Validate an idea. Check if there’s a market for it. Ship and listen to users. Iterate. Ship again. Listen to what they say. Iterate.

Heard that before?

Product Discovery, often referred to as Customer Discovery, is hardly a new idea. Despite that, many companies often forget about it or do it plain wrong. This applies to giant corporations, tiny bootstrapping startups, and anyone in between.

---

Product Discovery is the process of testing a concept with customers. The goal is, of course, to build the right product. By right, I mean the one that solves real problems, is well-timed and is possible to build with existing technology and available resources.

Sure, that’s easier said than done. But, if the product discovery is done right, it might make the difference between success and failure.

Yet many companies don’t do it right.

In a frenzy to outcompete their opponents, companies ship new features over and over again. The dust hardly settles after the last major launch, before the two other teams are already beta testing new concepts. All that to keep their market position or outpace their biggest rivals.

Many aspiring entrepreneurs also target that tiny chunk of the market. They’re hoping users will jump to their product right away and will grant them eternal glory in Silicon Valley.

To no surprise, many of these products collapse and the list of the most notable failures goes on and on. Let’s mention only a few of them:

• Windows Millenium
• Apple Newton
• Google+
• The New Coke
• Ford Edsel
• HP TouchPad

Each of these companies had a virtually unlimited budget. They could have spent hundreds of millions of dollars on marketing them. They could have hired the world’s top talents to build and sell them. They did.

And yet, each of these products is considered a spectacular failure. Because, whilst they were great in their own way, the customers didn’t really need them.

They gave them a try, some lined up in front of stores for hours. A few even emailed or tweeted friends about them (except maybe for the Ford fanbase in the ‘50s but we can understand that).

Product discovery process at Railsware Yet, none of the above products really took off, and each was, sooner or later, shut down. These companies still remain some of the world’s biggest and most successful despite these failures. Can’t say the same about thousands of startup founders who lost all their savings (and likely several years of their lives) building failed products.

Product Discovery vs Product Delivery

Product Discovery in agile methodology is often confused with Product Delivery. Despite the name similarity, it’s important to note that these are two completely different processes. They should both be a part of the process that leads to shipping a product, but you shouldn’t mix them up.

Product Discovery, as stated above, is about understanding what kind of solution is needed. It’s about understanding clients and their needs. It’s also about addressing their pains and creating value for them.

Product Delivery, on the other hand, is about building the solution figured out in the discovery process, with scrum methodology for example. It’s about bringing it to clients, seeing their reaction and building on it with future releases.

To make it even clearer, Product Discovery is about building the right thing, whilst Product Delivery is about building the thing right. Simple, right?

When to do product discovery? What is continuous discovery?

A very reasonable approach is to begin with proper product discovery, starting very early. It should happen before you even write the first line of code or attempt to sell anything.

Retreat with the team for a few days, relax, brainstorm and generate tons of ideas. Come back, put them in place and see what users think.

Now, likely the feedback won’t be all so positive and you won’t get a perfect hit at the first discovery session. Users won’t be so crazy about the product and user acquisition will be harder than expected. Clients won’t use a feature you thought would be crucial, or that feature will get lost in the process.

That’s why continuous product discovery should be a part of your delivery process. This doesn’t mean weekly retreats with the team (however nice these sound). It’s not about going through the whole process over and over again. This means:

• Craving user feedback. It’s about reading app reviews and analyzing support tickets. It’s about harvesting as many feedback sources as you can to understand your users’ point of view.
• Testing how users use your product, where they get lost, and what the bottlenecks are.
• Reaching out to users, asking for their opinion, and trying to figure out what the problems they’re struggling with are.

Such a process is often referred to as Dual-Track Agile. It’s about discovery and delivery processes that constantly overlap. The example below shows a possible flow:

• The discovery session leaves you with several key hypotheses and an idea of a model you could test with users.
• During the delivery, the concept is built and given to users. The first downloads happen and users are onboarded.
• Users didn’t like the concept but gave some valuable feedback. The concept goes back to the discovery table.
• A new concept is designed, under different assumptions. It’s passed to the delivery team for development.
• The second iteration is ready and is given to users. More downloads happen than last time and higher user engagement is visible. It looks promising.
• It turns out that users were eager to sign up, but didn’t find any value in logging in after that. Back to the discovery.

(many iterations later in a galaxy far far away…)

• The delivery team shipped the new concept and it finally seems to be the right match! Growth is significant, users keep coming back. There’s an interest in premium features. Now it’s onto the delivery team to keep improving the product while keeping the discovery team involved at all times.

Continuous Discovery is a bit easier than the initial product discovery. You (hopefully) already have some clients who can help you validate some hypotheses. The more users you ask, likely the better outcome you will get and the more informed decisions you’ll make. Assuming you’ll know how to interpret their answers.

We now have the WHEN part explained so let’s move to the core of this article – HOW to do a proper product discovery.

Product Discovery – questions to ask yourself

Whichever discovery method you choose, there are several product discovery questions worth asking yourself. They will also help you visualize what you want to get out of the process.

