Stanford Venture Weekend 2009 Debrief

One of the entrepreneurship student organizations on campus hosted an event called Stanford Venture weekend last weekend. Students from across the university were invited to apply to participate, and a team of about 25 students was formed. The concept in a nutshell was that within a 54 hour period, the team would brainstorm an idea for an internet-related start-up, implement a prototype, and prepare a pitch. At 9.00pm on Sunday, three Sand Hill Rd venture capitalists (VCs) and a VC partner from Wilson Sonsini, one of the leading law firms for start-up representation, would turn up to hear our pitch, see a product demo, and provide advice and feedback. Two rooms were rented from the university in Meyer Library from 6.00pm Friday to the end of Sunday and the organizers kept us sustained with breakfast, dinner, snacks and drinks.

The weekend was pitched in the following way: “We believe Venture Weekend is a great way to get the community excited about entrepreneurship and to spend an intense weekend with creative people who want to actually bring an idea to life as opposed to sitting back and listening to YATAE (yet another talk about entrepreneurship).” Truth be told, I was excited by the opportunity, but pretty skeptical about the whole idea. The ingredients of a successful start-up include having a great team, and having a team which is passionate about the idea.

The quality of students that turned up was not at issue—a university like this has the luxury of a student body containing more talent than you can shake a stick at. The team was composed primarily of computing science grads and undergrads, with a sprinkling of MBAs, design schoolers, and a couple of law school students. However, “great team” refers not only to the individuals in it, but also how they work together. This competition would chuck together two dozen people, most of whom didn’t know each other, and hope they somehow would gel.

The second skepticism arose from the fact that the start-up idea would be the product of a brainstorming session, but surely no single idea was capable of generating enough passion from everyone in such a diverse group. Especially for something that would require a lot of hard work, an entire weekend, and a high opportunity cost. (Eg, law students have finals looming two weeks away.)

Surprisingly, these two things turned out to be less of a problem than I thought.

At Friday 6.00pm we gathered in a meeting room in Tressider with two large whiteboards. About 20 of us had decided to show up and the gender imbalance was massive—literally one girl, a CS undergrad. After some time for mixing, we split up into groups of 3 and started brainstorming ideas for a half hour. The first challenge was extracting the single idea to pursue from the mass of ideas people came up with. The deadline for this was 9.00pm. Each team of three got a chance to quickly run through their ideas with the whole group. The point of brainstorming is to throw up as many ideas as possible, but the major pitfall in such exercises is that people often jump in with criticism, and the proposer feels obliged to mount a defense. This detracts from the point of the exercise and bleeds away time.

Engineers often half-jokingly wonder what the value of MBAs are for in a start-up. Here their value was clear. A couple of them stepped up to facilitate the brainstorming session and impart some direction on the team. It must have been a bit like herding cats, though. By keeping the process moving forward, they slowly extracted a list of a dozen ideas which were written on the whiteboard and explained in more depth. The person who came up with the idea spoke for a while about it, and then people asked questions to get a better understanding.

Each idea was voted upon, and the five most popular were short-listed. Each of these were then examined again in greater depth—market size, revenue opportunities, difficulty of developing a prototype by the end of the weekend, competitor identification, team size needed, and so on. We then voted on the top two ideas we each thought we’d like to personally work on. Interestingly, people’s preferences shifted in the last round of voting (indicating to me the value of the preceding discussion), and we ended up with two clear leading ideas garnering ten and six votes. After much discussion, we eventually came to the realization that it was going to be unwieldy to coordinate a team of 20 on a single project. For instance, if you don’t need 10 coders, you shouldn’t use 10 coders—too many cooks. We elected to split into two teams pursuing the top two ideas, but made it clear that the teams weren’t exclusive. The point of the weekend was that the whole thing should be collaborative, so skill sharing between teams was important. Sometime around 10.00pm we made our way to Meyer in our respective teams to begin the two start-ups.

I found the process significantly more painful than my description probably reveals. Most people were quite outspoken, and although there were rarely problems with people interrupting others or things like that, it did mean that there were a large amount of valid opinions to juggle. Even deciding how to run a vote on the ideas was a difficult process in itself: should we vote on our top idea? Or top 2 ideas? Or on all the ideas we’d be willing to work on? Or should we vote on the ideas we think are viable? There was much wheel-spinning in the mud and I could see my initial skepticisms fulfilling themselves.

