What do Google Glass and Microsoft Zune have in common?

If you’re not familiar with these products, that’s partly the answer. If you are, then you probably already know: both were commercial failures. While several factors contributed to their market exit, a critical reason stands out: insufficient market research prior to launch. Both Google and Microsoft skipped essential steps in the discovery process, failing to ensure that their products addressed real, significant consumer needs. This oversight led to products that consumers found unnecessary and ineffective in solving meaningful problems (you can find some detabtes here and here).

Those cases lead us directly to today’s topic: the discovery process.

If you’ve been a product manager for quite some time, you definitely heard the term ‘discovery process’. There is a good chance you also know what it means.

However, even senior product managers sometimes struggle when it comes to the proper way to conduct a discovery process, and whether it is worth spending the time doing so.

In this post, I’m going to walk you through this topic in the most effective manner that I can.

Let’s first align everyone on what we are talking about here.

What is a ‘discovery process’

There are plenty of definitions out there, so as far as I’m concerned – ChatGPT’s definition is as good as any:

“

The “discovery process” for product managers is a critical phase where they gather and analyze information to identify the needs and problems of users, explore market opportunities, and ultimately decide on the features and improvements to develop for a product.

”

Yep. Sounds about right.

Putting it in my words – it’s a research-oriented process that takes place mostly outside of your office and it’s focused on gathering signals from the market (customers, trends, competition, etc..) in order to make sure that you are making the right product decisions about your features and new product initiatives.

When you should embark on a discovery process

Even though we still didn’t get into the details on what this process includes in practice, you can probably understand that this is a costly process, both in terms of time & resources.

Most of the posts that you’ll find on the web don’t focus on what exactly should trigger you to embark on this journey. And since you have your best intentions at heart regarding your product and you are strongly motivated to make it successful – you may reach the wrong conclusion that you should do it as often as possible.

Doing so would be a mistake because it’s indeed very time consuming. Those who do try usually understand quite fast that conducting a discovery process for each medium-sized feature and above is not really feasible.

This brings us to the natural question of when you should do a discovery process and when you can skip it.

Here is a short decision flow that should help you reach your decision:

1. If the feature you’re working on is medium-sized or smaller – skip it. 
2. For big features (but not new products or initiatives) – be brutally honest and ask yourself how much you understand why this feature is needed, and whether your decision to work on it is based on data signals that you are familiar with. If you feel comfortable with what you already know, and your decision to proceed with the feature is based on actual data – you can skip the discovery process.
3. In any other case, including new products, new initiatives and big features where you are not sure it holds enough justification to work on – you need to conduct a discovery process.
4. Refining or defining your product strategy – if you feel that the current product strategy is not holding water, it’s not delivering the results you hoped for or you simply don’t have one – then I do recommend conducting a discovery process that re-verifies the hypotheses behind the existing product strategy or with a lack of product strategy – learn what you need about the market as a foundation for a new strategy.

As you can see from this short list – there is no need for you to execute a discovery process for most of your time.

That doesn’t mean you don’t need to ‘master the why’. Meaning – even for small features it should be very clear to you why you’ve chosen to work on them instead of other features that are on your table. Sometimes it means that you do need to run a short research – talk to some people, understand the pains behind the feature request, estimate the impact, etc.

But I wouldn’t call it a discovery process.

The goals of the discovery process

Most of the experts will tell you that the discovery process is about risk mitigation. Meaning – making sure you and your team don’t spend your time on features that nobody needs.

Marty Cagan mentioned the following 4 risks in his article (here):

“

• value risk (whether customers will buy it or users will choose to use it)

• usability risk (whether users can figure out how to use it)

• feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)

• business viability risk (whether this solution also works for the various aspects of our business)

“

Personally, I think that the ‘value risk’ is the most critical one, by a fat margin. Working on a feature or a product that doesn’t deliver enough value is the most frequent mistake that I see.

The discovery process should help us mitigate these risks.

But I see an additional goal for the discovery process, and for some reason nobody talks about it in the posts that I’ve read. The goal I’m talking about is ‘ideation’. Meaning – coming up with ideas for features, strategies or products based on deep market research.

