March 19, 2011

8 Lessons Learned from Startup Weekend

I imagewanted to post this the morning after Startup Weekend Los Angeles concluded in late February, but due to the fact that I along with half my team (Minboxed) came down with the flu the following morning, I postponed this for long than I would have liked.

Startup Weekend Los Angeles stands out among other Startup Weekends in that each one of these events have produced real companies like Vol.ly, Foodme, Ming.ly, and Zaarly – who took first place in this very Startup Weekend and recently closed a $1m dollar round of funding and soft-launched at SXSW (great job, guys!)

The quality bar for talent is high and the judges are terrific – this year we were even treated to a surprise visit from Ashton Kutcher and Demi Moore, who judged my presentation along with 9 others.

This marked my third startup weekend, my second as a participant, and my first as a team lead.

I learn something new at each Startup Weekend; the ultimate value in these events isn’t really producing a product or a company – it’s learning how to work alongside a team of strangers to build something that didn’t exist 56 hours prior.

In that vein, I thought I would share what I learned.

1. You don’t need a functional product demo to win Startup Weekend

If I can point to one thing that I personally did wrong in this event, it was over-emphasis on building a functional prototype at the detriment of everything else. I can’t help it – I’m an engineer and a passionate geek.

I spent all of Saturday hammering out a prototype, figuring out how to connect to Gmail, how to use IMAP, how to write SQL queries to score achievements, how to batch everything from an ASP.NET MVC app on AppHarbor without worker roles, and so forth…

Minboxed didn’t place in the top three at the end of the judging, despite solid engineering and design efforts from our team – another startup, Eventify.me won 2nd place however.

In the course of Eventify.me’s demo of their live product, their entire thing came down and the team leader was forced to scramble onstage for the duration of her presentation. It’s the sort of nightmare scenario that every presenter worries about. In the end, it didn’t matter though – the judges were able to appreciate the quality of the idea and the future of the business without having to see it fully in action.

2. Sell the judges on the business, not the product

We were very focused on making Minboxed an awesome product – competitive social gaming built on top of email in order to make it more fun to be productive with your email. We had some innovative monetization strategies (in my opinion) and a good general strategy for acquiring customers; in other words, I think we made a good case for building a healthy business.

However, in our pitch to the judges those aspects of our work received a fraction of the attention that our product demo and our value proposition did. In hindsight, we made a great product pitch at the cost of a great business pitch.

3. Relate your business model to a proven one

In past Startup Weekends I’ve attended, the winners have always been companies who’ve modified a successful business model to either address a new problem or a new market; Zaarly took the Craigslist model and flipped it on its head, making it demand-driven instead of supply-driven. Hinty, the winner from the previous Startup Weekend LA, took a consumer-facing twist on TellMe’s business model.

I don’t want to make it sound like Startup Weekend judges punish innovative business models – it’s just easier to sell them on something that builds on the success of something else. I still can’t think of anybody who’s built a business doing something close to what Minboxed does; maybe that means it’s a bad fit for Startup Weekend or perhaps it means that we simply needed to go further to prove that there was a viable business behind it.

4. Talk to customers early

We did not talk to customers, a huge mistake. We talked to users, people who would be playing the Minboxed game, but not people who would be paying for it.

Had we talked to customers earlier we would have discovered just how far we needed to go in terms of privacy (one of the judges told me later that this was a big part of the reason why we didn’t make it.) In addition to discovering potential issues early and helping teams pivot on their business models and products, early customer commitments and testimonials are one of the best ways to sell judges on the future of your business.

We were focused on users of products, not customers of our business – a big mistake.

5. Do your pitch presentation with someone who isn’t on your team

Small lesson here – there were a number of things we did to make a good case for Minboxed, but we didn’t touch on them with either enough clarity or enough detail to convince the judges. Had we given our presentation to someone who wasn’t on our team before we ever showed it to the judges, we could have heard their “I don’t understand why…” questions and modified it earlier.

At the end of the day, your idea will be judged by how you communicate it as it will be on its own merits, if not more. Your team will take a myopic view of the business if you don’t include feedback from outsiders, thus why this lesson is important.

6. Cap the number of team members and pick people with specific skills

This is one thing that we did really, really well. We had a team of six, which is still a little large, but we made sure that we had the right people on it. Two engineers, one designer, and three marketing / business development folks.

I had to turn away a few people, and I’m glad that I did – when you get too many people, you spend too much time trying to make sure that everyone is included and trying to roll everybody’s work into the final product / presentation. You’re better off being mean on Friday night and saying “no thanks, we’re good” and paring down your team to the bare essentials.

7. Keep the engineering workflow tight

One problem I have yet to find a good solution to is how to manage the engineering workflow for product development at Startup Weekend.

Following my experience from this past Startup Weekend, it’s my new belief that if you have an appropriately tractable idea for Startup Weekend you should have two engineers: a back-end developer who owns 100% of the database + stack and a front-end developer who implements the JavaScript, CSS, and user-experience implementation. The two engineers and the designer (if there is one) need to hammer out on-paper designs for every page with a user interaction, and the back-end developer needs to create a set of dummy controllers for the front-end developer to build against.

I say this because my teammates and I have spent a lot of time trying to merge divergent bottom-up designs on Sunday on two different Startup Weekends, instead continuing to work on the product, and it’s a major productivity-killer.

If you have better ideas on how to do this and what’s worked for you historically, please leave a comment. I don’t have a perfect system for this.

8. As a team lead, your job is to evangelize

The team lead for any Startup Weekend project is usually going to be the person who pitched the idea before it was selected; as a team lead, your first job is to evangelize a vision to your team from the first second to the last.

If your teammates have a clear vision that they can buy into, it makes it easy for them to self-manage and work with minimal interruption.

Next are your potential customers –evangelize them on the idea and get early commitments and testimonials.

Last are your judges – your job is to evangelize them on the total vision for your team, business, vision, and product and earn their votes.

Stepping away to work on the product and talk to potential customers is still time well-spent, but ultimately your first priority is evangelism.

Thoughts for next time

I’m going to participate in the next Startup Weekend LA, and I’ll pitch a new idea, and even if I don’t win I’ll learn something new. Looking forward to it!

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..