Intro to Product Discovery

Intro to Product Discovery
The Design Academy

● Part 1: What is Product Discovery?
● Part 2: The when, how and who of Discovery?
● Part 3: How to balance Discovery & Delivery
● Part 4: Prioritising Discovery & Running Experiments
● Part 5: Recap, resources & reading
Workshop Overview

Part 1: What is Product
Discovery?

“Product Discovery describes the
iterative process of reducing uncertainty
around a problem or idea to make sure
that the right product gets built for the
right audience.”
Tim Herbig
What is Product Discovery?

Strategy
Discovery
Problem(s) to solve
Ideas to test (i.e. what to build?)
Delivery Solutions to build (i.e. how to build it?)
Customer Outcome (behaviour)
Business Outcome (Impact)
‘Empowered’
Product Team
Redgate
Customers

Team A
Delivery
Idea(s) Outcome
Time
Long lead time to validate (risk).
Fails to address customer problem.
Wasted design & development effort.
Release
Team B
Discovery
Validation done upfront, before build.
Limits waste by testing ideas early.
Less Agile, more Waterfall(?)
Delivery
Discovery
Delivery
Discovery
Team C
Ongoing, continuous validation.
Fail fast, learn quickly, waste less!
Increase the odds of success.
Discovery
Delivery
Discovery

“We can’t always be right, but at
minimum we can validate that
we’re putting our time and money behind
ideas that stand a reasonable chance of
succeeding.”
Jeff Patton

“Typically about 50% to 80% of all
software we ship fails to accomplish its
objectives.”
Marty Cagan

Discovery is how modern product teams
mitigate the risks of building out ideas that:
3. Don’t drive or enable our commercial objectives (viability).
1. Customers won’t use or value (desirability).
2. Technically we’re unable to implement (feasibility)

Discovery Delivery
Activities
“Is there a problem to be solved?” “Is it a good idea? What should we build?” “Is it driving the right behaviour(s)?”
Customer Interviews
Secondary Research
Analysis / Synthesis
Problem Framing
“How do we build the solution?”
Experimentation
Rapid Prototyping
Customer Validation
Concept Design
Build (Code + UI)
Release
Test
Iterate
Measurement:
Adoption,
Usage,
Feedback,
Sentiment
? ? ? ?
Problem Discovery Solution Discovery Build (Design & Code) Release (& measure)

Part 2: The when, how and
who of Discovery?

1. Whenever there is uncertainty about what to build, for whom and why.
2. When we’re falsely confident that our idea is a good one (is it…really?).
3. When we want to mitigate the costs of being wrong…and we’re wrong a lot (see Marty).
4. We should always be doing some amount of discovery work.
When should we do Discovery?
It’s all about reducing risk
and ensuring we spend time
on the most promising ideas.

“Discovery is needed anytime when there are many
unknowns that stop a team from moving forward.
Moving forward only on assumptions can be risky, as
the team may end up solving a problem that doesn't
really matter - wasting time, money, and effort.”
Neilson Normal
Group

“The most expensive way to test your
idea is to build production-quality
software”.
Jeff Patton

Discovery is as an ongoing and continuous set
of activities carried out by a product teams to
determine, to a degree of confidence, what to
build, before deciding how to build it.
What to build, before we build it!

How to do Product Discovery?
Product Discovery in a nutshell.
1
2
3
4
5
1. Strategic research, market signals and tech trends feed
into a backlog of ideas.
2. A Discovery team sets about exploring and validating a
number of possible ideas.
3. They discard those that are a poor fit and work up those
that are likely to have the greatest impact.
4. The best ideas win out, are shaped, scoped, and sliced
and added to teams’ delivery backlogs.
5. We design, build and release the solution in shippable
increments; iterating through rounds of user testing.

The ‘Core’ Discovery Team.
Concept of the ‘Core’ Discovery Team
sees PM, PD, TL (i.e. the PLT) act as
“permanent collaborators” to instigate and
lead the team's discovery efforts.
Who is involved in Discovery?

However, discovery is done best when practiced
as part of an integrated and continuous
approach to product development; where the
whole team is engaged to create better
outcomes.
Discovery as a team sport (?)

“Continuous discovery is: weekly touch
points with customers, by the team
building the product, where they conduct
small research activities, in pursuit of a
desired product outcome.”
Continuous Discovery
Teresa Torres

