Rationalize your discovery process

In the eleventh session of the Instituto Tramontana product management program we entered the terrain of process. Not as something that sequentially follows what came before, but as one of the most recurring activities in product management: deciding what to build and why. This is where metrics, bets, empathy, and everything we've seen so far converge. And this is where most teams stumble.

The problem has a name: being trapped in delivery. It's the default mode. When what you do is measured by what you ship, and not by what you achieve, all energy is directed toward producing. The backlog grows, priorities are negotiated by volume and urgency, and the connection to the reason something should exist is lost. Naming this trap matters because it's not a one-off failure: it's the natural state of organizations that build product.

What follows in this session are concrete ways to create counterweights to that inertia.

Solutions as a set of alternatives

The first counterweight is resisting the impulse to jump to THE solution. It's easier said than done. Many forces work against it: the pressure to deliver, the comfort of the familiar, the illusion that the first idea is the right one. And you'll face situations where the solution comes to you already given, with varying degrees of detail.

The most effective remedy is to consider a set of alternative solutions and evaluate them against substantive indicators: customer experience, quantitative metrics, financial objectives. For this not to be a rhetorical exercise, you need two things: a habit of generating alternatives and explicit criteria with which to compare them. Without those criteria — which usually come from financial and behavioral metrics frameworks — the evaluation of alternatives becomes a discussion of opinions.

That search for multiplicity, combined with the constant connection to what happens between your product and the people who use it, leads you to the need to design what is commonly known as a discovery machine.

The three moments of discovery

The best way to find an alternative to the delivery-centered approach is to design a flow that treats each moment of the process differently. In all of them, the search for evidence as an anchor for decision-making is relevant.

The capture moment

The first moment allows you to collect, classify, group, prioritize, weigh, and relate signals from the people who use your product. You can reach these signals through automated information gathering, but also through empathic relationships. In the former, you incorporate quantitative metrics and patterns. In the latter, qualitative evidence and an effort to uncover contexts.

When you hear talk of "start with the WHY," keep in mind it refers to what happens here as a starting point. But it's not something that occurs once and then disappears. Problem exploration and solution exploration are intimately connected.

The sources of capture are broader than we usually think: conversations with customers, tests with people inside your company, listening sessions, reading reviews, reading incident reports in customer support channels, participating in other functions within the company. Both customer experience teams and your own empathy and conjectures based on data can feed this moment.

It helps to establish a perimeter for what you capture. Not everything you collect deserves immediate attention. If the capture moment fills up without criteria, it loses its function as a filter and becomes just another backlog. Setting an explicit limit forces you to prioritize, and prioritizing forces you to think.

The traffic light between capture and shaping

Not everything you capture should move to the next moment. Here lies the first key that any discovery process must incorporate. You need to manage a traffic light that indicates when a signal, or a set of them, can advance.

What turns that light green? Financial metrics frameworks — which place the potential business impact — and behavioral metrics frameworks — which place the relationship between people and the product — are the kind of anchor you need. Without those frameworks, the traffic light operates on intuition or internal pressure, which is another way of falling back into the delivery trap.

An effective way to systematize this step is to give yourself a template with the basic questions any set of signals must answer: Where did the opportunity arise? What happens if we do nothing? How could we know if we got it right? Can you imagine some kind of solution?

The shaping moment

The next moment is not yet immediate execution. You need to give yourself space to devote reflection to the signals you've worked on. Reflecting doesn't mean falling into writing detailed requirements and design to then wait for execution. Reflecting, here, means above all thinking about alternative solutions that open up the space of the imaginable.

When you hear talk of "experiment mindset," keep in mind that in most cases it refers to what happens at this stage: betting on something that helps you reduce the uncertainty between what you seek to improve and what you set in motion to achieve it.

It's useful here to incorporate a clear distinction between project and product. The former is a discrete way of accomplishing something; the latter is a value exchange where the contribution can be continuous.

The traffic light between shaping and building