• Will the customer use this feature? Will they be willing to pay for it?
• Will it bring any value to them? Will they feel a difference if you take it away?
• Will they know how to use it?
• Are we capable of building it? Do we have the right skills, experience, and budget?
• Is it aligned with our business goals?

These are not simple questions and you might not know the answers. At first, you’ll probably do a lot of guessing and you’ll get some answers wrong. But over time, once you get to know your users better and test some assumptions on them, it will become clear if your approach is the right one.

If you already have some early adopters, a great method of getting the questions right is by exposing the team to your users.

Many companies ask non-customer focused employees (developers, designers, product managers, etc.) to spend a bit of time with clients. They answer their support tickets, respond to forum posts, jump on calls.

Even a few hours a month can do miracles. This can point you to an approach that wouldn’t cross your mind even on the best-facilitated product discovery session.

Product Discovery techniques

Over the years, many Product Discovery techniques have been proposed. Some gained little popularity, others became omnipresent on product discovery sessions. The most common methods you’ll encounter are:

• Design Thinking
• Jobs to be Done
• OKRs (Objectives and Key Results)
• RAT (Riskiest Assumptions Test)
• BRIDGeS

Let’s cover them one by one.

Design Thinking

Design Thinking is often defined as “a way of solving problems through creativity”. This doesn’t only help with product discovery which we’re discussing in this article. It can also have a very broad usage.

It can help students figure out a good approach to a graduation project. It can be a good way for an NGO to plan a marketing campaign to find donors. It can be also used by any CEO to allocate team members into teams and maximizing the positives.

Design thinking has become a universal approach to solving any kind of problem.

IDEO is widely considered to be the inventor of this approach but they deny such an achievement. Instead, they claim to have only popularized this approach and quite a job they did.

Today, the idea of solving problems by design has become one of the most popular ones on the planet. Quoting IDEO, “[Design thinking] brings together what is desirable from a human point of view with what is technologically feasible and economically viable.”

That’s why Design Thinking is a great tool for Product Discovery processes. It focuses on the following pillars:

Empathy

It’s all about understanding the needs of potential users of a product, problems they’re facing and their importance. It’s about putting yourself in their shoes and trying to dive into the feelings of your customer base.

This stage is inevitably connected with interviewing people. You want them to use a demo and share their feedback. Or if a product has already launched then you want to find real user stories.

At the end of this stage, the participants need to define the problems that they’ll be trying to address next. This is frequently considered a separate step of the Design Thinking process but since it’s inevitably connected with ‘Empathy’, we’ll keep them together.

Ideation

This stage is about coming up with many, even the wildest ideas. The only condition – they should be an answer to the established problem.

It can be a feature you’ve been thinking of for a while. It might be a marketing approach that could turn out to be revolutionary. Or, it can be only a simple project that came to your mind just now.

Participants are also encouraged to build upon the ideas of others. This has proven to be a powerful way of getting even better ideas. This stage is not for judging ideas or even discussing them. It’s to release creativity, fill the board with thoughts and move on. Go for quantity, not quality.

Experimentation (also referred to as Prototyping)

In this stage, we go through the ideas outlined in the previous stage and analyze them one by one. Can it solve the problem? Is it feasible? Are we able to build it?

We might throw some good old MoSCoW into the mix. The end goal of this stage is for the team to come up with ideas for prototypes to address the given problem. Such concepts are then broken down into pieces and put in motion.

Testing

Prototypes are built, and the design team is now tasked with measuring how a prototype is performing. Are the people using it as expected? What are their thoughts? Do they come back? Are they complaining about the lack of something? The goal of the team is to gather as much data as possible.

The process doesn’t end here because the prototype you’ve just delivered won’t be the final version of a product. It likely won’t even be close.

Depending on the results of testing, the team might go back to:

• Empathy – if they define a new or different problem during the testing

• Ideas – if the ideas generated were not enough to address the problem

• Prototyping – if the hypothesis was right, but we need a different prototype

And it can go on and on like this. The flow of Design Thinking is very flexible in nature. Some facilitators, to boost creativity, might split the team into groups and have them work on the same stages simultaneously.

Or, designers can collect information throughout the whole process. They could be building prototypes while the team is still discussing ideas.

In other sessions, several different groups could be going through the whole flow. As a result, several prototypes might be put in motion. There are many, many approaches to doing design thinking, but over and over again, the method proves to get the job done. Speaking of…

Jobs to be Done

Jobs to be Done is a powerful framework that has gained significant popularity among innovators. It takes a bit of a different approach towards problem-solving. It encourages participants to look at a problem, not from the perspective of a user (typical personas approach), but instead they focus on a ‘job’ a target is trying to achieve.

A job can be defined as a particular change a person wants to achieve in their life. Such an approach pushes you not to look into building an improved version of an existing solution. Instead, you should find a completely different way of solving a problem.

To give you an example – let’s say someone struggles with cutting a meadow around their house every month. They have a regular grass mower, but the field is large and it takes a lot of time.

