Product Discovery addresses 4 types of critical risks as discussed in Understanding the Four Risks in Product Development. The objective is to collect evidence that a solution to be developed later during Product Delivery will actually solve the customer's problem.
Later chapters will go into more detail, for now let's quickly sketch the 2 main phases required to build successful products:
<aside> 💡 Figuring out what to build with the primary objective of deciding for the right solution to a relevant problem.
<aside> 💡 Actually building it with the primary objective of focusing on building the solution right.
The focus during Product Discovery is on fast learning and validation of ideas.
The focus during Product Delivery is on predictability, quality and a repeatable process.
Ideally, a cross-functional product team jointly works along both phases. Also, both are more or less parallel activities even though, when the teams are focused on getting this done, their full attention shall go towards delivery while at a different point in time they will dive into discovery. So even engineers shall stay engaged with ongoing discovery even though probably to a lesser extent that Product Manager and Product Designer.
While this picture may look oversimplified, the key message for now is that both are continuous work streams. To be considered as a conceptual model, the exact implementation will vary depending on circumstances:
I emphasize to product people all the time that there is no single product discovery process just as there is no single product development/delivery process. There are many different discovery processes, all for different situations.
Marty Cagan: Process vs. Model
To get a bit more realistic picture, check out dual track agile as depicted by Jeff Patton where he refers to both tracks as Discovery and Development:
Some key aspects to note here: