What would be the difference between an "opportunity" and a "problem?" Going off of Torres's definition of an opportunity as a customer need, pain point or desire, I'm having trouble seeing what would be added to the opportunity during the discover phase that would result in something different. In my mind, it feels like the "problem" would just be a re-wording of the "opportunity."
Opportunity is a problem worth solving. Not all problems are opportunities. If the problem is urgent, pervasive and people willing to pay for the solution - it is a great opportunity
I'm not sure about that. In OST you map all opportunities, then prioritize and test them. In particular, on of the assumptions may be that the opportunity is worth solving.
Taking into account you other answers, I guess we just mixed the Problem the Opportunity. In your model, Opportunity goes first, you log all of them, you prioritize and analized and then it became a validated Problem that worth solving. Basically the same approach. I just used the Pragmatic Institute terms/methodology
This question definitely derives from the double diamond perspective and your answer of "draft" and "more defined" is the direction that my mind was going as well. For me and my team, it can be difficult to recognize just when your opportunity has been "more defined" to the extent that we can consider it a problem to solution. That said, I recognize that we're fairly light on the discovery aspects of the double diamond perspective. Our "prototyping" is done in production, I run weekly customer interviews but am still working on gaining insight into specific problems (vs finding more opportunities), and we use data analytics more retroactively (once something is released we measure the impact).
„The first truth is that at least half of your ideas are just not going to work” - Marty Cagan, Inspired"
I bet Mr. Cagan toned down here. I guess that 99% of ideas do not work. What does "going work" in this context meant? Actually, it is all about making more revenue>profit (to grow or stay afloat by providing more value to customers and retaining them).
Now let's imagine there is a genius at product management who can come up with dozens of workable ideas, implement them and generate ever greater growth and profit. Each quarter they can discover several opportunities and implement solutions. They are a great visionary and innovator for a rapidly growing company.
If so, Pawel, then my question is: how many "workable" solutions can a good product manager/team ideate and implement every month/quarter/year? Is there any benchmark, and is that (number of ideas, implementations, impact) a good indicator to measure a PM's performance?
Later Marty specified that good teams assume at least 75% of those ideas won't perform as they hope. Many require further iterations.
This statement is in the context of continuous product discovery, so I'd say the "idea" means every single feature. It's uneasy to map it to a specific revenue / growth / or profit, as those are high-level metrics a product team is unlikely to influence directly.
An average team can deliver something like a few features / 2 weeks, but that's highly context-specific. You definitely shouldn't benchmark the number of features. What matters is whether those features solve problems and drive the desired outcomes.
I can imagine a team delivers a single high-level idea during an entire quarter. The idea consists of 2-3 features. And it drives all the desired outcomes.
Thanks for the article. I hope this message finds you well.
In Exploring Problem Space, we can explore problem in 5 ways. (Performing customer interviews, Learning from usage analytics, Learning from data analytics, Leveraging other tools and
Mapping opportunities)
Except for the last one, that the others are validated with analytics data or user interviews etc. Opportunity mapping, on the other hand, seems to me more like writing our assumptions, like problem ideas without any evidence. Don't we need the first 4 in the list to validate problems on opportunity mapping that we write as an assumptions?
What are the steps after Opportunity mapping? Could we jump on solution space directly without any validation with user inout or data?
The Product Discovery resembles a typical startup founder's routine. That brings me to the point that the founders should be very good in such activities. Actually, any product that is developed in a company is a “mini startup” that should meet the product-market-feet on its micro level. So, applying the lean startup methodology coupled with startup founder mindset is crucial.
Thanks, Pawel, I really enjoyed this. As an addition to your read materials I recently read a Jobs-To-Be-Done book that builds on Tony Ulwick's work called When Coffer and Kale Compete by Alan Klement. If anyone is keen to keep exploring JTBD It's a great book to read and I think it used to be available to read it online for free.
What would be the difference between an "opportunity" and a "problem?" Going off of Torres's definition of an opportunity as a customer need, pain point or desire, I'm having trouble seeing what would be added to the opportunity during the discover phase that would result in something different. In my mind, it feels like the "problem" would just be a re-wording of the "opportunity."
Opportunity is a problem worth solving. Not all problems are opportunities. If the problem is urgent, pervasive and people willing to pay for the solution - it is a great opportunity
I'm not sure about that. In OST you map all opportunities, then prioritize and test them. In particular, on of the assumptions may be that the opportunity is worth solving.
https://www.productplan.com/glossary/opportunity-solution-tree/
In a new picture uploaded Today I do not use this term. What's your opinion.?
Taking into account you other answers, I guess we just mixed the Problem the Opportunity. In your model, Opportunity goes first, you log all of them, you prioritize and analized and then it became a validated Problem that worth solving. Basically the same approach. I just used the Pragmatic Institute terms/methodology
I can see you renamed Opportunity to General Problem:)
That's connect, Chris. There are two perspectives mixed in this picture, and they do not match perfectly. Let me think about it.
My first answer (from the double diamond perspective):
- Opportunity on the left - every "draft" item (problem / need / desire)
- Problem in the middle - well understood, defined and validated Opportunity
But I'm not fully satisfied with this answer. I'll try to improve the picture, to make it more clear and product-centric.
What do you think?
This question definitely derives from the double diamond perspective and your answer of "draft" and "more defined" is the direction that my mind was going as well. For me and my team, it can be difficult to recognize just when your opportunity has been "more defined" to the extent that we can consider it a problem to solution. That said, I recognize that we're fairly light on the discovery aspects of the double diamond perspective. Our "prototyping" is done in production, I run weekly customer interviews but am still working on gaining insight into specific problems (vs finding more opportunities), and we use data analytics more retroactively (once something is released we measure the impact).
This is really helpful, thank you!
Hi Chris, I improved the picture. I hope it's clear now :)
@Pawel
Thanks for the article! FYI, there is a small typo towards the end, "Product-Makret Fit"
„The first truth is that at least half of your ideas are just not going to work” - Marty Cagan, Inspired"
I bet Mr. Cagan toned down here. I guess that 99% of ideas do not work. What does "going work" in this context meant? Actually, it is all about making more revenue>profit (to grow or stay afloat by providing more value to customers and retaining them).
Now let's imagine there is a genius at product management who can come up with dozens of workable ideas, implement them and generate ever greater growth and profit. Each quarter they can discover several opportunities and implement solutions. They are a great visionary and innovator for a rapidly growing company.
If so, Pawel, then my question is: how many "workable" solutions can a good product manager/team ideate and implement every month/quarter/year? Is there any benchmark, and is that (number of ideas, implementations, impact) a good indicator to measure a PM's performance?
Thank you.
Later Marty specified that good teams assume at least 75% of those ideas won't perform as they hope. Many require further iterations.
This statement is in the context of continuous product discovery, so I'd say the "idea" means every single feature. It's uneasy to map it to a specific revenue / growth / or profit, as those are high-level metrics a product team is unlikely to influence directly.
An average team can deliver something like a few features / 2 weeks, but that's highly context-specific. You definitely shouldn't benchmark the number of features. What matters is whether those features solve problems and drive the desired outcomes.
I can imagine a team delivers a single high-level idea during an entire quarter. The idea consists of 2-3 features. And it drives all the desired outcomes.
Got it, thanks, Pawel.
Hi Pawel,
Thanks for the article. I hope this message finds you well.
In Exploring Problem Space, we can explore problem in 5 ways. (Performing customer interviews, Learning from usage analytics, Learning from data analytics, Leveraging other tools and
Mapping opportunities)
Except for the last one, that the others are validated with analytics data or user interviews etc. Opportunity mapping, on the other hand, seems to me more like writing our assumptions, like problem ideas without any evidence. Don't we need the first 4 in the list to validate problems on opportunity mapping that we write as an assumptions?
What are the steps after Opportunity mapping? Could we jump on solution space directly without any validation with user inout or data?
Hi Canan, I explained it thep-by-step here: https://huryn.substack.com/p/the-4-steps-of-continuous-product Let me know if it helps :)
Great work Pawel. I like the idea that you test the riskiest assumption instead of all assumptions. Otherwise it would be take a looong time!
Great article, Pawel. Thank you!
The Product Discovery resembles a typical startup founder's routine. That brings me to the point that the founders should be very good in such activities. Actually, any product that is developed in a company is a “mini startup” that should meet the product-market-feet on its micro level. So, applying the lean startup methodology coupled with startup founder mindset is crucial.
Pawel, do you agree?
Thanks, Pawel, I really enjoyed this. As an addition to your read materials I recently read a Jobs-To-Be-Done book that builds on Tony Ulwick's work called When Coffer and Kale Compete by Alan Klement. If anyone is keen to keep exploring JTBD It's a great book to read and I think it used to be available to read it online for free.