What is a Product Discovery?

The term Product Discovery was coined officially in 2007 by Marty Cagan as a way to describe a set of activities that aim to de-risk the likelihood of an engineering team building the wrong product. In essence, it helps to understand whether there is a desire for the product or service by customers, is it viable to sustain the business, and is it technically feasible to achieve. Since then, product discoveries have become an important part of building valuable products and it is an integral part of the product development lifecycle.

Product teams are rarely given the opportunity to consider different options or learn and measure the impact of decisions previously made. It’s usual for teams to be seen as a delivery function to a business group and given tight deadlines that are not based on any sort of estimation but gut feel. This is known as the Build Trap - teams decide to build based on best guesses, not facts or data.

So what’s the solution? Well, it comes down to giving product teams the time to think before they start doing. This means doing research, generating insights, forming and testing hypotheses, ideating solutions, and most of all, being empowered to decide what is valuable to build and what is not. This process can stretch from a couple of days up to a few weeks or months depending on the risk and unknowns associated with the build of the feature and desirable value.

Why you should do a Product Discovery?

Before we answer this question, let’s put things this way: doctors do not treat based on patients' assumed diagnosis but conduct their own investigation before prescribing the treatment. Likewise, a product team needs to:

• Have an understanding of the problem space - what is the problem or need and why does it exist

• Generate facts in the form of qualitative and quantitative data - understand who experiences the problem, their behaviours, attitudes, and needs

• Consider all possible options for the problem, verify the most suitable product or service, and eliminate bias for your own preferences

• De-risk the delivery and ensure what’s being built is the right thing - engineering time is scarce and if you spend your time pursuing the wrong opportunity for months, there’s a significant chance of missing your business goals

• Avoid the build trap - our first ideas are not necessarily our best so when we jump into a delivery mode we have limited information on how customers will use the solution or even if it solves the problem

When should you do a Product Discovery?

As a start, you need to understand the level of uncertainty associated with the proposed solution. If you have high certainty in the product or service then you can directly start with the delivery of the product or feature. However, if you have low and medium levels of uncertainty then you should strongly consider a Discovery.

Let’s take a look at two extreme scenarios: one delivering in an environment of low and another of high uncertainty, see how they compare and what can be done to decrease uncertainty in each case.

For both scenarios we will consider the following situation: you’ve come up with an idea or been asked by the founder or leadership in your company to deliver a new customer sign-up flow in 2 weeks.

Scenario 1: Low uncertainty

Fortunately, you've done a sign-up flow before, and even better, the team you’re going to work with to develop it has done that too. Moreover, you have insight into what customers will be looking for on the sign-up screens. You spend a few days writing down the technical steps involved and do some detailed estimation based on your team’s past experience and existing user research. Your estimates come a little higher than the proposed delivery timeframe and you ask for an additional week which is accepted by your stakeholders. You are very confident that you can now deliver the sign-up flow within 3 weeks and it will be exactly what your customers need. Three weeks onwards and you deliver the flow which is seen as a big success as customer acquisition goes up. Your team’s happiness and morale are high and leadership is very confident in your abilities to estimate and deliver.

Scenario 2: High uncertainty

For this scenario, we will assume you and your team have not done this in the past and cannot say with confidence what steps are involved, how complex they are, and how long it will take. Also, you have no or very limited insight into what your customers and business need from this sign-up flow. You are still given 2 weeks and because you feel pressured to commit, you decide to start delivering against the requirements and deadline you’ve been given.

You begin by creating a product backlog which is then handed over to engineers who fail to understand what’s required of them and they scratch their heads on why and what they are being asked to do. As the deadline approaches you realise you won’t be able to deliver in time and start making strategies to save the delivery. Team morale drops and leadership loses confidence in the abilities of the team to deliver. Eventually, you get to deliver the flow but analytics data starts coming through which shows low engagement and acquisition rates.

So why did the team from scenario 1 succeed while the one in 2 did not? The team in the second scenario faced a high degree of uncertainty. They didn’t fail necessarily because of a lack of technical expertise but rather a failure to admit there was limited knowledge and commitments made due to a poorly informed timeline. Moreover, there was no prior insight on what is going to make this sign-up flow seen as a success. How could you have approached the second scenario differently in order to be at odds of being successful? The answer is in the title of this article.

Conclusion

There are many techniques that could be utilised in a Discovery and there isn’t a one size fits all framework. There are techniques that go as high level or as detailed about learning about customers and validating assumptions with both qualitative and quantitative data. Also, the majority of techniques do not involve the developer’s time (unless there’s a need to technically validate something, of course) which is important since in delivery the development team needs to juggle between releasing fast to learn and making their code performant, scalable, secure, etc.

There are many things to consider when you’re building a product and you have to weigh in on the effort vs impact specific areas of the product will deliver against your business goals and value proposition.

Ultimately, you want to ensure you’re investing your limited resources into something that will enable you to learn and aid you to inform the next step in your journey. The best way to achieve that is through giving yourself time to think (Discovery) and then do (Delivery).