1 Product Discovery: A Brief Introduction

1.1 Introduction

In certain scenarios, the software we plan to build is well-defined and clear. In these cases, it makes sense to use the term requirement, as the customers can clearly express what the system should do.

However, in other scenarios, this clarity simply does not exist. For instance, we often are not even sure if the software—or an important feature of it—will be used or will have a market. Thus, in such cases, it’s nowadays common to use the term discovery to describe a set of activities aimed at discovering what really needs to be implemented.

In discovery scenarios, the term hypothesis is often used instead of requirement. The goal is to make it clear that we first need to run experiments before defining what will actually be implemented.

The discovery process is typically led by Product Owners (PO), Product Managers (PM), or UX Researchers. However, it is also important to involve developers and other stakeholders.

1.2 Example

Suppose we work for a software company that develops an online learning system. Our customers are universities that pay a monthly subscription fee. We want to implement a new feature: the ability for students to schedule short, synchronous meetings with instructors to ask individual questions.

Our hypothesis is as follows:

Synchronous meetings would improve the learning experience for students. Consequently, our software will be better evaluated by university administrators. Then, more universities will subscribe to our system and fewer will request cancellations. This will help us achieve our main business goals this quarter.

To validate this hypothesis, we need to verify the following points:

• Whether the lack of synchronous, individual interaction with instructors is a significant pain point for students.

• Whether universities are willing to allocate instructors’ time for these meetings.

• Whether this functionality is economically feasible. For example, we need to check if universities can charge for these meetings.

• Whether there are legal issues related to implementing this feature. For instance, we need to check if instructors’ contracts allow for this type of activity.

• Whether our company has the technical capacity and available developers to implement this feature within a reasonable timeframe.

Once the hypothesis is validated, it should be transformed into one or more user stories. If it proves unpromising, it should be discarded. However, this approach ensures we do not waste time implementing and providing a solution that would not be used or add value to the product.

1.3 Customer Interviews

Interviews with customers are the main technique used in discovery processes. Listening to customers is essential for deeply understanding their problems, habits, and routines. This helps us confirm (or refute) our hypotheses and determine if they will indeed add value.

However, it’s crucial to avoid a common mistake: asking customers directly if they think our idea is good and if they would use it. This often results in affirmative responses given out of politeness or a desire to end the conversation quickly.

Instead, interviews should focus on customers’ problems and routines, emphasizing their past experiences rather than speculative future scenarios.

For our learning management system, the questions could be as follows:

• When was the last time you needed to clarify an important question with an instructor? In which courses did this happen?

• Did you manage to get your question answered? If so, how? If not, what were the negative effects?

• Do you usually ask questions in the online learning system’s forum? Do these questions help you clarify doubts?

After the interviews, if our hypotheses seem promising, the next step involves building prototypes or MVPs.

1.4 Other Techniques

It is also important to mention that, in some scenarios, we have no clear idea how to solve a particular problem. These scenarios differ from our example, where we already had a specific functionality in mind to evaluate.

When ideas and hypotheses are unclear, we can use other discovery techniques such as Design Sprints, which we studied in Chapter 3, Design Thinking, and Jobs to be Done (JTBD).

1.5 Discovery with Scrum

To incorporate discovery activities into Scrum, we typically adopt a dual-track system that runs concurrently, as illustrated in the following figure.

The first track involves discovery activities, led by POs and PMs, aimed at discovering user stories for the product backlog.

The second track consists of delivery sprints, which follow traditional Scrum, as we studied in Chapter 2. The goal of this track is to implement and deliver user stories.

1.6 Discovery with Kanban

We can also adapt Kanban to include discovery activities. This typically involves using two workflows:

• Upstream Kanban: This new flow, with its own Kanban board, is dedicated solely to discovery activities. For example, it can include activities to understand customer demands and prioritize them.

• Downstream Kanban: This represents the main Kanban flow, as we studied in Chapter 2. It starts with the backlog and proceeds through steps such as specification, implementation, and review.

To illustrate these two flows, we typically use an image of a funnel, as shown in the following figure:

The Upstream Kanban corresponds to the narrowing part of the funnel, indicating that not every stakeholder-proposed demand reaches the backlog.

1.7 Conclusion

Let’s conclude with a quote from Martin Cagan, a well-known author in the digital products community (extracted from Inspired: How to Create Tech Products Customers Love, Chapter 8):

The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.

Exercises

1. What problems can occur when adopting Scrum or Kanban in a traditional way, and how can discovery activities help solve them?

2. When interviewing customers, we may have new ideas and hypotheses. Thus, Describe a new feature hypothesis for the online learning system used as an example in the article.

3. Besides being conducted with the interviewer’s mother, what is the main problem with the following interview?

Son: Mom, mom, I have an idea for a business — can I run it by you?

Mom: Of course, dear.

Son: You like your iPad, right? You use it a lot?

Mom: Yes.

Son: So would you ever buy an app which was like a cookbook for your iPad?

Mom: Hmmm.

Son: And it only costs $40 — that’s cheaper than those hardcovers on your shelf.

Mom: Well…

Son: And you can share recipes with your friends, and there’s an iPhone app which is your shopping list. And videos of that celebrity chef you love.

Mom: Oh, well yes honey, that sounds amazing. And you’re right, $40 is a good deal. Will it have pictures of the recipes?

Son: Yes, definitely. Thanks mom — love you!

Source: Example extracted from the book The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you by Rob Fitzpatrick (link).

4. Describe three additional questions the interviewer should have asked in the previous interview.

Check out the other articles on our site.