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.
Problems can't be validated. They are best discovered.
Given what I know now if I could go back in time, I would not have started the interview with a list of problems. Instead, I would have asked them about the last time they shared photos.
From there, I would seek to understand
- when they share photos (triggering events),
- why they share photos (desired outcomes),
- what they use to share photos (existing alternatives), and finally
- where they struggle (problems).
What I would have learned was that parents
- take lots of pictures but only share select photos,
- so they can share their children's best memories with loved ones.
- They were currently using email and prints (this was 2009),
- because they didn't need to share many photos.
- They weren't struggling enough to warrant learning (and teaching their loved ones) a new way to share photos.
This isn't problem validation but invalidation. Ouch!
If I had explored other adjacent jobs (to be done) with photos during my interviews, I would have learned that what they were struggling with at the time wasn't sharing photos but backing them up for posterity.
I did stumble into this problem accidentally in a subsequent customer conversation, which led to a problem positioning pivot that reversed my dismal early adoption rate. Had I discovered this sooner, I would have saved four months of building something I thought people wanted on a false positive problem validation.
Since that experience, I no longer attempt to validate problems this way but rather use what I like to describe as a backdoor approach to uncovering problems worth solving using the process outlined above.
Understanding your customer’s problems better than they do grants you superpowers. You’re seen as an expert, and building the right solution comes a lot easier.
