Startup Weekend Toolkit

Here’s a Startup Weekend Toolkit I put together after mentoring and judging. It’s a lot of info, so it’s best to read this before you go since you will be busy enough (and sleep deprived) during the weekend, but these resources will save you lots of pain.

Startup Weekend isn’t a hackathon or a business plan competition… So work on these activities instead:

1. Customer Development. “Get out of the building” and talk to people. Learn from them. What hypotheses do you want to test? Do your potential customers support and reinforce your assumptions? What qualifies success or failure?

2. Business Model. Express what you learned in customer discovery: Who is your customer? What is your core value proposition? What are your key activities? What are your revenue streams? What is your cost structure? Who/what are your key partners/resources? What are your distribution channels? What is your roll-out strategy?

3. Execution. What did your team build during the weekend?

4. Your presentation. Not being able to express what you did is the unspoken failure point of many teams. Start to practice on Saturday, not Sunday.

Are you really building an MVP?

Working with lots of startups, the most common error I see people who think they are working on an MVP is that they do not understand what an MVP is. An MVP is focused on getting validated learning. Write down your hypothesis and what will qualify as success or failure for you. See more about that below. Otherwise, how do you know if you’re learning anything?

A sample hypothesis format:
I believe that [customer segment] has [problem / need] and [a specific number / percentage of them] will do [action / use this solution].

Hypothesis Formation to guide you as you build an MVP and then collect data. Read this brief article for guidelines.
Questions to consider: What are your riskiest assumptions? What MVP will enable you to test your riskiest assumptions? What will you accept as validation that you are solving your customers’ problem?

MVP case studies:
Think about how Dropbox, Aardvark, The Ladders etc tested their services before building them out.

Some techniques to build an MVP:
– Landing Page — put up a landing page that leads the visitor to believe that the product has been built out. Then test user actions — do they try to sign up, do they try to buy, etc;
– Mockups / Wireframing — these can be on paper, using tools as simple as powerpoint (where I like to hyperlink fields on the page and connect them to other pages to make it feel like a website), or more sophisticated tools like InvisionApp or Balsamiq. Give the user the feeling of using your product before you write any code;
– Video — make a video to demonstrate what your service does before you build it. This could be as simple as text or basic images or screenshots with a voice-over;
– “Concierge” — use humans to emulate what the software would do later on, if you were to build it;
– Prototype — actually build a working version.
– “Parasite” — this is the name I use for riding on top of another network (Twitter, FB, Skype) and using the users there as test subjects rather than trying to drive new users to your new service.

Doing Customer Discovery Interviews:

1) Ask about situations in which potential customers might be aware of the problem you’re trying to solve and then ask questions around that. This means that if you’re trying to solve the problem of finding cheap vacation travel packages, I’d ask “Do you like traveling?” and ask them to talk about that, instead of directly asking “Do you want to find cheap flights for your vacations?” (which is a question that forces them to say “yes, of course” — not that helpful to you).
2) How do you solve this problem currently? or What do you do to make it less painful? In the above example, they might have signed up for notifications for cheap flights from online discount travel agencies. This will tell you about the competitors who are already involved in solving this problem. Not just the existing business competitors, but also ways that people deal with this problem by themselves.
3) Can you describe this problem to me in your own words? They may have already told you about this without you having to ask them. Directly asking this also only works if you didn’t already force the issue by asking them if they have the problem. Otherwise they’ll just repeat what you asked them already. This may also give you keywords to put on your landing page and in ads.
4) Are there other solutions out there that you’ve tried in the past? This will make you aware of competitors or other services addressing similar problems.
5) What do you wish you could do to solve this problem (even if it isn’t practical)? This can be really powerful, especially if you find out that something they think is not practical is now practical for you.

Cool things you could show:

• Number of people you spoke to;
• What you learned that was unexpected;
• Actual purchase orders;
• How you hacked the system to get it all done.

Watch out for these things. I made this list by surveying past participants:

• Mentor whiplash (getting pulled in different directions by different mentors);
• Replacing customer interviews with online surveys (because you run out of time or are too hesitant to find interview subjects);
• Hesitating to “get out of the building;”
• Underestimating the time it takes to talk to people;
• Building too much, testing the problem too little;
• Not taking risks, not being creative;
• Not practicing the pitch enough;
• Thinking too much about the judging;
• Team fighting, worrying about IP protection, getting distracted, no team balance, team too large.

Practice your pitch. Pitch structure ideas:

• Introduce yourself and team;
• Introduce the problem, Show your solution;
• Talk about how you got there: Customer Discovery work you did, your Business Model.

And for what happened when I tried to run my own one-person Startup Weekend before I was a judge for the first time, read this.