___
A step-by-step guide for conducting better
product discovery
Coding features ([Link] is hard
and expensive. Yet many teams learn they’ve made a false assumption about what users
really need once their new feature goes live – only to go underutilized. Well, life is too short
for that. And any business that operates in such a way won’t be around for long
([Link]
excellence/).
Fortunately, there’s a better way.
The standard process for prioritizing ([Link]
prioritization-frameworks/) what the delivery team works on looks like this:
Adapted from Kevin on Code: [Link]
What if we invested more in researching and validating ideas upfront before we ever sent
them to delivery?
Adapted from Kevin on Code: [Link]
We call this second track “product discovery” and it complements and precedes product
delivery.
Here’s how the legendary Marty Cagan describes it:
“First, you need to discover whether there are real users out there that want this
product… Second, you need to discover a product solution to this problem that is
usable, useful, and feasible.”
In short, product discovery is a process that helps product teams refine their ideas by
deeply understanding real user problems and then landing on the best way to solve them.
At Productboard, we are big proponents of this approach and will walk through the
product discovery process we follow in the steps below.
The product discovery process is about building
the right products and features for your
customers
There is always uncertainty when it comes to making product decisions. We conduct
product discovery because we want to reduce the risks around what we decide to build.
Sacrificing discovery usually leads to a disconnect between user needs and the products
that are built.
Marty Cagan ([Link]
from-the-father-of-tech-product-management/) identifies four big risks
([Link] in product management:
1. Value risk (whether customers will buy it or users will choose to use it)
2. Usability risk (whether users can figure out how to use it)
3. Feasibility risk (whether our engineers can build what we need with the time, skills, and
technology we have)
4. Business viability risk (whether this solution also works for the various aspects of our
business)
Essentially, conducting product discovery mitigates these risks and ensures that we are
building the right products for users. It helps your team laser-focus on the problems and
needs of users and sets them up to obtain deep user insights
([Link]
through continuous learning.
It’s important to note that the goal of product discovery is not necessarily to ship features.
Rather, it’s to promote an environment of learning that will help you improve your product
incrementally and consistently.
The goal of product discovery is not necessarily to ship features. Rather, it’s to
promote an environment of learning that will help you improve your product
incrementally and consistently.
A step-by-step guide for conducting product
discovery
Productboard uses the Double Diamond approach ([Link]
blog/design-thinking-101-the-double-diamond-approach-ii-4c0ce62f64c7) for
conducting product discovery, structured as follows:
Uncover the underlying user need
Understand
Define
Identify the optimal solution
Ideate
Prototype
Test
Let’s break down each piece step-by-step.
Uncover the underlying user need
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:
How can we enable mid-market companies to better use Productboard?
Defining the right types of challenges is sometimes 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
users. Then there are growth vs. technical challenges. Growth challenges are usually
quantitative — maybe you are trying to improve a metric within your product, like user
retention. Technical challenges are often related to product performance.
During the challenge identification stage, you understand and define what you are trying
to solve.
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. Some useful tools and techniques to use include
user research, focus groups, observation, customer interviews, data analytics, competitive
research, empathy mapping, and more.
Define
After you understand the user needs you are trying to address, you must then clearly
define them. There are a few steps to take to do this:
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 ([Link]
Essentially, you must figure out which of the identified problems you should tackle first.
There are several popular frameworks ([Link]
prioritization-frameworks/) that are used by product teams to do this. At Productboard
we favor value vs. complexity, but there are others, like the RICE method, ICE, and
more.
Productboard’s prioritization matrix, built around the value vs. complexity prioritization framework.
To clearly define problems, many product teams employ journey mapping, dive into the
Five Whys or other similar techniques ([Link]
need/), or conduct a SWOT analysis.
Identify the optimal solution
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:
Mid-market companies experience limitations with Productboard’s 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 and
features before they go into delivery.
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, and 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.
Prototype
Prototypes enable teams to demonstrate their ideas
([Link]
prototype/) and bring them to life.
There are many different types of prototypes ([Link]
prototypes-examples-mvp/), including but not limited to sketches, mockups, clickable
prototypes, MVPs ([Link]
mvp/), or even using competitive/similar products
([Link]
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.
Learn more about prototypes:
Why every product manager should be able to prototype
([Link]
prototype/)
8 examples of prototypes to build for your MVP ([Link]
prototypes-examples-mvp/)
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.
Present solutions
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:
Let’s enable customers to build multiple Portals so they can communicate with each
of their audiences differently.
Getting to a solution can take numerous iterations
([Link]
highly-complicated-product/). After all, the product team wants to be sure that they
deliver the right thing to users. 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 ([Link]
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.
Helpful tip
Product teams should codify best practices for how solutions should be used so internal
teams and customers can get the most out of them.
Intercom has an excellent product principle ([Link]
product-principles/) when it comes to this: stay opinionated but flexible. You can build a
solution and have an idea of the best way your customers can use it, but also build in
flexibility so your customers can use it in the way that best suits their needs.
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.
(In case you were wondering, you can now create multiple Product Portals
([Link] in Productboard. Go check it out!)
We wanted to share this framework because many product teams spend most of their
time working on solutions rather than working on problems. And it makes sense. It is a
tempting shortcut with far fewer steps involved. However, skipping the discovery process
can lead to teams shipping the wrong things, resulting in products and features that miss
the mark and go unused.
By using this framework and following its steps, our team has built an environment of
continuous learning that benefits both our teams and users, increased transparency into
our entire product management process, and involved a diverse set of stakeholders. We
hope you find as much value in it as we have.