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?
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".
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:
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.
Ping me on Twitter and let me know!
Hey there 👋 if you liked this post, you might also like Tability, a simple tool to help teams maintain the right focus.Try Tability for free →
Knowing your goals, and knowing how to track them are 2 different things.
There are a lot of tools you can use for your OKRs, but everyone of them is built different. We go through the different types of tools out there to help you pick what fits your goal tracking needs.
Learn how to write better objectives by understanding the difference between business and strategic objectives.