Many entrepreneurs would think – let’s build a better, faster and more precise grass mower and sell it at a premium rate. It could work if you keep the price reasonable.

Jobs to be Done takes a different attitude. It tries to dig into the core of a problem, looking for an actual improvement a person is seeking. Do they want their grass cut? Yes, of course, but deep inside, they don’t care about the process of cutting the grass efficiently.

Instead, they want to have a good-looking garden, so they can feel good about themselves and their neighbors can admire them (or hate them a bit less, you pick). Also, the less effort they have to put into it, the better for them.

The JTBD-influenced group would look into making a genetically modified grass. It would only grow to a certain length, solving a problem. Would this satisfy the job a person is trying to get done? Most definitely.

OKRs

OKRs can be also used during the Product Discovery session.

In case you’re not aware of what they are: OKR stands for Objectives and Key Results. It’s a way of making ambitious plans and setting specific goals. These will allow you to measure if you meet your objectives.

As an example, an Objective “launch a product on the Spanish market” can come with a Key Result “reach 10,000 signups and 2,000 weekly active users”.

OKRs are meant for ambitious goals, so often reaching a KR of even 70-80% is considered a success. If you reach 100% of the key result without any serious struggle, the goal was likely not ambitious enough.

When doing a Product Discovery, teams should come up with user personas. They will help them visualize their goals, struggles and anything that might influence the way they use a product. Then, participants need to think about the goals they want a product to reach – these will be the objectives.

Usually, people are stimulated to come up with as many ideas as possible. Each is then discussed with the group. Ideally, 3-4 ideas should become Objectives.

Following that, the team comes up with Key Results for a given Objective. Each idea is, of course, discussed and then, when a consensus is reached, the teams write down their new OKRs.

As was the case with the other approaches, it’s hard to expect that the initial OKRs will stick for a long time. That’s why the team needs to be ready to revise their goals as they go. They should keep them as close to a current reality as possible. Of course, they still need to be ambitious. Settling for a trivial-to-achieve result shouldn’t be an option.

Due to the nature of OKRs, they should be also combined with other Product Discovery Methods. After all, they only focus on the objectives of a product, they don’t provide much support at the brainstorming stage. Regardless, OKRs make for pretty good metrics for product discovery.

RAT

Another interesting approach to product discovery is the method called RAT – Riskiest Assumptions Test. It puts a heavy focus on doing multiple tests of even the smallest prototypes. This way, the team can gather valuable data from clients as early in the process as possible.

RAT stands in opposition to what many entrepreneurs call MVP (Minimum Viable Product). By definition, MVP was meant to be a very basic version of a product, aimed at validating some hypotheses. Unfortunately, these days many, many startups spend months building their MVPs. They hardly gather any customer feedback and end up shipping products that might as well turn out to be useless.

Riskiest Assumptions Test is about determining the biggest assumptions about a product – its features, market, business model, etc. Participants try to come up with the simplest possible ways of validating these assumptions. The shorter the time needed to validate them, the more tests they can perform within an available runway and the higher chance of finding the right product/market fit.

BRIDGeS

BRIDGeS is a product discovery and decision-making framework created by Railsware's team. It’s a method we’ve been using at Railsware for many years. It gave birth to various successful products, and we’re confident that, when done right, BRIDGeS has the potential to be one of the best product discovery frameworks.

A BRIDGeS product discovery session is usually a one or two-day intense meeting. The session starts with the topic introduction. Participants introduce all the existing materials, like research, surveys, analytics data, wireframes, etc. The team defines the main Subject(s) that suffer from a problem and want it to be solved. Then, the team analyzes Benefits, Risks, Issues, Domain knowledge (any supporting data), and Goals of the Subject(s) and prioritizes them to focus on the most critical things.

Once the team has a deep understanding of the problem context, it moves on to finding solutions. It’s easy to offer 3-4 Solution variations when you see what aspects are the most important. The team can use the same set of descriptors to inspect Solution variations and make an informed decision based on all risks and opportunities each variation entails.

Once the Solution variation is chosen, the team creates a feature list making sure every critical aspect is taken into account. Eventually, the team prioritizes features and puts them on a roadmap.

Such a process gets everyone on the same page and enables you to deeply understand your product context. It’s especially recommended for the initial stages of development as a good intro to product development.

Summary

Whichever method you choose, the key deliverables of the discovery stage should be:

• A clear understanding of customers, their needs and the problems they’re facing
• A clear idea of how your product will overcome those challenges

The more data you have and the better. If you can understand it and use it to your benefit, the higher the chance of success for your product.

This wraps up this guide to product discovery. I hope that by now you know WHY it’s important to run a product discovery, WHEN it should happen and HOW product managers ought to implement it.

We also hope these will help you discover a great product and successfully deliver it to your customers. If you believe that you and your team have a great idea, you might be right, but don’t forget to double-check with your clients.

Steve Blank wrote in one of his books “There are no facts inside your building so get outside”. He might have been onto something.

Thanks for reading! This article is originally from Railsware's blog, but still, let me know your thoughts :)