The Essential Guide to

Product
Discovery
 Table of

Contents
PG. 3 Opening words

CH. 1 || PG. 4 The how and the what of

product development

CH. 2 || PG. 11 The age of product discovery

CH. 3 || PG. 15 A step-by-step guide for

conducting product discovery

CH. 4 || PG. 25 3 mistakes to avoid with

product discovery

PG. 29 Conclusion
 Opening words

The discovery cycle is the process of

actively capturing, researching, and
prioritizing user needs—as well as
collecting and validating solution ideas
for addressing them. It complements
the delivery cycle, which efficiently
transforms validated product ideas
into valuable product functionality.

Product discovery can be a touchy subject within the product

world. While many of us know that it’s important, it’s easy to
prioritize delivery and think discovery is a practice we can save
for another day. 

We have two goals for this eBook:

• To place product discovery in context: Why is it so

important right now?
• To provide you with a playbook: How do you conduct
better product discovery no matter where you are on your
journey today?


Without further ado, let’s get started.

OPENING WORDS
CHAPTER ONE

The how and the

what of product
development
What’s the point of optimizing the delivery of
software if we’re not delivering the right thing?
Quick! How many tools can you think
of that help teams manage how
software gets developed and delivered?

Now how many can you think of that

help not with managing how software
gets built, but deciding what gets built
in the first place?

5
 What’s going on here?

Take a look at when the

most popular tools in each
space were launched

How?
Agile planning
tools
1998 2002 2008 2011

2012 2013 2014

What?
Product
management tools

It seems that four years ago, we all finally realized: What’s the
point of optimizing the delivery of software if we’re not
delivering the right thing?

But it’s not that we never cared about deciding what to build.
It’s just that what has always lagged a little ways behind.

6
 so busy marketing at users and building hundreds
There’s nothing new of millions of dollars of infrastructure that they
about the “what” overlooked the fundamental needs of their target
market.
For over 25 years, we’ve had helpful frameworks
for discussing what users need and what to build $1.2 billion dollars later, they learned some of
to address those needs. This is no new concept. their early assumptions had been incorrect and
It was back in 1991 when IDEO began filed for bankruptcy in 2001 at the height of the
popularizing the notion of design thinking—using dot-com collapse.
rapid prototyping to iteratively uncover users’
And there wasn’t just a disconnect between
needs and design optimal solutions. Still, these
business models and user needs. It existed at the
methodologies were only used by isolated teams
feature level as well. In The Inmates Are Running
until more broadly adopted over a decade later.
the Asylum (1999), Alan Cooper makes an urgent
Indeed, the ‘90s were largely a time of optimizing call to refashion the feature-centric view of
marketing and engineering execution rather than product development, divorced of the needs
systematically validating user needs. This came at features were meant to address. 
a heavy cost. In the opening chapters of The Four
Steps to the Epiphany, Steve Blank details how His writings helped redefine the role of product
managers and solidified user experience design
WebVan, the early grocery delivery service, was
as a field in its own right.

How? What?
Building products the right way Building the right products

David Kelley founds IDEO to introduce

1990—1995
design thinking to the business
Ken Schwaber and Jeff Sutherland world; popularizes use of iterative,
pioneer “scrum” agile software 1991 intermediate solutions (prototypes)
development methodologies, as a means for better understanding
inspired by 1980s Japanese the problem at hand and the best solution
manufacturing breakthroughs to address it

Kent Beck
Kentdevelops Extreme
Beck develops Extreme
Programming at Chrysler.
Programming It
at Chrysler. It
embraces inevitable
embraces changes
inevitable in
changes in Webvan founded: It raised an
astounding $1.2 billion in startup
requirements by shifting
requirements to to .
by shifting 1996
shortershorter
development cyclescycles
development capital before folding in 2001 7
 Pets.com founded: It raised $300
1998 million in VC before closing in 2000

Dot-com bubble bursts due in

Agile Manifesto 2001 1999—2001 large part to internet retailers’
published fundamental misunderstanding of
user needs

Atlassian launches 2002

JIRA Outcome-driven innovation introduced by
Anthony Ulwick: users “hire” products to
achieve certain outcomes—to carry out
certain “jobs”. Clayton Christensen
Mary and Tom Poppendieck
popularizes this notion of “jobs-to-be-
coin “lean software
coin “lean software 2003
done” in his book Innovators Solution
development,”applying
development” applying lean
lean manufacturing
manufacturing processes from the
processes
Toyota from the Toyota
Production System to
Steve Blank publishes Four
Production System
software to
development
software development
2005 Steps to the Epiphany, detailing the
Customer Development framework,
where entrepreneurs “get out of the
building” to study user needs in the real world
GitHub launched. Within 2 years,
boasts 1 million code repositories
Eric Ries, once a student of Steve
2008 Blank’s at UC Berkeley, publishes The
Pivotal Labs agile consultancy
Lean Startup, further popularizing the
releases Pivotal Tracker, an
notion of failing fast with “minimum
internal project management tool
viable products”

