Good problems to solve
If you’re not on a mission to solve a specific problem, how do you choose the best customer problem for your startup to work on solving?
Solve customer problems that arise often, every day
We have to help our customers develop new habits — to use our product/service to solve that problem, rather than their old habitual solution. Habits form more effectively with less time between repetitions.
Another variable in that equation is the real or perceived value created. If the real (or perceived) value created is sufficiently high (eg selling a house for $200k more than the traditional means of sale) then frequency-of-use doesn’t need to be as high. But if you have to choose between solving a high value problem or a high frequency of use problem, you should choose the latter. Habits just form more quickly the more often a new solution is used.
The third variable is to choose problems for which you can add value fast. If your customer has to go through a lengthy onboarding process before they receive the value from your solution, that’s not as great as if you can give them some of the value in the first sixty seconds. Much of the rapid adoption of Tinder and Uber comes from the very rapid pay-off. Tinder reduces your time to start feeling like you’re going to meet attractive people to under a minute if you already have a photo of yourself on your phone. Uber books you a ride in under a minute, a process that used to take a few minutes on hold and then another minute or two speaking to a bored, hostile person on the phone.
Divide in order to conquer
Build solutions that you can sell to individuals within an organisation or community, rather than to the organisation or community as a whole. Divide and conquer. Be Atlassian before you aspire to be Oracle.
Build solutions that stand alone, that don’t need to fit into a tech stack or set of other processes.
Build solutions that don’t need regulatory approval, or to fit into fixed, inflexible organisational requirements.
Don’t build solutions for problems that exist in the organisation you currently work at, or on the employer’s time, because once your employer finds out about it, you may discover the hard way that your employment contract says your employer owns what you’ve been building.
Don’t build a solution to your own problem
Your own lived experience as the customer with the problem is useful to a degree but its importance is generally overstated.
The moment you decided to try and solve this problem in a better way, you became fundamentally different to all your actual customers, who would be prepared to continue solving the problem in the normal way for the rest of their lives. Your dissatisfaction with the normal solution contaminates every insight you have into the customer experience.
You can hire in people with lived experience if you need to, and better still, you can do broad and deep customer research to understand the customer and the problem without ever having experienced it yourself, if you learn how to do valid customer research at scale. I’d rather you learned how to do great customer research than taught yourself to code!
Build solutions that are 10x better
Hopefully it goes without saying, but build solutions that are either 10x better quality than the existing solutions, 10x faster, or 10x cheaper. Don’t build something that is going to be only incrementally better quality, incrementally faster or only a little cheaper. You just won’t deliver the dopamine hit your customer needs to choose your solution the next time they need to solve this problem — they’ll be too likely to have forgotten about you, and to switch back to their old, habitual solution. You’ll have to pay to re-acquire them again. You won’t get them evangelising your product to their friends and colleagues. They won’t feel so clever. You won’t have made their life measurably better. And they won’t tell you how much they love what you’re working on (which is so much of what startups should be about!)