Oh this is nothing new “ uncover a high-priority problem that a significant segment of specific customers are struggling to solve today.”
What’s really tricky is how that plays out in real life especially if, like many founders, the whole business idea was seeded as an insider’s pain.
I am my target audience so I know the pain.
Which is not always the case. And even if so, it’s more multi-faceted than expected so we are really dealing with a package of inter-related maybe problem that need a lot, a lot of work to transform into valid, usable problem statements.
I believe you shared how OpinionX discovered that after months of sticking with what you thought was THE right direction.
I am facing that right now, and need to get back to the drawing board (granted I have not started the real user interviews yet!)
Thanks again for another excellent article, so much learning here.
What's often the case for founders solving their own pain is that they know the problem exists in the market from their own experience, but the challenge is sometimes to find the beachhead customer segment that is CRAVING a solution to the problem as a top priority -- that is who you want to target as your Ideal Customer Profile.
I don't think I have saved these many articles of a single creator before. This was brilliant. It's a bit beyond my understanding but it was helpful nonetheless. I'll be coming back to refer your articles in the future.
I'm very grateful for comments like this Nino, thank you! I think I still have some work to do to simplify my writing and make the core ideas stand out clearer, so hopefully over time you'll find them easier and easier to understand and implement :)
Your writing is absolutely fine. The only reason why I didn't understand some parts is because I'm not from a sale or marketing background. You did a great job nonetheless.
"Match, Identify, Pitch, Assure" -- really great way to frame all of this. Big fan of splitting apart customer, product, and sales discovery.
What I am taking away is that when you perform discovery research, the context matters ALOT. More specifically the outcomes you wish to achieve. But it's tricky because the methodology & approach will be the same (talk to customers) and not knowing what you want to do with your findings can mess things up.
Quick question: Have you had any experience with JTBD (or outcome-driven innovation)? If so, how has it gone for you? If not, is there a particular reason why you stayed away from it?
100%, understanding the objective of your research sets the context for your customer conversation.
I've used JTBDs sparingly over the years (more when I worked on consumer research projects at Unilever than in software). Using the model from the infographic at the end of the post, I personally place JTBDs in the Market Context bucket in the same way I view things like use cases, goals and objectives, behavioral triggers, etc (things that cause a prospect customer to pursue a specific outcome).
My approach to JTBDs and its alternatives are relatively the same -- understand the frequency of the action, the value associated with it, and the most significant pains preventing them from accomplishing it to a sufficient standard today. That will help you answer questions like:
(1) Is this problem commercially viable to solve?
(2) Do I have a unique insight into how this could be solved?
(3) Can I feasibly build that solution?
imo the approach (ie. JTBDs) doesn't really matter as long as you're able to find solid answers to questions like these. For some scenarios, JTBDs might happen to be the best lens through which to view the problem, so I tend to keep it in mind overall but I don't stick to it ideologically :)
I've been trying to get to the essence of what "customer discovery" actually is. And what you've outlined above essentially spells that out. It can get confusing with all the different frameworks.
To me, and I would love your feedback on this, we:
1) Figure out the way the action is done currently
2) Figure out why the action is taken to begin with (the value)
3) Figure out if the action is done in different ways (in different contexts)
4) Figure out who is doing it
5) Figure out where it's not working (hard, slow, unreliable, expensive, etc...)
After we know all of that, we can move to product discovery and start building out solutions after assessing the 3 points you've outlined above.
And in the end, we want our customers to end up with a BETTER WAY to do [action]. Which the solution we provide helps to facilitate.
I sometimes use a slightly different set of 5 questions, which you can see in this case study of WeatherBill: https://www.opinionx.co/blog/deconstructing-a-successful-startup-pivot. As you said, the frameworks can end up being overwhelming and holding you back from making progress, so as long as you're doing the basics right then you're already 80% of the way there :)
On your last point, the one thing to keep in mind is that the "better way" needs to be better by the metric that they view the problem through. For example, there's no point in chasing cost if the issue is how slow the process is today.
Oh this is nothing new “ uncover a high-priority problem that a significant segment of specific customers are struggling to solve today.”
What’s really tricky is how that plays out in real life especially if, like many founders, the whole business idea was seeded as an insider’s pain.
I am my target audience so I know the pain.
Which is not always the case. And even if so, it’s more multi-faceted than expected so we are really dealing with a package of inter-related maybe problem that need a lot, a lot of work to transform into valid, usable problem statements.
I believe you shared how OpinionX discovered that after months of sticking with what you thought was THE right direction.
I am facing that right now, and need to get back to the drawing board (granted I have not started the real user interviews yet!)
Thanks again for another excellent article, so much learning here.
What's often the case for founders solving their own pain is that they know the problem exists in the market from their own experience, but the challenge is sometimes to find the beachhead customer segment that is CRAVING a solution to the problem as a top priority -- that is who you want to target as your Ideal Customer Profile.
I don't think I have saved these many articles of a single creator before. This was brilliant. It's a bit beyond my understanding but it was helpful nonetheless. I'll be coming back to refer your articles in the future.
I'm very grateful for comments like this Nino, thank you! I think I still have some work to do to simplify my writing and make the core ideas stand out clearer, so hopefully over time you'll find them easier and easier to understand and implement :)
Hey Daniel,
Your writing is absolutely fine. The only reason why I didn't understand some parts is because I'm not from a sale or marketing background. You did a great job nonetheless.
🫶
"Match, Identify, Pitch, Assure" -- really great way to frame all of this. Big fan of splitting apart customer, product, and sales discovery.
What I am taking away is that when you perform discovery research, the context matters ALOT. More specifically the outcomes you wish to achieve. But it's tricky because the methodology & approach will be the same (talk to customers) and not knowing what you want to do with your findings can mess things up.
Quick question: Have you had any experience with JTBD (or outcome-driven innovation)? If so, how has it gone for you? If not, is there a particular reason why you stayed away from it?
100%, understanding the objective of your research sets the context for your customer conversation.
I've used JTBDs sparingly over the years (more when I worked on consumer research projects at Unilever than in software). Using the model from the infographic at the end of the post, I personally place JTBDs in the Market Context bucket in the same way I view things like use cases, goals and objectives, behavioral triggers, etc (things that cause a prospect customer to pursue a specific outcome).
My approach to JTBDs and its alternatives are relatively the same -- understand the frequency of the action, the value associated with it, and the most significant pains preventing them from accomplishing it to a sufficient standard today. That will help you answer questions like:
(1) Is this problem commercially viable to solve?
(2) Do I have a unique insight into how this could be solved?
(3) Can I feasibly build that solution?
imo the approach (ie. JTBDs) doesn't really matter as long as you're able to find solid answers to questions like these. For some scenarios, JTBDs might happen to be the best lens through which to view the problem, so I tend to keep it in mind overall but I don't stick to it ideologically :)
Wow. Thank you for sharing that...
I've been trying to get to the essence of what "customer discovery" actually is. And what you've outlined above essentially spells that out. It can get confusing with all the different frameworks.
To me, and I would love your feedback on this, we:
1) Figure out the way the action is done currently
2) Figure out why the action is taken to begin with (the value)
3) Figure out if the action is done in different ways (in different contexts)
4) Figure out who is doing it
5) Figure out where it's not working (hard, slow, unreliable, expensive, etc...)
After we know all of that, we can move to product discovery and start building out solutions after assessing the 3 points you've outlined above.
And in the end, we want our customers to end up with a BETTER WAY to do [action]. Which the solution we provide helps to facilitate.
Does that make sense?
Those are 5 great questions to answer!
I sometimes use a slightly different set of 5 questions, which you can see in this case study of WeatherBill: https://www.opinionx.co/blog/deconstructing-a-successful-startup-pivot. As you said, the frameworks can end up being overwhelming and holding you back from making progress, so as long as you're doing the basics right then you're already 80% of the way there :)
On your last point, the one thing to keep in mind is that the "better way" needs to be better by the metric that they view the problem through. For example, there's no point in chasing cost if the issue is how slow the process is today.