Thanks Ian for sharing these frameworks. I especially liked the first two, very helpful! These tools help bring form and structure to the idea instead of dealing with it abstractly in your head or spread out in various notes. As you said in the audio, some of these might be more helpful for a team compared to a solo founder or two.
I was also inspired by the Basecamp example you mentioned about understanding the context of "When" a user decided to take an action and why they did it instead of solely relying on the user assumption of what they think they need. The team ended up making just a notification rather than a complex new feature!
I will make sure to check the mattress interview that you specifically recommended and the other one by Des Traynor. Thanks.
Love the point that the problem brief section should be devoid of solutions. I feel that a lot of people (myself included at times) already have some solution in their head while describing the problem, and this limits the variety & creativity in solutions.
That was the changing point for me as a PM when I realized that giving my team just the context and lots of it was a far more powerful action for creating the right outcomes.
I think as PMs, we have a decent level of product intuition of what the solution can be. Still, imo we should focus more on empowering our designers/engineers to discover the right solution. We can still use our product judgment but hold it back until a little later in the process.
Thanks Ian for sharing these frameworks. I especially liked the first two, very helpful! These tools help bring form and structure to the idea instead of dealing with it abstractly in your head or spread out in various notes. As you said in the audio, some of these might be more helpful for a team compared to a solo founder or two.
I was also inspired by the Basecamp example you mentioned about understanding the context of "When" a user decided to take an action and why they did it instead of solely relying on the user assumption of what they think they need. The team ended up making just a notification rather than a complex new feature!
I will make sure to check the mattress interview that you specifically recommended and the other one by Des Traynor. Thanks.
Love the point that the problem brief section should be devoid of solutions. I feel that a lot of people (myself included at times) already have some solution in their head while describing the problem, and this limits the variety & creativity in solutions.
That was the changing point for me as a PM when I realized that giving my team just the context and lots of it was a far more powerful action for creating the right outcomes.
I think as PMs, we have a decent level of product intuition of what the solution can be. Still, imo we should focus more on empowering our designers/engineers to discover the right solution. We can still use our product judgment but hold it back until a little later in the process.
Also a great post from Paul Adams on Product Judgement - https://www.intercom.com/blog/product-judgment/