Intercom (customer communication platform)

2011
re-popularizes jobs-to-be-done framework
Trello founded to bring in a series of popular blog posts
kanban style project
2013 and e-books
management to every team

Alexander Osterwälder and Yves

2014 Pigneur publish Value Proposition
Design; explore ways to identify user
pains/gains and map these to solution ideas

8
 As it sorted through the ashes of the dot-com More recently, we’ve seen a resurgence of
collapse, the tech industry was primed to interest in jobs-to-be-done with Intercom’s
reconsider the role of the product team. Who popular blog posts and eBooks (2013–present). 

Others have reframed jobs-

Without dedicated systems for managing the what, to-be-done to further refine
teams are more susceptible to losing focus, building the way we discuss what
users really need. In Value
the pet features of the highest-paid executive in the
Proposition Design (2014),
room or being swayed by the demands of their Alexander Osterwälder and
largest, loudest customers—even if doing so is less Yves Pigneur describe a
product’s core value
likely to help their product succeed in the long run.
proposition as a function of
the user pains it solves or
better to lead the industry’s recovery and a new the positive gains it provides. As they show,
paradigm shift than the guy known for his theory solving pains and delivering gains is the
that creative leaps come from destruction—  foundation of every business model.
Clayton Christensen. 

In Innovator’s Solution (2003) Christensen re-

popularized the notion that users “hire” products
to achieve some outcome, to get some “job”
“What” frameworks
done. His jobs-to-be-done approach serves as a
helpful framework for tailoring new features to
have advanced but the
users’ underlying needs—whether you’re making tools haven’t
software or milkshakes.
Returning full circle, the frameworks we now have
In the years that followed, Steve Blank worked to for discussing and optimizing both the how and
apply many of the same ideas that inspired agile the what of product development have advanced
methodologies (on the how side) to the what side. considerably over the past two decades. But tools
One of the core tenets in his for managing each have advanced
Customer Development framework at different rates. 
(2005) was eliminating wasted
Building shippable
effort (building features no one software is an As an industry, we’ve favored the
wants) by learning faster.
expensive way to how to the detriment of the what.
And that means that until now,
Eric Ries, a student of Blank’s at refine the product managers have managed
UC Berkeley, channeled these understanding of the complex process of deciding
ideas into The Lean Startup, what to build next using hacked-
expanding on Customer
what users need together spreadsheets, shared
Development by detailing specific docs, task management tools, and
practices startups (and any product team) can use systems for managing engineering, sales,
to iteratively test hypotheses while pivoting from marketing, and support data.
cheap prototypes to successful products.

THE HOW AND THE WHAT OF PRODUCT DEVELOPMENT 9

That’s a shame, because it means teams have getting shipped sooner, teams collect feedback in
collectively wasted hundreds of thousands of less time and use it to optimize what to work on
hours and billions of dollars developing next. 
underutilized features and products that failed to
live up to their potential. The how and the what are interrelated, after all!
All the same, building shippable software is an
Don’t get us wrong. Optimizing the how hasn’t all expensive way to refine your understanding of
been a waste. Efficient software delivery is not what users need. And even then, by limiting
inherently a bad thing. Being able to adapt to ourselves to learning from one product
changing requirements, collaborate seamlessly, improvement at a time, we risk being blinded by
and improve continuously have led to higher the haze of incrementalism, unable to see if we’re
quality software and more efficient, motivated working on the optimal product or feature set to
teams. And because product increments are begin with.

So how might we go about deciding what to build at the same time as

we’re optimizing how we build our products?
Head over to the next section to learn more.

RETURN TO CONTENTS
CHAPTER TWO

The age of
product
discovery
Why risk building the wrong feature if you can first
validate your understanding of the existing need and
the ideal solution?
 “There is nothing quite so useless as
doing with great efficiency something
that should not be done at all.”
Peter Drucker

