Stop Trying To Validate Problems
Stop Trying To Validate Problems
Problems can't be validated. They are best discovered.
👋 Hi there - I’m Ash, and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Every Saturday, I share battle-tested recipes, strategies, and how-tos for systematically building repeatable and scalable business models.
When asked to do the smallest thing to learn from customers, the first instinct of many founders is to run a survey.
Starting there is usually a bad idea.
You often don't know what you don't know at the earliest stages of an idea. This makes it hard, if not impossible, to script a survey that hits all the right questions to ask, especially when you're also expected to present them with a multiple choice of answers to pick from.
A better approach is to conduct a customer problem interview. But here, too, rather than using open-ended questioning (a topic for a future issue), it's too easy to fall back on presenting the customer with a list of problems to rank.
This isn't much better because when you spotlight specific problems, you inadvertently end up biasing the customer. Even when the customer seemingly accepts having a problem you're looking to solve, they may be doing so out of context or to be polite, which is easily mistaken for validation.
Acting on a false positive problem is very costly. You end up spending needless time, money, and effort building a feature or product that's in for a future rude awakening.
I've made this very same mistake trying to validate versus discover problems.
Many years ago, I was exploring a large file/photo-sharing app aimed at busy parents.
The problem statements on my Lean Canvas read, “Sharing lots of photos and videos is hard” because:
there are lots of kid photos to share,
sharing and uploading lots of photos is time-consuming,
parents don't have lots of free time.
I set up over a dozen interviews with parents. I opened the interview with a short problem story and asked them if it resonated. It did. I then got them to rank these problems, which I used to prioritize what I built. A couple of weeks later, I even shared a short demo showcasing how quickly and efficiently they could share a large batch of photos using my solution, which was received with excitement.
Armed with what I thought were validated problems, I then spent the next two months building out these features and sent invites to everyone I spoke with. Based on the enthusiasm from the interviews, I was expecting instant uptake. But after 30 days, only 50% of them had downloaded the app, and only 10% had shared any photos.
This was a costly lesson, which is why I want to share this with you.