You have an idea. You probably have lots of ideas. And you want to build them all. You’re probably thinking all these ideas will solve the problem you or your users are having. But how do you really know? How do you become confident in order to build the right thing to solve the right problem without wasting your money? Or your rich aunt’s money? Or an investor’s money?
We believe that the best way to do this is to build in small increments, get feedback from humans, learn from it, and adjust based on what we learned. We use the following steps to eliminate uncertainty, fail quick, and fail cheap in order to build the right product for the right people:
- Step 0
- Build in small increments
- Get feedback from humans
- Learn from it
- Adjust based on what we learned
This is the first of five posts in this series. We'll cover Step 0, the prep work we do to identify the problem we’re trying to solve, before we start building. We do this for new products and for new features within an existing product.
First, we start with a conversation about what the problem is and who is experiencing it. We don’t talk about solutions or technology in this conversation, only about problems. It can be hard to avoid the obvious solution, especially if it worked out well for our friend or if it’s the latest and greatest new feature used by Facebook. “They are doing it this way, we can just do that too” is alluring. It seems easy and cheap to copy a solution. But it is often fraught with solving the wrong problem or missing out on a more effective solution.
During this conversation, we ask a lot of questions. We use The Five Whys to get at the root of a problem to make sure we’re solving the right one. Having a focused conversation about the problem helps us consider all ideas equally to find the right solution.
Second, we do the research. Once we know more about the problem, we ask questions of those who are experiencing that problem.
- Have they been able to solve it yet?
- How they have solved it today?
- Why did you choose this solution?
We avoid focusing on specific technology, products, or tools. It's possible one or more humans are doing manual work to solve the problem today. Or there are four different tools they string together and a human in the middle coordinating the middle steps. Or there is nothing in place to solve the problem today. We take the answers to these questions and research what else exists to solve the problem. Existing solutions may address some aspects of the problem, but they likely don't solve them all.
As part of this research, we look into what’s not working with their current solutions and which solutions they chose not to use. What are the challenges with four different tools and a human in the middle? Where are the pain points in that process?
Identifying the pain points users need solved lets us start generating ideas for solutions. Depending on the size of the problem, we might do this as a team on a whiteboard or as individuals.
Who are we talking to?
We're talking to people experiencing the problem. If it's a problem we are experiencing, we find others who also experience it so as to get unbiased information. These are our early adopters. They are serious about solving this problem, interested in testing it and in providing feedback to improve it. These people will hang around with us through each of the next steps as we start building and learning.
Starting with Step 0, we can avoid solving problems users don’t have or don’t need solved. Sometimes it’s an ok problem to have but not critical and we don’t need to solve it.
Stay tuned for the second post in this series on building in small increments.