In this post you will discover what Product Discovery is and how to integrate it into your product development processes. The article is divided into two parts: the first is about theory and method, and in the second part we focus on team organization.
Dealing with Product Discovery phase of a software project
The first time I read this expression I honestly didn't quite understand what it was and what it was for.
"Product discovery is about coming up with something that is worth building and delivering. Very specifically, the output of product discovery is a validated product backlog."
I discovered it on SVPG (thank you Marty, without you I don't know how I would have understood how Product Management works) and found it very interesting, but I was really struggling to understand how I could apply it to my product and my team.
I had my nice Product Backlog full of super precise stories with perfect acceptance criteria and specifications. Some stories had already been weighed to perfection by developers and designers who had meticulously calculated how long they would take.
We were a perfect, well-oiled Feature Factory: organized as best we could to analyze, design, develop, and send into production whatever features were decided upon.
It was very difficult to understand the new Paradigm. After all, we were past the start-up phase: we knew exactly what we had to do.
It was false.
It was too hard to accept that everything in the backlog was just and only a set of assumptions, and that even though we were now past the Start-up phase, we had no idea whether feature Y, or redesign X would have the impact we imagined.
We were using Scrum, and that seemed to be enough. On Agile methodologies, since we talk about them so much here, a clarification is necessary.
Agile, Product Management and Product Discovery phase
Agile and the various methodologies like, Scrum and Kanban, are great project management tools. You definitely need to know them, and they are an important part of your work, but they have very little to do with Product Management.
Being able to organize a team or prepare a Sprint is the basis, you need to know how to do that. Period. But that is not what makes the difference.
The difference in a good Product Manager is made by: the Outcome he or she is able to generate by working with the team, The Why he or she works on, the problem he or she chooses to solve, the information he or she is able to pull out of users, how he or she communicates and negotiates with stakeholders (mostly!), the metrics you choose to move, etc.
It's not enough to use Agile frameworks: you can do the best estimation ever or be a black belt in sprint planning but if you don't systematically validate everything you want to take into development and then into production, you're just doing good project management.
The strangest thing is that most teams are aware of this, but there is always an excuse to skip the validation part:
- We are few in number (you may have heard this dozens of times in teams of 3, 30, or 300 people).
- We have experience. We know what the user wants.
- There is no need.
- We are late.
Mindset and Product Discovery
Before proceeding for me, it is very important to remind you that it is always a matter of mindset and awareness: if you and your team don't accept that everything you have in mind to release are just ideas and therefore need to be validated first, there is no point in your continuing to read on.
I have seen too many great ideas that made so much sense (to us) have zero impact on users.
What matters is the time you take to figure out if it makes sense to take an idea into production, versus the metrics you want to impact.
What is Product Discovery?
Product Discovery is a set of techniques and processes whose ultimate goal is to reduce the risk of failure in the development of a digital product.
There are different types of risks you face when creating new products. Here are a few:
- We want to solve a problem that no one cares about
- The problem is important but to very few people
- We are implementing a solution that is very complicated to use
- We are designing a product whose implementation may require too many resources
- Problem and Solution work, but the business model is not sustainable
It is simple: if you are doing things for the first time, the risk that you are getting things wrong is very high. Also, even if in the discovery processes you will have found ideas/features/problems that make sense to move forward on you know that several Iterations will be needed to create something that really has impact at scale.
Integrating Product Discovery into your processes will help you figure out which path to follow while wasting as little as possible. As usual, it can be done either using in-house resources, either with the help of the discovery phase services for product development.
If we were to summarize to the fullest we could say that the Outcome of Product Discovery is a greater understanding of the customer, reminding us that only and only by starting with the customer will our Product Backlog make sense.
Product Discovery, User Story and Product Backlog
One of the parts that left me most in doubt in the past was the relationship between Product Discovery, User Story, and Product Backlog, i.e., what comes first?
Later you will see some tips on how to organize the work, but to simplify we can say that before writing a User Story on the Product Backlog we should validate it with Product Discovery.
We need to make sure that this information is true or at least we need to understand what is the risk we are incurring when we send such a feature into development.
The main problem with implementing Product Discovery
The main Problem I find is not so much the lack of understanding of how important Product Discovery is, only a fool would think it is useless, but the way it is implemented.
Instead of using one or two people working on a prototype for a couple of weeks, companies use an entire team of engineers to develop, test, and release the product into production. This is why it often takes a large number of releases to get a product that makes sense.
companies typically use the development team to build an extremely expensive prototype and use their real customers as unwitting testers.
The goal of this post is just to give you two practical examples that can help you organize your team for maximum impact.
Agile Dual Track
Simply Discovery and Delivery happen in parallel in the same sprint, flow or release.
This solution makes sense if you have larger and especially more mature teams in terms of both delivery and discovery experience. One Team or part of a Team (we'll see now) tries to figure out what makes sense to bring into Backlog, the other part instead deals with developing what's in Backlog.
This illustration by Jeff Patton makes the point perfectly.
The Lean Value Tree
What, in fact, is being generated? The Lean Value Tree.
- A visual tool that makes it easy to get value-based strategy from plans.
- Allows leaders and teams to structure and manage options for changes and improvements.
- It provides an effective way to share and analyze desired outcomes, examine risks and opportunities, and continually redefine what is needed.
- It is based on the idea of prioritizing outcomes (not features) that introduce optionality as a crucial element of planning.
- Each aspect of the tree contributes to achieving the main vision through experiments directed at producing behavioral changes.