Coding features 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.
Fortunately, there’s a better way.
The standard process for prioritizing what the delivery team works on looks like this:
What if we invested more in researching and validating ideas upfront before we ever sent them to delivery?
We call this second track “product discovery” and it complements and precedes product delivery.
Here’s how the legendary Marty Cagan describes it:
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.
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 identifies four big risks in product management:
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 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. "
Productboard uses the Double Diamond approach for conducting product discovery, structured as follows:
Let’s break down each piece step-by-step.
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
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.
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:
To clearly define problems, many product teams employ journey mapping, dive into the Five Whys or other similar techniques, or conduct a SWOT analysis.
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.
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.
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.
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.
Learn more about prototypes:
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.
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. 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.
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.
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 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.
Here is a summary of how Productboard evolved through this product discovery process:
(In case you were wondering, you can now create multiple Product Portals 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.
Looking to improve the way your product team conducts product discovery? Check out Productboard’s free new e-book: The product discovery playbook.
In it you’ll find information on all of the following:
