I was a mentor at the Santa Cruz Tech Raising event last weekend, meeting with individuals and teams who were making their ideas into real, useable products and services. Santa Cruz is just over ‘the hill’ (the Santa Cruz mountains) from Silicon Valley, so it’s close enough to be pollinated by Silicon Valley but distant enough to develop it’s own distinct tech community and culture.
The Tech Raising event was a terrific focal point for that community. The organizers have a format where interested parties meet on a Friday night and work through the weekend towards a prototype, which they demo Sunday evening. It doesn’t elect any winners or losers- as in real life, it’s up to the participants to win on the terms they define. The venue and format are organized to encourage meetings between interested parties (developers + designers + strategists/marketers + others) and collaboration. Mentors and speakers are there to help out where they’re needed.
What struck me most was the consistently high quality of the ideas and the individuals there. If I had the resources, I’d invest in most of them myself. Now that the weekend is over, they face the same challenges as every other entrepreneur.
Whether they called it by name or not, most of the teams had a general notion about major trends in operating startup’s, which I’d summarize as:
A. ‘Lean’: Don’t try to write a five year plan for a startup- you don’t know what’s going to happen. Make your assumptions explicit then validate them with the shortest possible experiments that validate your key assumptions. Do it within a specific time frame. If you can prove yourself right, persevere; if not, pivot and try a new approach. This includes focusing on an “MVP” (minimum viable product) for launch, versus something that has everything you’d like it to include.
B. ‘Customer Development’: Get out of the office and spend a lot of time talking to customers. Map out their needs explicitly and validate you have a solution for them using the ‘Lean’ method above.
C. ‘Agile’: Work with your development team in two to six week cycles where you see working product all the time. Don’t go crazy with a gigantic specification and big ‘pull back the curtain’ deliveries.
Beyond these, I did find myself having a lot of conversations that revolved around these three recommendations:
1. Walk Quickly but Watch Where You’re Going
Let’s say the founder has a developer who’s available and eager to work on the project. Should they hold the developer until they have a set of user stories? My first answer would be to sit down with the developer and write up the stories. What if the developer doesn’t want to- they just want to get going? That’s not a great sign, ideally you want folks who are enthusiastic about collaborating in this way, but I’ve seen it happen and when you want to get going you take what you can get. In general, I’d say just get started and work closely with the developer in discrete steps. But just because you’ve started without them doesn’t mean it’s not a good idea to write up the stories. They’ll help you along the way- it tends to be just the right amount of structure to make sure your team is building what you want to validate in the market.
2. Build a Room Before you Build a Castle
It’s very hard to get users to sign up for a service. Yes, it’s nice to have them on your platform but you’re going to have a lot of work getting to critical mass. Even if that’s your destination, I strongly advise considering the initial version as an app. on top of an existing social graph like Facebook, LinkedIn or Google+ and avoid taking the users too far afield. You’ll have a much better shot at getting an interesting quantity of users where you can validate your idea.
3. Get from Beautiful Vision to Sexy Silhouette
If your goal is to attract a developer, particularly to work with you to get to a prototype or MVP, you want to maximize the sexiness of your business idea and minimize the amount of work they’ll have to do. Other than having a great idea, the best way to maximize the sexiness is to show you know the user/buyer intimately. The best way to do that is to have a vivid audience description and solid, well researched user stories. The good news: this also helps minimize the amount of work your prospective developer has to do since user stories are designed to be highly actionable for developers. If your item is a website, learn how to use a content management system like WordPress or Drupal (not hard, really) and make sure the developer knows you just need the core of the site put together, that you’re ready to use the built-in tools to fill in the content.
I’ll be getting materials from the book, like the Enable Quiz product design which has user stories, online in the next couple of weeks. I also posted a paper with some example user stories on the Leonid website- click here.