The rest of the night was very messy. We spent it trying to scope out the two ideas, but kept conflating the issues of what we should achieve in the weekend with what could be achieved in the longer term.

I’m not going to write much on the two ideas, but it is helpful to briefly detail them to get an idea of the different challenges facing each team.

The most popular idea was the creation of a platform for placing virtual objects in real world locations. These objects can be interacted with by anyone with a mobile device with GPS (typically an iPhone). The platform would enable a variety of applications, including gaming (giving people an easy way to organize and participate in scavenger hunts), informational (guided tours), and commercial (Livecoupon-type services). The idea was very similar to this idea brief I came up with in November last year. (This illustrates the fact that good ideas are a dime a dozen in this part of the world—executing an idea is a different thing altogether.) This idea was a major project to fully implement, but the potential upside was huge.

The second most popular idea was the creation of “university Twitter”, which I initially treated with disinterest because of the name. But that description is probably not apt. This is how I now view the idea: at tech conferences, many people liveblog keynote speeches, or join a chat channel to comment on what a speaker is saying in real time (kind of like a back channel for chatter). If you apply this idea to the classroom, you open up the possibility for real-time collaboration between students. You also provide professors with numerous benefits such as the ability to monitor and encourage participation, to obtain an objective measure of participation, and obtaining student feedback. This seems disruptive at first, but when you realize that most students are on Facebook or e-mail during lectures anyway, this is probably a good way to keep students on topic. (One anecdote: a friend of mine decided to join Facebook during a lecture. He sent out invites to all his friends in the same lecture and was amused to find all of them being accepted over the next five minutes. Clearly no one else was paying full attention to the lecturer, either.)

The first idea was the one I (initially) found more interesting. After all, the problem space was bigger, more complex, and it was an idea that I had previously come up with myself. We had another brainstorm and there were varying opinions on how to proceed. Lots of mutual misunderstanding, efforts to get people on the same page, and more wheel-spinning. Meanwhile in the other room, they were already brainstorming business names, drawing screen mockups, and moving forward. By midnight, we were clearly not all on the same page, and I think the frustration led to us calling it a night soon after. However, we had managed to draw up a quick and dirty database schema and some screen mockups.

Saturday morning came. When I arrived, we’d lost a few people and were left with about 12-15 who decided to stay on. The two groups were roughly evenly numbered and had started to fragment into sub-teams. Even though the products weren’t fully fleshed out, the sub-teams had decided to press on regardless and match up the edges later.

Some thoughts related to the sub-teams. I think the basic skills an internet start-up team traditionally needs include:

• back-end coders (including SQL, database schema creation and optimization, and programming in languages such as PHP and Python);
• front-end coders (including HTML, CSS, Javascript);
• also, the back-end coders need to be able to talk to the front-end coders when interfacing the two ends together, so data manipulation skills are important (eg, knowledge of XML, JSON, AJAX, etc);
• graphic designers;
• if applicable, any technical people needed to develop models which back-end coders can translate into code (eg, economists, financial analysts, etc); and
• “business people” (to help obtain funding, so they help to perform market research and viability studies, prepare and deliver presentations and pitches, and form and manage relationships with other relevant parties. They are also valuable in managing the team and providing leadership and direction.)

These roles are not exclusive. People are multi-skilled. There is no reason why a coder couldn’t also be a business person, or why a graphic designer can’t deliver a pitch to a VC. But typically, these skills are all desirable, if not essential.

Note that a “law person” does not appear in the list above. Law students are in the unusual position of not actually being able to really use their skills in a start-up. Not actually being California-qualified lawyers, we’re generally not allowed to give legal advice, draft contracts, or do any of the stuff that lawyers do. Providing legal guidance can skirt the fine line between violating and complying with professional conduct rules, so often the most we can do is spot legal issues and potential deal breakers. And then refer the team to a real lawyer, which is not particularly helpful for a start-up without any funding. What about incorporating a company? Maybe I could do it in Australia, but I wouldn’t trust myself to do that in California without legal counsel, and definitely not when there are equity division issues, among other things, present.