The need for ideation may arise because, sometimes, all the features on the backlog don’t seem that important.

Another reason may be that your company is struggling and you have a feeling that everyone (including you) have been missing something.

And sometimes the current product wins the market by a small margin and you are positive that you can find the secret ingredient that will help it win with a knockout.

By going back to the market, talking to customers, getting on top of the latest research and brainstorming with industry experts you can get a fresh view of the problems your audience is struggling with and it’s possible that it will lead you to an eureka moment.

How to conduct a proper discovery process

As I noted above – the decision to start a discovery journey is a tactical decision which you make based on a specific challenge. The possible challenges are:

• A big new feature or capability
• Fixing a meaningful capability that doesn’t deliver the desired impact
• A brand new product or initiative
• Revisiting an existing product strategy
• Coming up with a new product strategy
• Ideation

Once you are clear about the challenge you are after, it’s time to come up with a plan.

The Discovery Process Plan

I will shortly outline my approach to discovery, and you’ll see that it’s much the same for all challenges. However, all the challenges beside the last two are built on top of some hypotheses.

Working on a new product strategy or trying to get inspired by the market (‘ideation’) don’t have hypotheses behind them most of the time.

Hence – if you are focused on a challenge which is based on hypotheses – the first step of the plan is to write them down.

If you are considering a new product – why is that? Why do you think it’s gonna be successful?

If you are considering a new big feature – why this specific and not another? Something led you to come up with this specific idea and got you fall in love with that – what was the hypothesis behind it?

If you are trying to fix a promising capability – what were the assumptions that led your team to come up with it in the first place?

Let’s take a short example:

You are a product leader at AirBnb and since you’ve been operating in this market for a few years now, you strongly believe that offering guided tours around the asset’s location would be a great addition to AirBnb’s offerings.

What made you come up with this insight?

After backtracking your thought-process, you came to conclusion that your idea is based on the following hypothesis:

You strongly believe that short-term residents of AirBnb assets would appreciate the help of a local guide because many of them would be interested in learning about the hidden gems of the local area and not necessarily the main tourist spots.

Ok. This is an interesting hypothesis. We don’t know if it’s true or not, but if it’s true – then you may be up to something…

The value of writing down our hypotheses is to make it very clear what should be the outcome of the discovery process – either we prove the hypothesis, on the theoretical level or refute it. The process is not complete until one of them happens. (I will address later on what I meant by ‘theoretical level’).

Sometimes you have more than one hypothesis. In the example above there are additional hidden hypothesis – here is how I’d write it:

1. There is a scalable automatic way for qualifying/disqualifying potential guides
2. There are enough interesting ‘gems’ around AirBnb assets to make it a meaningful market

I can write some more, but those will suffice.

It’s important to be very accurate and brutally honest when writing down your assumptions. Missing key assumptions can void your conclusions from the discovery process you just completed.

Once you have written down your hypotheses, it’s the time to proceed to the next stage – follow a similar path you’d take for reaching a product market fit, but on a smaller scale.

What do I mean by that?

When I wrote my series about product market fit (PMF) a few years ago, my second post was about the Lean Startup Co. Playbook for PMF. You can find it here.

Long story short – this reference claims (and I agree) that the road to PMF goes through these stages:

1. The target audience (the customers or the users)
2. Their underserved pains
3. The core value proposition of your product
4. The specification of the MVP
5. The implementation of the MVP

When I’m saying that the discovery process needs to go through similar stages – I’m referring mainly to stages 1-3.

Essentially it means that:

1. You need to get well familiar with the personas who are going to use this feature/initiative/product.
2. You need to ‘fall in love’ with their underserved pains. Hence, regardless of your initiative, what really bothers them in their day-2-day, which belongs to the domain of your product.
3. Craft the value-proposition of your new feature or product in 1-2 sentences. It sounds easy, but it’s not. It means you really need to distill the essence of the true value that your product will deliver to amend some of the pains you identified before.

