How to validate a problem with 2 simple questions

Most of us can't help drafting a solution in our heads whenever we hear about a problem. And most of us also know that it'd be dangerous to go ahead with it. We have just one possible solution (which can be quite blurry), and it's best to ask others before we go about implementing it.

But what do we ask exactly?

Don't seek feedback on your solution

A common mistake is to ask a question that looks like this 👇

"Would you use <solution> to solve <problem>?"

This type of question focuses on your blueprint, without looking at whether or not <problem> is a big enough pain. It skips the validation of the issue entirely. What happens next is usually a back and forth on what could be tweaked on the solution to make it work—and the worst part about it is that it can be an exciting chat!

But you'll come out of it with the illusion that you have a <problem> worth solving. In the words of a certain VC: "wrong".

Seek stories, not feedback

It's necessary to seek feedback on implementation once you know what issue you should tackle. But you should start by seeking stories rather than features in the early days of product discovery. A better question would be 👇

"What are your thoughts on <problem>?"

This is an open-ended question that can go anywhere. It might get annoying for you because <solution> might never come up, or they might just end the conversation right away by answering "not much". But that's data. If no one has anything to say, then perhaps it's not that big of an issue.

An even better approach would be to elevate the conversation to the situation where <problem> might occur (<job to be done>). So your question could be:

"Tell me about <job to be done>?"

The great thing about this question is that it'll help you get a better picture of the issues surrounding your problem. It will allow you to:

• Understand the stack ranking of pains
• Refine your mental model
• Get a better sense of the triggers (super important!)

We're in the era of outcome-driven teams, and we hear a lot about the importance of metrics and clear goals. It can sometimes push us to narrow down our questions to get clear-cut answers. But, we must not lose our ability to explore with open conversations.

This is suck a common communication issue that there's even a Wikipedia entry for it called the XY problem.

Have any questions or feedback?

Ping me on Twitter and let me know!