Besides being a lawyer, I’m in the somewhat unusual position of having a decent working knowledge of back-end coding, front-end coding, and (it turned out) graphic design. So I wasn’t completely useless. I’d rate myself as pretty competent in all three fields, although not an expert. So for example, I can reasonably easily develop most website prototypes, but I don’t know how to make a website or database scalable to handle high volumes of traffic. I don’t have experience managing large code bases, worked on by a team of coders (eg, using Subversion). I can design logos and page layouts, but I have zero talent when it comes to drawing original artwork. But I have been making websites for years and years.

After a couple hours of discussion that appeared to be going around in circles, some sort of vague consensus was reached about what the virtual objects platform product actually was. Soon after, the team roles were snapped up. Two people worked on coding the iPhone app, one worked on implementing the back-end API, and there wasn’t really a web front-end to code. A d-schooler set to work on designing page layouts. I twiddled my thumbs. I asked for something to do, but there wasn’t much. I was told to figure out how to interface Google Maps’ Javascript API with an iPhone App. My knowledge of iPhone App programming is limited to the first two online lectures of CS193P (available for free at the iTunes store), and I don’t know Objective-C, but I did a bit of poking around anyway. I discovered that iPhone 2.0 doesn’t have an easy way to translate Objective-C calls into Javascript calls (unlike the forthcoming 3.0), but someone had written a UIWebView component to do the job of translating the calls (at least for a partial set of the API). That occupied me for about 10 minutes. Then I was back to thumb twiddling.

Then an MBA on the Lecturefeed team was trying to create some graphics for their website. However, no one really had any Photoshop experience, so when I stepped in to help him, he asked if I wanted to help them do graphic design. Since I wasn’t doing anything else, I was summarily assimilated into the Lecturefeed team. Graphic design is probably the area I’m least comfortable with—I’ve never had any design training and all my Photoshop and Illustrator knowledge has been cobbled together through years of trial and error and online tutes. (Not that I had any formal training in web-oriented coding—I, like many coders, learnt all of that stuff out of my own volition—but the comp sci classes I took in undergrad at least taught me programming best practices.) The MBAs sketched the logo on the board, and were attempting to design it using Powerpoint(!) so I eventually ended up designing it in Illustrator. I fed images to the front-end coder as requested, worked on the color schemes, and troubleshooted design issues.

By the end of Saturday, things felt like they were moving along nicely. The coders were all doing great jobs, the iPhone app was slowly taking shape, and somehow both teams had managed to coalesce and make material progress.

Sunday came and I was told to design the logo for the virtual objects platform, but they hadn’t even come up with a name for it. They gradually decided on “Upquest” after a survey of available .com domain names, and I made a series of candidate logos. Meanwhile, the MBAs were constructing their neato slide deck and running rough market sizing calcs and financial projections. By the time the VCs appeared at the door, we had amazingly completed what we had set out to do. We had a fantastic presentation and working preliminary prototypes. My skepticisms turned out to be much more unfounded than I even hoped they’d be.

The feedback we got was happily positive. One VC was “very impressed” by our weekend efforts, and told us that relative to everything he sees usually, the standard that night was high and we were welcome to drop by his office in the future when things were more developed. I’m not sure how much of this was them blowing smoke up our asses, but VCs around here are well known for not pulling their punches and pouring cold water on ideas that don’t interest them. Then again I’ve heard the opposite as well—they don’t like to reject things outright because there’s no upside in potentially souring a future relationship.

However, the most interesting part to the weekend for me came after this. The partner from Wilson Sonsini stuck around to answer any “next steps” questions that we had. I asked him about what the typical process for start-ups was after idea formation. Nothing legal had been discussed by anyone up to that point, which I thought was positive because it meant that people were focused on the weekend’s activities rather than something potentially more self-interested. This would have been fine had this been like a class project that wasn’t taken further, but of course people from both teams were now thinking of taking things further.

