To quote John Dewey, “A problem well stated is a problem half solved.” This quote highlights that understanding the problem requires much understanding, empathy, and hard work. The problem is part of an elaborate, interrelated model of situation, user, system, outcomes, and goals. Understanding all the elements and their connections enables Scrum Teams to build the right thing. It also allows Product Owners to prioritize the Product Backlog, create product roadmaps, and ultimately deliver the most value.
Requirements engineering is the discipline of defining the problem and what the solution needs to do to satisfy it. Since 2000, the tools and ultimate philosophy of creating requirements have evolved from a static, activity-focused approach to one that is more holistic but also incremental. Design Thinking and User Experience disciplines have influenced how Scrum Teams think about requirements.
Product people use product discovery, while software and systems people use requirements engineering. However, the two bodies of knowledge are ultimately concerned with the same outcome: great products that deliver the most value based on the economics of the situation.
Product Discovery is the discipline of discovering the problem we are trying to solve, and it is the process of discovering valuable outcomes for the user, customer, and other stakeholders. I like Tim Herbig's definition of product discovery.
At its core, Product Discovery is the evidence-informed process of reducing uncertainty as you find problems worth solving and solutions worth building. It emerges through a series of nonlinear activities, conducted as a cross-functional team.
The definition highlights some key ideas:
- Evidence Informed - Notice the avoidance of the term based. Evidence will inform the Scrum Team in pursuing value, but ultimately, people will make decisions. Evidence combined with other things will drive any decisions. However, evidence is still crucial in discovering value.
- The activities are nonlinear - In the 1980s, linear, waterfall approaches drove projects' “understanding” phase. For example, you created a use case, you then built the realization, etc. The reality is that many different activities inform the Scrum Team's understanding of the work, and those activities happen throughout. Activities inspire other activities as the team strives to uncover value.
- Cross-functional teams - In the 1980s, a separate team or specialist usually did requirements and discovery. The specialist or other team then documented these findings, which were given to the development teams to work on. With the impact of digital technology, the process is not discrete, handoffs are error-prone, and the process requires many different skills.
The phrase “Product Discovery” seems to imply that we are discovering products. But it describes any discovery activity for products. That means it can sometimes be significant things, like products or major changes, or small things, like a new field on a form. Yes, the significant things require more work, but the small things require some level of discovery and validation, too. We often quickly jump to solutions when dealing with small things, which can ultimately undermine the whole product as no one asks the simple question “What problem are we solving?” and “What is the cheapest way to validate the solution?”.
Product Discovery with Scrum requires validation. This is delivering something to improve our understanding, answer the question of value, resolve assumptions, and prove our Increment is valuable. Please note that when I say delivery, I am using the term to describe work, not just work on software or a physical product. Discovery without validation is not really “discovery” at all. Evidence, as Herbig describes, is crucial. Of course, that evidence may already be present in some form, so the work may focus on uncovering evidence rather than creating experiments to find it. For example, evidence regarding current website usage or observations of people using the product, or not using the product. However, building evidence always requires work, even if you are not creating a new feature to set an idea. Also, getting the Scrum Team involved builds lots of shared learning.
There are a lot of myths concerning the role of discovery in Scrum, I will explore them in my next blog post.