Product Discovery – 13 important PFRAQ questions to ask

Product Discovery describes the work required to decide what to build on a product, feature or initiative. On this article we’ll explore 13 PRFAQ questions to ask yourself when doing Product Discovery.

Questions around what and why something should be built are the focus of discovery. At this stage it’s important to spend more time on the problem space than on the solution space. Focusing too much on the solution may prompt teams to fall into build traps, which could lead to product market fit deviations.

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

Albert Einstein

Asking yourself, your peers and most importantly your customers questions is a great way to reduce uncertainty and that’s the main objective of doing Product Discovery. In addition, asking questions is part of the day to day of a product manager’s job and a focal point of Working Backwards’ PRFAQs.

PRFAQs are not a silver bullet for product discovery ideation. However, they can and should be used as the ultimate watch dog before committing time, effort, money and other resources on developing products that will not deliver value to customers and the company. Beyond that, running sessions to discuss the PRFAQ document will provide company wide alignment and validation around the assumptions made during discovery.

Opportunity Solution Trees

Opportunity Solution Trees are a concept devised by Teresa Torres and are described in her book Continuous Discovery. They are a visual representation of the steps to take during product discovery. We have separated our PRFAQ questions across these steps: Desired Outcome, Opportunity, Solution, Assumption Test. Lets understand what PRFAQ questions to ask at each stage.

Desired Outcome

In a good working backwards practice we should start with the desired customer experience. And for that we should ask:

In other words, what are the sentiments we want our users to experience? What are the actions we trying to prompt? What are the metrics we are trying to drive?

As we’re defining the outcome it is also important to define the target, for whom we are designing a desired outcome:

We may, or may not, have actual individual customers that would be included in the target, but we should have at least personas that represent the cohort.

Last we should consider doublechecking if we’re going down the right path:

We should verify if what we identified to be the desired outcome for our target, is in fact solving customer problems/or needs.

Opportunity

After defining the desired outcome, we should start exploiting problems that, if solved, would drive the desired outcome:

After defining the problem we should validate the size of opportunity for the customers we are targeting. Starting from the less to the most specific market fit:

Total Addressable Market (TAM) defines the total market opportunity for the product. If we the product was an Android app, the TAM would be the total number of users in the world.

We may however not be able to service all users within the Total Addressable Market:

If we were to build a weighting app for iOS, we would likely need some sensors to be available on the phone, which may not be available in all models. This portion of the market is often referred to as Served Available Market (SAM).

We should then focus on how big is the problem that we’re trying to solve and how many customers would take action:

If we were to build a weighting app for Android, not all users with a capable device would care about it. Even if they had the necessity of using a scale for cooking for example, not everybody would be bothered to open an app for weighting. Some users would just prefer to use a regular kitchen scale. Some other users like techies, for instance could potentially be interested. This portion of the market is often referred to as Target Market.

Solution

After thoroughly exploring space, we should look into the solution space and understand what would we providing to users in order to solve the problems defined:

At this stage we should still be focusing on the “what?” not the “how?”.

We should make sure we can make it clear for users and internal stakeholders that the product is a valid solution:

This is a cornerstone question for accessing product market fit. To the point that it makes sense to isolate the fundamental characteristics of the solution that will be most important to meet the specified need:

Assumption Test

Finally, after considering solutions that guide us to the desired outcome, we should make sure we can validate our assumptions.

First thing to revisit is to understand what we have done to sanity check our idea:

Have we done any market research or customer surveys?

In addition we can also make use of past experiences and learnings:

Did we have some learnings from prior tests that informed what to build? Have we done any market test initiatives like a Concierge MVP or Video MVP?

Once we get into the actual development it’s important to prioritize the learnings we need to take:

This should inform the scope of the initial MVP and further product iterations.

Conclusion

Product discovery is the base of product development. Some of the questions are fundamental for understanding what, why and to whom the product should be built. So fundamental, that quite a few questions should appear in the Press Release (PR) part of the PRFAQ and naturally on the PR of the release.

PRFAQs help establish the expected results of the different phases of the development lifecycle. Unfortunately they are not a guarantee of success. There are other iteration steps that we should consider during product discovery to make sure we reduce the risk and uncertainty on building products.

The list above is a filtered view of our FAQ Database, a tool developed to help product managers and entrepreneurs build PRFAQs. Check this and other PRFAQ question categories at ideashortcut.com/prfaq-database.