Typically, a venture that is intending on becoming serious will incorporate. The new company is a legal entity in which ownership rights can be clearly divided (through division of equity) and a receptacle into which all IP developed can be assigned. Incorporation costs money in taxes, fees, and ongoing compliance obligations, and a company’s constitutive documents also need to be drafted. The more founders, the more complex or time-consuming the process will normally be. I was told repeatedly that it was highly advisable to retain legal counsel to assist with the incorporation process. Although not strictly necessary (there are online services that will do it for something like $300 a pop), it’s a question of risk tolerance. Things can go wrong with the paperwork, but no problem will arise if everything else goes fine. But incorrect paperwork can cause problems down the track—ownership or management squabbles and breakdowns in relationships between founders, for instance. And a company with an uncertain legal position creates risk that is a turnoff for VCs and other investors. (While the founders can scribble down an agreement to split equity on a napkin that will appear to work, these seemingly innocuous scraps of paper can cause major headaches later on.)

VC lawyers will usually defer fees and make take a nominal equity stake in the start-up if they advise it. Because the fees are deferred until the company receives funding, if the company fails in this endeavor, the lawyers won’t get paid. Therefore, VC lawyers perform their own assessment of start-ups to see what’s viable. (One yardstick they use appears to be what the opportunity cost of setting up a business is to the founders—do they have their livelihood riding on this, or are they doing this as a summer project to kill time while they wait for their full-time job to start?) VC lawyers can also connect start-up clients with VCs as well, so in this case the lawyers perform a bit of pre-filtering for the VCs. Having a reputable lawyer can assist with credibility and reputational capital that is useful when seeking VC funding.

The trouble with not incorporating is that it becomes difficult to determine who owns what, both in terms of IP and the business itself. Although the value of IP may be zero at the venture’s beginning stages, IP is nonetheless created and usually owned by the creator in one form or another, whether as copyright or otherwise (eg, code, graphics, some form of business input). If this IP is not assigned to the business in some way, then use of that IP may give rise to liability due to infringement of the owner’s right. Without a company, the IP has to be assigned to an individual. You could transfer IP to individuals as joint holders, but this raises its own set of thorny issues.

Understandably, we wanted to keep the ball rolling while the buzz was still in the room and we were still physically together in the same room, so an immediate attempt was made to try to figure out how to split the equity pie as soon as the lawyer left. A few people wanted something written down on paper. My lawyerly instincts began to kick in and I could see the numerous problems besetting this goal. First of all, some people had to leave due to the late hour. I didn’t see how it was possible to reach any sort of agreement when everyone who had a stake in the weekend wasn’t in the room. (Even those who weren’t interested in pursuing either idea might have some sort of IP ownership in some aspect of the project which could cause future problems were that IP to acquire commercial value.)

Secondly, there were a lot of people involved. Maybe six people wanting equity in each venture. Negotiating equity splits would be difficult. There wasn’t much contention over splitting a portion of the equity (10%) equally in reflection of the contributions of each team member even though the time spent actually working seemed to be weighted towards the coders. The bigger challenge was trying to figure out how to split equity based on future commitment. Each of us had variable time commitments, so it seemed to me impossible to reliably determine that night who was actually committed. For example, someone could say they wanted to work on it full-time over summer and therefore they should get a 25% stake. But an unusual opportunity might arise over the next two months which causes them to bail—but they still would have an ownership stake that didn’t accord with their contributions (and no one seemed to be considering contributing anything other than sweat equity). So there was suggestion of creating a vesting schedule for equity, or some sort of “temporary equity” (equity that “goes away” if you don’t get involved). Again, with that many people involved, I could see issues, and would expect many unseen issues, with doing something like this. There were definitional issues (how do you determine who is “involved”? How sufficient does the involvement have to be? How do you handle voting? If you allow other stockholders to vote that one stockholder is no longer involved and thus has to divest their property interest, how do you protect minority stockholders from being colluded against?). There were legal issues (was any of this even legal? Does a controlling stockholder have some sort of duty to look out for minority stockholders?).

Far too tricky to scribble down on a scrap of paper that night. The lawyer had also mentioned that these scraps of paper that float around can surface later on and complicate things. Furthermore, drafting a legal contract is an art form in itself. Just as with coding, there are right ways to do things, and wrong ways to do things. Sometimes the wrong way to do things works anyway because things go as expected. But often things go wrong—unforeseen circumstances arise, people do things which are unexpected, and when the values fall outside the boundaries which were hastily conceived late on Sunday night, if you don’t have robust code, or a robust contract, things break. Just like our prototypes, we could produce something that gave an idea of how things should work, but there’s no way it could be used in a production environment. Creating something purporting to have binding legal effect in that situation was kind of analogous to launching the prototype we had into prod. It’s dangerous and it simply won’t work.