A second traffic light decides when a thematic line is sufficiently important to move it into the development space. Guide metrics frameworks — those managed as primary metrics for the entire company — usually help to discriminate and weigh the importance and the appetite you want to dedicate to something.

Again, a template can help: What problem are we solving and why? Describe situations that help understand the value we'd be providing. How will we measure success? And an estimated scope that includes what's in and what's out.

The building moment

In the final moment we move into the delivery space. It's where the selected solution becomes something concrete. In this session we only opened the door: the next one will walk through it, and we'll see the specific challenges of the building stage.

Opportunity cost and compound interest

Two concepts that tend to be less present in product teams, and that lie at the root of why the entire approach gravitates toward delivery.

Opportunity cost allows you to understand what you stop doing when you decide to work on a solution. Every time a team dedicates a sprint, a week, or a quarter to building something, it's choosing not to build everything else. The most common error isn't choosing badly, but choosing without being aware that you're choosing: many times the alternative solutions aren't even present, and therefore the opportunity cost is invisible. The discovery flow is, among other things, a way of making that cost visible.

Compound interest is more related to the pace at which you deliver value. The usual problem is thinking that one large delivery is better than many small ones. Large initiatives are planned that take months, accumulate risk and dependencies, and when they finally ship, the context has changed or the impact is smaller than expected. Small and frequent improvements generate a cumulative effect: each one gives you information, each one adjusts your direction, and the compounded result usually far exceeds that of a few large improvements. Shortening build cycles isn't just an operational practice; it's a way of investing your effort with better returns.

Greasing the machine

Beyond the moments and the traffic lights, there are practices that make a discovery flow work on a day-to-day basis.

Parallelize discovery and development. The discovery flow should not run in series with building.

While the team builds what has already passed through the traffic lights, you can — and should — continue working on the capture and shaping moments for what comes next. This practice, sometimes known as dual-track, prevents the team from finishing something and finding a void: with nothing prepared, they pull from the backlog or the noisiest request, and you're back in the trap.

Feed the flow publicly and collaboratively. The discovery flow is not a private document belonging to the product person. It needs to be visible to the team and, if possible, to stakeholders. Transparency allows anyone to contribute signals, and makes the decision process explicit, which reduces the perception of arbitrariness.

Neither rigidity nor reactivity

The first clear benefit of instrumentalizing a discovery flow is that you don't have to fall into either of the two extremes between which common practice oscillates. The traditional approach tends to neglect the critical aspects of uncertainty. The approach commonly known as "agile" tends to dilute methodological capacity, reducing everything to a constant delivery chopped up without explicit purpose.

The discovery flow sits at an intermediate point: it has the intention and structure of the former, but the rhythm and adaptability of the latter. You don't plan for months before building, but you don't build without having thought either. The traffic lights are the mechanism that regulates that tension: you neither let everything through without a filter, nor block everything until you have complete certainty.

Prepare to live trapped, but also to gradually break free

The delivery-focused approach is predominant in our industry. It's good to accept that as a starting point, so as not to set yourself up for great disappointments. A frequent role in product management is that of rationalizing delivery, bringing confidence and method to execution. Through that activity, credibility is often earned, and it can be a good starting point from which to begin shifting the approach.

This is especially important when you lead teams. The incentive system of delivery is very different from the incentive system of discovery. The topics related to product strategy and culture tend to be what most conditions what can be done here. We'll see them in the final block of the program.

---

Session practice

Case study: Designing a discovery flow. In this session we allowed ourselves to work without as many constraints, in order to kick off the initiatives that will be dedicated to the coming weeks of development. The exercise consisted of taking a real product — each participant's own — and designing the three moments of the discovery flow for a specific problem, defining the traffic light questions at each transition and the metric criteria that turn the light green.

Homework: Identify a real problem or opportunity in your product that is currently "trapped in delivery" — something that is being built or is about to be built without having gone through an explicit discovery process. Apply the three moments of the flow: document the capture signals that justify working on it, fill in the first traffic light template, and sketch at least two alternative solutions in the shaping moment. The goal is to experience the difference between deciding what to build and simply building the next thing on the list.