Product discovery — the new holy grail

You have probably been to many industry conferences and heard about the product discovery process more than once, it seems to me that the topic has become one of the most important issues in the product management domain.

Thesis of this article is that in my opinion, there is not one golden benchmark of this process (as Facebook or Netflix has) and each of them has its own trade offs list that we can thoughtfully structure our processes based on sources.

Feature types

First, let’s talk about a simple typology of possible product features.

• New feature — quite a loosely defined term which in practice can mean everything from simple front-end functionality to enormous logic — front-end and back-end logic and maybe other 3rd party resource implementation.
• Optimization of application performance — a change in the back-end of the application or, for example, infrastructure, with the goal to optimize the app as whole or concrete part/s.
• Bugs — improvements and application bad behavior.

Sources of feedback

• Dev team
• Consumer
• Competition analysis
• Intuition

Complexity

If we do a simple math exercise it turns out from simple combinatorics we have 21 different combinations possible.

So is the implication of this to build 21 different processes? How can we logically arrange it?

Thinking about product discovery process

In the context of development, I think we should discuss these two main paths:

• Internal improvement

This is a collection of improvements that may not come from your customers explicitly but can be seen in them as a delayed ignition fuse, e.g. pagination or its absence in the context of a selected database or a bulky payload transferred via API.

In these cases, customers will not tell you in your polls, nor will you see it in the NPS.

There are two methods to detect improvements, either you have domain or technical knowledge that allows you to easily diagnose and predict the consistency, or you need to create conditions for sharing such insights in the team, e.g. in the form of an improvement hunt.

How to organize such an improvement hunt? Perhaps someday I will write a special text on this subject, but the idea is simple — divide the team into two parts; one represents the client and the clients needs, while the other team acts as an advocate for the product.

• Client feature

There is no sole source that triggers feature developments. You can rely on your intuition, data or feedback which comes from your clients. For each PM, the hardest thing to do would be to search and critique each of these sources, however the last one is probably the hardest to argue about.

Possible solutions on how to manage and prioritise these ideas in my opinion may be division into two steps:

• An attempt to organize into larger categories which allows you to change the perspective, look synthetically at certain groups and their frequency, which is already the first important step in order to proceed with the second.
• Prioritization — this is a very long topic because we can start from the simplest models of prioritization, such as the effort / value model that personally I like the most, to a greater amount of ‘design bureaucracy’, such as the ICE model.

Both data plus your domain knowledge and intuition should provide the necessary indications for further design investments.