Start by identifying a problem. Don’t start with an idea. Get married to the stakeholder and the problem they may have, not to a genius solution that you think you have.
If you start with an idea of a solution without first having lived or identified the problem very well, it’s highly likely that your solution will forever be in search of a problem that does not really exist or that may not be as painful to a stakeholder as you’d hope.
Michael Seibel’s analogy illustrates well:
If your friend was standing next to you and their hair was on fire, that fire would be the only thing they really cared about in this world. It wouldn’t matter if they were hungry, just suffered a bad breakup, or were running late to a meeting—they’d prioritize putting the fire out. If you handed them a hose—the perfect product/solution—they would put the fire out immediately and go on their way. If you handed them a brick they would still grab it and try to hit themselves on the head to put out the fire. You need to find problems so dire that users are willing try half-baked, v1, imperfect solutions.
In this GIF Dexter has a problem worth solving. You give him a brick (v1 MVP) and he will use it, even if it’s not the perfect solution.
Alright, so the concept of a worthy problem is easy to explain, but how do I find one? Here’s the framework I use to identify problems worth solving, in which you are more likely to survive if it’s a problem you’ve lived yourself.
- Causes Frustration
- Takes too much time
- Is too expensive
- Already spending money on terrible solution
That last point is key, since its easy to lie to yourself saying “I would pay for this” if you are enamored with your genius solution whereas if you are already paying for something terrible then it stops being an hypothetical.
Exercise: My suggestion to be able to train yourself to not think about the solution before the problem and to make problems more visible is to take 5 minutes and write down 20 problems, deliberately not thinking about a solution, just problems. Quantity is better than quality. Repeat this process a couple of times and you’ll see that each time it becomes easier to define problems without worrying about the solution yet.
Feel free to reach out on twitter @andresbarreto (faster) or through here if you have comments or questions