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:
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
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
… 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:
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
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:
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:
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:
… 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
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]
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
Below is an attempt to merge Teresa Torres’ Opportunity Solution Tree with the strategy-discovery-delivery map:
- 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