There is a better way to discover what users who don’t take the time to uncover them are
really need without slowing down the efficient doing one of two things:
systems we’ve developed for delivering software.
• Making assumptions
• Encouraging developers to make
The answer is dual track agile.
assumptions (by passing them fuzzy
Consider the typical agile product team, with requirements)
product managers who:
In either event, they’re likely to get key details
• Process inputs like feedback and feature wrong, which threatens to waste the team’s time
requests  and degrade the quality of the product. Building
• Generate feature ideas based on user software, even efficiently, is an awfully expensive,
needs and strategic considerations frustrating, and suboptimal way of discovering
• Prioritize the most valuable ideas, pushing what users really need.
them to the dev team’s backlog
• Expensive because software is time-
• Discard low-value or infeasible ideas
consuming to code and maintain. Isn’t there
a faster, cheaper way to learn?
With just the top priority ideas on their plate,
• Frustrating because developers don’t
developers can deliver valuable features faster.
enjoy committing to build potentially
That means feedback can be collected sooner,
infeasible features with fuzzy requirements
helping the product team further fine-tune what
in tight timeframes, particularly when it
gets built.
might all be for naught
• Suboptimal because blindly iterating on an

But there’s a problem. arbitrary feature idea until it’s deemed

valuable means not spending that time
delivering another feature that is best
At the very least, we’re assuming user inputs can
aligned with the needs of your target
be neatly translated into requirements that
market and overarching product strategy
product can send to the dev team’s backlog.

In short, why risk investing in building the wrong

Often, they can’t. 
feature if you can first validate your
Users have complex needs with subtleties they understanding of the existing need and the ideal
solution?
may not even be aware of. Product managers

THE AGE OF PRODUCT DISCOVERY 12

 By introducing product
discovery to our process
we can do just that:

Adapted from Kevin on Code:

http://bit.ly/2hOGtDI

The discovery cycle is the process of actively capturing, researching, and

prioritizing user needs—as well as collecting and validating solution ideas
for addressing them. It complements the delivery cycle, which efficiently
transforms validated product ideas into valuable product functionality.

THE AGE OF PRODUCT DISCOVERY 13

 At productboard, our product discovery process With a clear understanding of the user's needs,
begins while communicating with prospects and PM and UX can team up to craft cheap
customers on Intercom, over the phone, or in prototypes and validate their understanding of
person during office visits and meet-ups. optimal solutions for pressing problems.
Ultimately, the aim is to understand:

“Hi there, I see you recently asked

for a dashboard exports capability. “If we built feature X like this, would
Would you mind helping us you use it?”
understand why you’re trying to
If feedback is positive, the prototype itself can
export your data out of the tool?” serve as a feature spec when the feature is sent
along to the delivery team, saving additional
Customers routinely make requests or mention effort down the road.
pain points they have with our product today, and
Together, the discovery and delivery teams form
our job is to dig deeper to understand what they
a super team, responsible for bringing value to
are trying to do.
the customers. The super team works
Product discovery can also be carried out more best when members from both
formally by interviewing users to delve into the teams collaborate to discover,
context of their requests: validate, and deliver solution
ideas.

“We certainly appreciate you

taking the time to screen share
your existing system of hacked
together spreadsheets. It’s clear
that prioritizing with a RICE score is
critical for you. Mind if we take a
screenshot to add to our
research?”

THE AGE OF PRODUCT DISCOVERY RETURN TO CONTENTS

CHAPTER THREE

A step-by-step
guide for
conducting
product discovery
Product discovery is about promoting an
environment of learning so you can improve your
product incrementally and consistently.
 The Double Diamond is a
popular approach for
conducting product discovery

Problem space Solution space

(RE) FRAMED
CHALLENGE PROBLEM SOLUTION
How much your head hurts

UNDERSTAND IDEATE TEST

DEFINE PROTOTYPE
rge
ge
Di

Di
er

e
ve

ve

nv
nv
rg

rg
Co

Co
e
e

Progress, Time, Resources

Source: Seek Blog on Medium

1. Identify the challenge

2. Re-frame the problem
3. Present solutions

Let’s break down each piece step by step

A STEP-BY-STEP GUIDE FOR CONDUCTING PRODUCT DISCOVERY 16
 1
The product discovery process starts with
identifying broad challenges that you are
trying to solve with your product. This is the
time for your product team to take a look at
the big picture—high-level objectives or
themes—not at specifics.

In productboard’s case, a challenge could

look like the following:

Identify
How can we enable mid-market
challenges companies to better use
productboard?

Defining the right type of challenge is

tricky. There are new product challenges,
where you work on an open-ended blank
slate. There are value and need-oriented
challenges, which revolve around the
current needs and pain-points of your
In this phase: users. 