I don’t want to dive into the small details of how to do that, since this post is already getting longer than intended. However, those details are quite important, so I recommend that you read the post I linked above if you wish to master that.

I always say that stage 2 is the key for building successful features or products. Hunting and properly identifying the pains is what you need to evaluate your solution based on.

Now, what tools are at your disposal for achieving stages 1-3 above?

1. Gathering qualitative feedback via customer interviews – with the right personas. If you need further guidance on that – read my series on this (here, here and here).
2. Gathering quantitative feedback via questionnaires with the same personas.
3. Reading latest research on customers/users habits, if available. Worth spending a few bucks if the publication is a serious one.
4. Reviewing your competition by doing competitive landscape research. How is your competition addressing these pains? Maybe they are onto something? I have a post on that here if you need more guidance.
5. Conducting UX/UI interviews when the feature/product is highly dependent on a user interface.
6. Going over your internal backlog of feature requests. Hopefully, the requests are properly documented and grouped around pains, rather than solutions. Otherwise, this is not going to be very effective.
7. Reviewing the data gathered by the existing products of your company which are already out there. Can you learn something meaningful about your customers’ habits or pains? What’s the data telling you?

Some articles on the web mention a ‘discovery team’ that you need to build before you start your discovery process.

I don’t think it’s necessary for most of the time.

However, number 5 and number 7 from the above list require some help from your peers. 

For example – if the new initiative you have in mind involves a lot of UX/UI – it’d be probably a good idea to ask a UX/UI expert to join you in this process.

If the problem you are trying to solve involves digging through piles of data – then having a data analyst by your side can certainly speed up things.

In one of the discovery processes I did back then – I asked another product manager to join me, because the initiative was quite big, and I thought that having another pair of eyes and someone who can challenge my assumptions can be beneficial. This product manager joined me for all interviews and asked their own questions. We both listened to the answers and sometimes came up with different conclusions. It was indeed very beneficial to have this second perspective.

Hence, It’s ok to tag along some ‘friends’ for this journey, as long as you don’t waste their time. Everyone is busy – so treat their time with respect and ask them to join you only if you truly believe they can contribute a unique value.

Now, at this stage you should have a solid plan. You should know the following:

1. What are your hypotheses
2. Who are the personas you’re targeting
3. What methods are you going to use for identifying their pains
4. What methods are you going to use to get an initial feedback about your new initiative/feature/product idea
5. Whether do you need a ‘discovery team’ or not, and if you do – who should it include

Executing your plan

Well… just follow your own plan 🙂

A few things to bear in mind though:

1. Agree with yourself or with your team on the timelines in advance.
2. Customer/users interviews take time to set up – start with that as soon as possible.
3. If you have hypotheses then the success criteria for your discovery process is that you were able to prove/refute all hypotheses, at least on the theoretical level. This is important – so let’s pause on that for a second – the right way to prove or refute a hypothesis is via an MVP. However, MVPs are expensive and are not part of the discovery. The discovery should tell you whether there is enough substance to justify an MVP, or there is no point in doing one. The second thing I wanted to note is that being able to refute an hypothesis is a successful outcome. Yes, this is not what you hoped for – but at least you’re not wasting everyone’s time and money.
4. If the reason you are doing a discovery process is to fish for ideas, then a successful outcome is that you have new ideas on where you should take your product, which are backed up with data that you collected via this process.
5. If the reason you went on a discovery process is to revisit or to come up with a product strategy then clearly a successful outcome is one where you have a new strategy in place which is backed up with data. Now, a product strategy takes a bit more than just conducting a discovery process, but we won’t delve into this now. You can read about it on my site under ‘product strategy’.

As long as you don’t try to bend reality to your internal wishes and as long as you follow my tips from above then your discovery process has a high chance of being successful.

I’d be delighted to hear from you how your journey went. Feel free to write back to me with some feedback or questions.

Happy discovery!!

—

If you have any feedback on this post – feel free to write me and let me know what it is. I’d be delighted to hear from you.

If you think your friends/peers can enjoy this newsletter as well – invite them to subscribe on this page.