So I put forward a suggestion. We could attempt to write down some proposal of how ownership in a future company was to be handled. We could write down an indicative stock split covering just the people in the room. We could even formulate some language about how a stockholder could be required to divest their holdings to other stockholders on a pro rata basis on the unanimous vote of other stockholders. (From the looks in the room, I discovered that the term “pro rata” is not as intuitively understandable a concept as I have come to believe and it probably should be replaced with something a bit more plain English in contracts generally.) We should then circulate the proposal to everyone by email, and call a future meeting. Anyone with an interest in obtaining equity should attend or indicate their interest if scheduling issues don’t permit attendance. The meeting would nut out the proposal more fully. Then, if people were really serious about moving forward, we should hire legal counsel to begin the incorporation process, using the proposal as a guide to what we wanted. We would then be told whether our proposal would be possible (I doubt the enforceability or validity of the divestment provision). The other issue would be to get everyone else who attended the weekend to assign IP over to the company for some nominal amount—something which may be administratively difficult to achieve, especially once people start leaving for the summer.

This suggestion seemed to persuade the group, and we left without putting anything down on paper but agreeing to set up a future meeting. My experience has been that interest quickly flags as time goes on, but the people that are genuinely motivated to carry on the idea, will.

It was an illuminating and interesting discussion to see people’s viewpoints, and the age old problem of lawyers frustrating businesspeople by raising roadblocks was evident. But part of lawyering is reducing the risk of bad consequences when things go wrong. Everything might seem hunky-dory when everyone’s in a good mood, but just like any computer programmer will tell you, there are always bugs somewhere in the code—if the code is used a lot, the bugs will turn up sooner or later. Legal bugs can be expensive to fix. Ultimately, though, legal risk is but one form of business risk, and like any type of risk, it’s usually a business judgment call whether it’s a risk worth taking. If everyone wanted to go ahead and draft up a contract that night, it would have been entirely in their rights to do so, nor would it have been particularly unusual.

The weekend turned out to be very worthwhile. I learnt heaps, met a lot of remarkable people there, and we put together something that exceeded all of our expectations (two prototypes!). All things considered, the organizers did a great job of coordinating things (even going so far as to get some Red Bull and In-n-Out burgers for us when we started clamoring for them). As part of the learning experience, a few things also emerged that would help to improve future weekends:

• NDAs and confidentiality agreements are probably not necessary (and there were none)
• Considering whether some legal paperwork should be distributed, such as an IP assignment agreement of some description, to be signed by anyone not interested in pursuing a venture beyond the weekend
• Consideration should be given as to what rights, if any, the university might have over a venture that arises from the use of university facilities in developing it
• The brainstorming session might benefit from the presence of facilitators (whether third parties or identifying a couple from the initial team)
• Team sizes should be flexible, but not too large (it is difficult to envision a project that is scoped appropriately for a weekend of work, yet involves an army of 20 people)
• Providing an overview beforehand of what the potential process is for taking things further, so as to set people’s expectations going into the weekend.
• How will domain name ownership be handled? (We registered domain names for both ideas that weekend.)

A large part of the learning experience was also the interesting insights gained into entrepreneurial team dynamics when working with different sorts of teams. Last quarter, I had the privilege of working with a bunch of incredible people (a Sloan who developed Google Adsense, a few MBAs with military, start-up, finance and publishing experience, an accomplished economics PhD, and an EE PhD who sold a Facebook application company with a userbase of millions). I was maybe the youngest team member there, and the way the team operated was a lot different to a team I’m in this quarter, where I’m the oldest team member. One style was not necessarily better or worse (last quarter we never even got close to getting a prototype developed due to a series of other problems we encountered), but just the working style is tangibly different—how the team chooses to communicate, divide responsibility, motivate and deliver feedback to each other, prioritize values and goals, and so on. Often it’s a matter of adapting to fit each one (and vice versa). Venture Weekend was a different type of team again.

This post has been a braindump and probably contains various inaccuracies, but if I had time to go through it again, I’d likely end up making some edits.

  1:27am (GMT -7.00)  •  Business & Finance  •   •  Tweet This  •  Add a comment