Understand Then there are growth vs. technical

challenges. Growth challenges are usually

Define quantitative—maybe you are trying to

improve a metric within your product, like
user retention. Technical challenges are
often related to product performance.

17
 Understand

To correctly identify challenges, you must understand

the underlying user needs you want to solve with your
product. At this stage, product teams rely heavily on
quantitative and qualitative research to find answers.

Ideas for tools and techniques that are useful:

User research

Focus groups

Observation

Customer interviews

Data analytics

Competitive research

Empathy mapping

A STEP-BY-STEP GUIDE FOR CONDUCTING PRODUCT DISCOVERY 18

 Define

After you understand the user needs you are trying to

address, you must clearly define them:

• Nail down the problem: Aim to nail down one

sentence that covers the entire problem you are
trying to solve. This helps you communicate
clearly to your team and aligns them around a
common cause. If you formulate the problem
loosely, it will be difficult to keep everyone
focused.

• Validate the problem: Make sure that you are

actually working on problems that need to be
solved. How big is the pain that your users are
experiencing? How much value will tackling the
pain truly add?

• Prioritize: You must then figure out which of the

identified problems you should tackle first. There
are several popular frameworks to choose from.


Many product teams employ journey mapping, dive

into the Five Whys or other similar techniques, or
conduct a SWOT analysis for this step.

A STEP-BY-STEP GUIDE FOR CONDUCTING PRODUCT DISCOVERY 19

 2
After you isolate specific user problems, it
is best to reframe them into chunks that
can be attainably solved.

For productboard, the broad challenge

listed above can be re-framed and
narrowed down into the following:

Re-frame the Mid-market companies experience

limitations with productboard’s
problem public Portal because they want to
communicate with multiple
audiences at once.

During the reframing stage, you ideate,

prototype, and test potential solution ideas
that you have prioritized with your team. All
this is due diligence to validate products

In this phase: and features before they go into delivery.

Ideate
Prototype
Test

20
 Ideate

You ideate to figure out how you plan to solve your users’
problems.

This is where your team can get really creative with

innovation exercises and other ideation techniques like

Team brainstorming

Mind mapping

Storyboarding

Running design sprints

After ideas are proposed, your team can gauge their

potential impact and feasibility, then prioritize which to
prototype and present to customers.

A STEP-BY-STEP GUIDE FOR CONDUCTING PRODUCT DISCOVERY 21

 Prototype

Prototypes enable teams to demonstrate their ideas

and bring them to life.

There are many different types of prototypes,

including but not limited to sketches, mockups,
clickable prototypes, MVPs, or even using
competitive/similar products. The type of prototypes
teams choose to build depends on what they are
trying to learn, what needs to be tested, and what
open questions they still have.

Test

Testing determines whether or not the proposed

solutions are actually capable of solving the problem.
Popular tools and techniques here include:
A/B testing, customer interviews, user testing,
distributing surveys, and product beta testing.

A STEP-BY-STEP GUIDE FOR CONDUCTING PRODUCT DISCOVERY 22

 3
Nothing is built yet at the solution stage,
but you are ready to present ideas to
stakeholders and users. Note that solutions
don’t necessarily equal features. 

Going back to the example from

productboard, here is a viable solution: 

Present Let’s enable customers to build

multiple Portals so they can
solutions communicate with each of their
audiences differently.

Getting to a solution can take numerous

iterations, and presenting the solution to
stakeholders (in productboard’s case,
product leadership, delivery teams, and
cross-functional teams) will be crucial for
earning buy-in and alignment. 

At this stage, it is likely you will move into

delivery, though not with a finalized design.
Your solution is still rough around the
edges.

23
 Build excellence into
your product discovery
process
Here is a summary of how productboard evolved
through this product discovery process:

Challenge
How can we enable mid-market companies to
better use productboard?

Re-frame the problem

Mid-market companies experience limitations
with productboard’s public Portal because they
want to share/validate their ideas with multiple
audiences at once.

Identify a viable solution

Let’s enable customers to build multiple Portals
so they can share/validate their ideas with each
of their audiences differently.


By using this framework and following its steps,

product teams can create an environment of
continuous learning that leads to truly excellent
products.

A STEP-BY-STEP GUIDE FOR CONDUCTING PRODUCT DISCOVERY RETURN TO CONTENTS

CHAPTER FOUR

3 mistakes to
avoid with
product discovery
3 mistakes that we often see in product discovery:

• Jumping to solutions before nailing

down real user problems
• Underestimating the importance
of working with stakeholders
• Not involving engineers early enough

