Product Discovery • Projekt.dk

Modern product-led organizations with a strong product culture will typically apply what has come to be known as dual-track Agile, each track with a specific purpose:

Development work focuses on predictability and quality. Discovery work focuses on fast learning and validation. Discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking

Jeff Patton

All organizations, not restricted to the product-led ones, want to be effective and efficient. How they do it depends on their context and business model. For the modern high-tech product organization, the dual-track Agile approach has become one of the Good Practices (hard to claim any practices to be “best”).

We’re running Scrum and have people equipped with all sorts of Agile certifications, therefore we’re super good at Product Discovery! In fact, we’ve engaged a number of Agile Coaches to do even better!

You might actually be super good at Product Discovery, but it is not due to Scrum (or e.g., Kanban for that matter) and probably not due to your Agile Coaches as expressed by Marty Cagan:

… the vast majority of Agile coaches don’t have experience with tech-product companies, so their experience is limited to delivery. Therefore, they would more accurately be considered Agile delivery coaches. They understand the engineering and release side of things, but not the discovery side of things.

Discovery coaches are typically former product managers or product designers and they have usually worked for leading product companies. So they are able to work side by side with actual product managers and designers – not just reciting Agile platitudes, but showing the team how to work efficiently.

It is hard for me to imagine an effective discovery coach who doesn’t have first-hand experience as a product manager or product designer at a modern product company.

Marty Cagan, INSPIRED p. 289-290

Melissa Perri follows suit, pointing-out that the adaption of Agile is not the same as getting great at product management:

Many companies … have eagerly adapted Agile, thinking it was a silver bullet for creating more value in software, only to be disappointed. Why? Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management.

Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset.

Melissa Perri, Escaping the BUILD TRAP p. 26

Teresa Torres starts her book, Continuous Discovery Habits with the same point:

All product teams do a set of activities to decide what to build and then do a different set of activities to build and deliver it. While you’ll learn that these activities can and should overlap and interweave with each other, the work that is required to do each is fundamentally different.

… many companies put a heavy emphasis on delivery – they focus on whether you shipped what you said you would on time and on budget – while under-investing in discovery, forgetting to asses if you built the right stuff.

Teresa Torres, Continuous Discovery Habits p. 13-14

A lot has been and is being written about the Development / Delivery track. This post will take a swim in the pool of Product Discovery Techniques.

Marty Cagan sums-up the purpose of Product Discovery:

… the purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production-quality product, it won’t be wasted effort. And this is why we have so many different techniques in product discovery.

…

Much of the key to effective product discovery is getting across to our customers without trying to push our quick experiments into production.

… If you want to *discover* great products, it really is essential that you get your ideas in front of real users and customers early and often.

If you want to *deliver* great products, you want to use the best practices for engineering and try not to override the engineers’ concerns.

Marty Cagan, INSPIRED p. 163

If you haven’t already done it, I suggest reading the previous article From Vision to Delivery and Outcome in the product-led organization giving you a framework of reference before moving on.

The primary inspirational sources for this post

You’ll find a growing number of books and even more on-line articles on the topic of Product Discovery. In this post I’ll primarily seek inspiration in the following books:

The Product Manager

Before jumping into the pool of Product Discovery techniques, lets take a step back understanding the realm of Product Management:

At the heart of it we’re finding exactly the Product Discovery discipline being where the modern Product Manager will spend a significant amount of time. Marty Cagan has repeatedly made it clear, that the Scrum Product Owner role is only a fraction of much larger role as Product Manager. Melissa Perri agrees:

… people usually become confused between what Agile calls *a product owner* and *a product manager*.

When you look at the role of the product owner in most Scrum literature, the three responsibilities of the position include the following:

- Define the product backlog and create actionable user stories for the development teams
- Groom and prioritize the work in the backlog
- Accept the completed user stories to make sure the work fulfills the criteria

… it leaves lots of questions unanswered and these questions are important for creating successful products:

- How do we determine value?
- How do we measure the success of our products in the market?
- How do we make sure we are building the right thing?
- How do we price and packet our product?
- How do we bring our product to market?
- What makes sense to build vs buy?
- How can we integrate with third-party software to enter new markets?

Product ownership is just a piece of product management.

… product owner is a *role* you play on a Scrum team. Product manager is a *career*

If you take your Scrum team away, and Scrum as a process, you are still a product manager. Product management and Scrum can work well together, but product management is not dependent on Scrum. This role should exist with any framework or process …

Melissa Perri, Escaping the BUILD TRAP p. 37

Product Discovery principles

In chapter 33 of INSPIRED, Marty Cagan recommends following a set of core discovery principles:

- It’s our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all modern product.
- The hardest part of all is creating the necessary value. This is generally where we’ll need to spend most of our discovery time.
- As hard and important as engineering is, coming up with a good user experience is usually even harder, and more critical to success.
- Today, we know that the technology drives (and enables) the functionality as much as the other way around. We know that technology drives (and enables) design. We know that design drives (and enables) functionality. The point is that all three of these are completely intertwined. This is the single biggest reason we push so hard for the product manager, product designer, and the tech lead to sit physically adjacent to each other.
- The most important thing is to know what you can’t know (which is exactly what Melissa Perri points to above).
- We must validate our ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, and not after.
- Our goal in discovery is to validate our ideas the fastest, cheapest way possible. Discovery is about the need for speed.
- We need to validate the feasibility of our ideas during discovery, not after (see later – can we build it?)
- We need to validate the business viability of our ideas during discovery, not after.
- It’s about shared learning. One of the keys to having a team of missionaries rather than a team of mercenaries is that the team has learned together.