Part 3: How to balance
Discovery & Delivery

Without balance and recognising the
need to do some upfront discovery, it
can feel like you’re…laying the track at
the same time as deciding where to go
next!
Discovery provides direction
Balancing Discovery & Delivery

Discovery
Building the right
things and driving
better outcomes.
Delivery
Building them right
and creating high
quality output.
Make
assumptions
about
customer’s
problems and
our solutions.
We increase
the risk & costs
were our ideas
to fail.
We risk biasing
towards our
first, most
obvious
solution.
Default to
writing code:
an expensive
way to learn
whether we
were right.
We have no
way of testing
whether our
solutions work
at scale.
We fail to
realise the
outcomes we
sought to
drive.
We’re unable
to deliver any
‘feature
complete’
software.
We end up
with good
ideas that we
cannot execute
on.
We end up
building before
we know what
we should be
building.
Quality is low:
always building
to learn.
? ? ?
?
?
? ? ?
?
?

The discovery track focuses on producing,
testing, and validating product ideas.
The delivery track works on turning those
ideas into an actual product.
Dual-track Agile enables product teams to
work on research and product development
in parallel.
Dual-Track Development

Variants of Dual-Track also recognise the role
of discovery in exploring concepts/ideas.
Again, determining the general shape, scope
and success criteria of what teams intend to
build before they build it.
‘Shaping’ Solutions

Many organisations use the concept of an
upstream Kanban to help prioritise and
visualise the flow of work upstream i.e. the
knowledge work that precludes an
implementation.
Visualising Discovery

Discovery Delivery
Learn
Learning
Backlog
Product
Roadmap
Validate
Idea
A
Idea
B
Sprint
Backlog
OKRs
Design Build (UI & Code) Alpha/Beta
Product
Backlog
Release
Sprint
Backlog
Idea
C
Idea
A
Idea
B
Idea
C
Task
Solution
Opportunity
B
Opportunity
C
Opportunity
A
Solution Solution
Task Task Task
Task Task Task Task

“Speed is irrelevant if you are going in
the wrong direction.”
Mahatma Gandhi

Part 4: Prioritising Discovery &
Running Experiments

Whilst discovery is a fundamental part
of product development, like delivery, it
comes at a cost. As such, we should be
mindful of when, where and how best
we spend that effort.
Prioritising Discovery
Spending wisely?

It’s about being pragmatic and
using the right approach in the
right situation. Spending our
discovery efforts where it is
most needed.

“You don’t have to lick the pavement to
know it tastes like sh*t!”
Steve Pearce

A considered, scenario-based
approach to Product Discovery. One
size does not fit all!
1. Test it?
2. Built it?
3. Borrow it?
4. Bin it?
Pragmatic Discovery
Hypothesis Prioritisation Canvas (Jeff Gothelf)

“The most expensive way to test
your idea is to build production-
quality software”.
What’s the smallest, cheapest
experiment you can run to learn
if your idea is a good one?
So, if…
Then…
…an experiment!
…a response.
a. Stick
b. Twist
c. Pivot

We should design and scale our discovery
efforts & experiments relative to….
Scaling Experiments
….where we are in the process, in terms of
problem or solution space….
… and the level of risk associated with and
our confidence in a given idea.
A B

• Split into 3 groups and join activity Mural.
• Map methods to ideas on the scale.
• Use risk/certainty matrix to scale approach.
• After 15 minutes re-group and reflect.
Scaling Experiments (Activity)

Part 5: Recap, Resources &
Reading.

Recap & Resources
1. Discovery bridges the gap between product strategy and product delivery.
2. Discovery is about mitigating the risks of acting on what we think are good ideas.
3. Discovery is not a return to waterfall and aligns well with any Agile, iterative process.
4. Discovery is a series of activities the whole team should participate/engage with.
5. It’s important to strike a balance between discovery (next) and delivery (now).
6. Like delivery, we should spend our discovery effort wisely (our known, unknowns).
7. Discovery is about determining what we should build before we build it.

Shape Up (ebook)
Product Discovery: A Practical
Guide for Agile Teams (2020)
Introduction to Modern Product
Discovery
Recap & Resources
Jeff Patton
Teresa Torres Tim Herbig Marty Cagan

Intro to Product Discovery

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Intro to Product Discovery

Semelhante a Intro to Product Discovery (20)

Último

Último (20)

Intro to Product Discovery