Teresa Torres is a thought leader in the product space who focused specifically on Product Discovery. She recently published Continuous Discovery Habits. Her ideas can be considered as a mental model combining all the different aspects and tools around Product Discovery.
In a nutshell, in the past decades Product Delivery has improved massively. The industry moved from annual releases to quarterly releases to night builds to continuous integration. We measure code quality, bug rates, story points, team velocity, and many more.
But for Product Discovery?
How do we know if we are doing a good job?
Teresa Torres, https://www.youtube.com/watch?v=l7-5x0ra2
In other words, how do we know whether we actually build the right things, the things that bring value to customers and business outcomes to the company? How do we know before spending huge budgets and failing very late?
The following is a quick excerpt from a blog post by Teresa Torres. For the full story check
Product Managers and Product Owners: What's the Difference? | Product Talk
Or watch Teresa speak at PRODUCTIZED:
But here's the key essence in brief:
Product Management back in the previous century started very much as a discipline where business stakeholders told Product Managers about the needs, Product Managers defined the requirements and then handed over to a separate team. So
Agile methodologies, most notably Scrum introduced the Product Owner role but also pulled the customer in. What's more, short iterations in sprints aimed at fast feedback loops — while it is questionable whether in all circumstances a business customer will join 2-weekly sprint reviews.
(Personally, I have experienced that more on a quarterly level.)
We still have the product person owning the requirements, here by writing requirements in epics and stories.
A major shift happens when teams move on to what Teresa Torres calls project-based discovery: have a product trio of Product Manager + Product Designer + Engineer actively involved in Product Discovery.
But there is still some kind of hand-over happening at the end of Discovery, in the form or written requirements to the delivery team.
As an extension to the above, and to bridge the gap into Scrum, often a PO gets introduced to "own the backlog of the team" as even the Scrum guide defines it.
While I, personally, have been working in environments with PM and PO separated, too, I don't quite see it as depicted — find it weird that an engineer, as a member of the product trio, is involved even "before" the PO...?
Finally, when we pull the entire team into Product Discovery, the loop is closed and discovery becomes a continuous process. The idea here is that the product trio is fully engaged and focused on discovery — but there are frequent touch points with the delivery team to get the entire team on board.
And maybe even more important: there is no separate requirements documentation. Rather, the same material is used throughout the cycle — the same story maps, prototypes, and designs.
Personally, what worries me a bit in this model is Teresa's statement
That means when they [the team] are available and they have time, they should be coming to our interviews.
Teresa Torres, https://www.producttalk.org/2020/10/product-managers-product-owners/
Given pressure on the delivery side, what if that is never the case, when they never find time to join in?!