Dive into details of each in the

following pages and learn how
to avoid them
 1
Understanding user problems is the most
important step when it comes to building a
product. Yet, a common mistake product
teams make is being so eager to jump to a
solution that they don’t nail down and
define user problems first. 

The average product team spends

Jumping to 80% of their time in the solution

space and 20% in the problem
solutions space. Ideally, that time should be
split 50-50.
before nailing Product thought leader Rich Mironov

down real user describes the consequences of this

mistake nicely: “A lot of organizations skip
user research, testing, and validation and

problems get right into solutions and what they want

to build. The result is a struggle to find a
meaningful market that will use and pay for
the product.”

At productboard, the team aims to define

exactly what they want to solve in a short,
succinct statement—the more specific, the
better. To accomplish this, it’s often
necessary to refine their understanding of
the problem through several iterations.

Here are some examples of user problems

the team has narrowed down while
conducting discovery:

• Makers from multi-team

organizations who process insights
are reading notes that are not
relevant to their product area
• Feature details of customers with
multiple products [in productboard]
contain fields that are not relevant to
the feature. It makes it hard to
navigate and creates an opportunity
to make a mistake

3 MISTAKES TO AVOID WITH PRODUCT DISCOVERY 26

 2
It can be tempting for product teams to
plow ahead with the discovery process
without involving stakeholders from both in
and outside the organization. This can
cause big problems further down the road
for a few reasons:

• Product affects everyone.

Everyone’s success—from top-level

Under- executives to individual contributors

—is tied in one way or another to the
product. Thus, it makes sense to

estimating the •
consider diverse needs
Stakeholders have valuable insights
to offer. Stakeholders have
importance of knowledge that stretches beyond the
product team’s domain. Customer

working with
success and support, for example,
interact with customers day-to-day.
Sales is in constant contact with

stakeholders prospects and has an excellent pulse

on the market. This expertise should
be leveraged, not ignored
• Product teams need stakeholder
buy-in. Product teams need the
support of stakeholders to push
through major product decisions.
Including stakeholders from the get-
go ensures that time and resources
don’t go to waste

Ideally, all stakeholders should have

their needs considered during the
discovery process so when it’s time
for delivery, they know why their
request has been included (or not).

3 MISTAKES TO AVOID WITH PRODUCT DISCOVERY 27

 3
Too often, engineers are only brought into
the fold during the delivery phase. After all,
that’s when their skills are needed to turn
ideas into real-life products and features.
This is problematic for a number of
reasons. 

“If you’re just using your engineers

Not involving to code, you’re only getting about

engineers half their value.”

Marty Cagan

early enough First, engineers won’t fully understand

the problem they are trying to solve
because they didn’t participate in the
process of defining it. They may question
why a problem was chosen in the first
place, and product teams end up justifying
their decisions rather than getting things
done. 

Second, product managers will be their

only reference for understanding users.
Thus, when it comes to identifying
solutions, engineers may come to
completely different conclusions than the
product team because they did not play a
hands-on role in getting to the bottom of
user insights. Essentially, the product team
will be two steps ahead and engineers two
steps behind.

Third, the product teams risk missing out

on great ideas if engineers aren’t looped
in. Engineers are often the smartest people
in the room. They provide valuable
technical insights, understand how to
utilize existing functionality and reduce
effort, and can help to quickly build a proof
of concept.

3 MISTAKES TO AVOID WITH PRODUCT DISCOVERY RETURN TO CONTENTS

 Conclusion

Our goal with this guide is to give you

both the theory and practice of product
discovery. You now have an overview of
how product management has evolved
over time, a sense of why it’s so
important for companies to have a
regular discovery practice, and the risks
involved with not doing so. 

We’ve also covered concrete steps you can take to begin

building a regular discovery practice on your team and at your
organization. This might feel like an intimidating process, but it
doesn’t have to be. Keep in mind that for many teams, adopting
discovery is an ongoing process, so getting started is what
matters most. You’ll have plenty of opportunities to iterate and
improve over time, but only if you take those first steps.

Thank you for reading

CONCLUSION RETURN TO CONTENTS

 About productboard

productboard is a customer-driven
product management system that
empowers teams to get the right
products to market, faster. It provides a
complete solution for product teams to
understand user needs, prioritize what
to build next, align everyone on the
roadmap, and engage with their
customers. productboard is easy to
use, enables company-wide
collaboration, and integrates into
existing workflows.

Learn more at productboard.com

ABOUT PRODUCTBOARD RETURN TO CONTENTS