In their book Product Discovery: A no-nonsense guide to building effective products and services, Marcus Castenfors and Martin Christensen provide us with their set of guiding principles (structured in the same way as the original Agile Manifesto).

These principles are fully in line with and support the other authors.

The British Design Council’s framework for innovation – also known as the Double Diamond model – applies the same principle as the Dual-track Agile model: Separate focus on Problem and Solution. In this illustration of the Double Diamond model, the iterative part has been made explicit:

Some teams are able to switch context between the problem and solution spaces within the same sprint. Other teams prefer “clean” problem or solution sprints.

The toolbox of Product Discovery techniques

Let’s start with a disclaimer: the breadth and depth of Product Discovery techniques is not only huge – it is constantly evolving making it impossible to provide a full map of all current techniques in all types of industries and business models.

Here I’ll try to provide an overview of the commonly used techniques – most of which found in my inspirational sources.

The majority of literature on the subject circles around purely digital products. The thinking is however fully valid and relevant for multidisciplinary products, the point being that we recognize and respect the constraints imposed by the physical world (electronics, mechanics, environmental, logistics, production, supply-chain, health & safety, regulations, norms, standards, certifications …).

For (purely) digital products, Marty Cagan brings focus to four essential product risks. Here with a fifth risk-area added, related to the production and lifecycle of physical products:

1. valuable for the customer
2. usable for the customer as intended
3. feasible for us to build
4. viable for our business
5. feasible for us to produce and deliver the product (in serial production)

Through disciplined Product Discovery we want and need to gain insights and control over these five product risk areas, before investing heavily in the Development / Delivery of an actual product!

Now – let’s open the toolbox of Product Discovery techniques.

INSPIRED PART IV THE RIGHT PROCESS page 159-307

Marty Cagan has dedicated a significant part of INSPIRED to Product Discovery Techniques. I highly recommend reading the whole book. Here I’ll just scratch the surface.

DISCOVERY FRAMING TECHNIQUES

DISCOVERY PLANNING TECHNIQUES

DISCOVERY IDEATION TECHNIQUES

DISCOVERY PROTOTYPING TECHNIQUES

You might be wondering – what happened to Eric Ries’ classic The Lean Startup in the list of inspirational sources?

I’ve found it misleading when it comes to the notion of MVPs. Just to strengthen my point, here is a quote from Marty Cagan:

Eric’s book did a great deal to help product teams, and to me, it is a must-read book for all product people. But I think most people would likely admit that the concept of MVP has caused considerable confusion within product teams, and I spend a lot of my time helping teams get value out of this critical concept.

… while the P in MVP stands for *product*, an MVP should *never* be an actual product (where product is defined as something your developers can release with confidence, that your customers can run their business on, and that you can sell and support).

The MVP should be a *prototype*, not a product.

…

I find that using the more general term *prototype* makes this critical point clear to the product team, the company, and the prospective customers.

… in this book I talk about different types of *prototypes* being used in discovery and *products* being produced in delivery.

Marty Cagan, INSPIRED p. 29-30

DISCOVERY TESTING TECHNIQUES

Testing Usability
Testing Value
Demand Testing Technique
Qualitative Value Testing Techniques
Quantitative Value Testing Techniques
Testing Feasibility
Testing Business Viability

TRANSFORMATION TECHNIQUES

Teresa Torres in Continuous Discovery Habits

First of all – if you’ve not yet read Teresa’s book, I highly recommend doing so. It is impossible to give full credit to this important book here. I’ll just convey a couple of high-lights.

The Opportunity Solution Tree [OST]

Opportunity solution trees are a simple way of visually representing the paths you might take to reach a desired outcome.

The root of the tree is your desired outcome – the business need that reflects how your team can create business value.

Next is the opportunity space. These are the customer needs, pain points, and desires that, if addressed, will drive your desired outcome.

Below the opportunity space is the solution space. This is where we’ll visually depict the solutions we’re exploring.

Below the solution space are assumption tests. This is how we’ll evaluate which solutions will help us best create customer value in a way that drives business value.

Teresa Torres, Continuous Discovery Habits p. 30

You might recall the mapping from product strategy over product discovery to product delivery in the earlier post.

Below is an attempt to merge Teresa Torres’ Opportunity Solution Tree with the strategy-discovery-delivery map:

Opportunity solution trees have a number of benefits. They help product trios (ed. : Product Manager, Product Designer, Engineer):

- Resolve the tension between business needs and customer needs
- Build and maintain a shared understanding of how they might reach their desired outcome
- Adopt a continuous mindset
- Unlock better decision-making
- Unlock faster learning cycles
- Build confidence in knowing what to do next
- Unlock simpler stakeholder management

Teresa Torres, Continuous Discovery Habits p. 30

To get the full story on how to leverage the use of the Opportunity Solution Tree, go read Teresa’s book.

Wrap-up

Yes – (continuous) Product Discovery is definitely a deep rabbit hole in its own right. The good news is that you’ll find a lot of helpful material out there to guide you.

Happy Discovery!