Developing Random Ideas Into a Product
Two weeks ago, three friends and I started working on a project. We’re all engineers with a history of working together.
Building something together wasn’t something we wanted to do, it was something we had to do. This is a team of accomplished executors that have individually built complex, large-scale systems at companies like Google, Square, and BEA; yet we didn’t know what to build. We gave ourselves a week to figure it out.
Below are some of the lessons I learned in figuring out how to go from a random bucket of ideas to a product vision.
Don’t brainstorm by committee. This never works and free-form ideating is probably the worst thing you could do. Instead, embrace frameworks as an aid for your brainstorm sessions.
Here’s a sample exercise:
- Each team member peruse Angelist and selects their favorite startups.
- Setup a 3 hour meeting to go over them.
- Everyone pitch their favorite products back to the team. Explain the problem that the product intends to solve and why it may succeed (or fail).
- Write each idea on the board and spend some time discussing as a group. Draw correlations between the ideas, bucket them into market areas, and stack rank your favorites.
This exercise will help you develop a sense of perspective enabling you to see patterns, learn the landscape, and think critically about a various problems that exist in the world. With that in place, it becomes easier to debate ideas.
Although the job of a VC is to invest money, the best are actually great at giving feedback and molding ideas into products. That’s because they see hundreds of startup ideas and pitches, giving them a healthy dose of inspiration to draw upon. Angelist is probably one of the closest things that we have at our disposal to get the same effect — use it.
Go outside. Chilling on a beach, walking through the park, and silently pondering life in a library is not the way to generate ideas. Life happens at the intersection of choice and chance, and inspiration strikes when you’re busy doing something else.
And most importantly, get out there as a team. The kernel for our product idea came just after miserably cold, wet, and miserable hike in Mount Tamalpais on a Sunday afternoon. This particular product would have made the world a better place, had it existed that day.
If you’re trying to solve a problem or develop a new idea then get out there, talk to people, and live life.
Keep it simple. Complexity is the enemy of the good. The more complex your idea, design, or product is the more difficult it’ll be to explain. Any VC you pitch to should grok the idea in less than two sentences. Ideally one. Then you can drill into the details of how you’re going to do it over that cup of coffee.
The same also applies to running your company. In the early days things change and evolve so quickly that any added complexity will only slow you down. Be scrappy and keep your overhead as small as possible. For example, use spreadsheets to track your budget and Google docs to track everything else.
Create 11th hours. If you’re “just going to build something,” then strap in for an eternity of medicority. Builders love to build. But everything comes together at the 11th hour. If you don’t create these in the form of milestones, commitments, and deadlines, then the chances of work just trudging along at a steady rate is high. There should always be looming goals and deadlines on the horizon. Again, we gave ourselves one week before we pulled the plug.
Start small. Fail fast. You will have ideas that you love one day and hate the next. This is extremely common and also referred to as the Positive Change Cycle and it comes in three stages: Uninformed optimism, informed pessimism, informed optimism. Stage two is the most interesting, because you have two options: Keep pushing or pivot. Choose wisely.
Learn early and often. Initially you are temporary organization in search of a problem, ideally one with a solution that is scalable and repeatable. You should start with a set of hypotheses, not theories. Figure out how to turn theories into hypotheses or throw them out. Once you’re able to validate your hypotheses, then you really start to build something.
But try not to get ahead of yourself. Your first assumptions will almost always miss the mark in some way. A common pattern is the build-measure-learn cycle. The faster you can close this loop and repeat it, the greater your ultimate chances of success. There are lots of ways to measure, but talking should be the least of them. It’s almost always better to show, not tell. If you try to describe a new product to someone, chances are they will visualize something different. This is essentially the idea behind focus user testing, best products and preview releases.
Tell a story. Everything is better told as a narrative or a story. Don’t describe your product as a series of use cases. Explain how a customer might use it on a normal day. Bonus points if the audience you’re talking about can visualize themselves as that customer. You should be able to tell a cohesive story before your product is built.
Try envisioning a single day six months after your product launches. How does your user interact with the product? What do they see?
Love or hate this article? Let me know @davidbyttow.