What is a product decision, actually?

Why products are accumulated decisions and how to make those decisions visible

There is one sentence I have used for years now without questioning it very much. It has become something close to a professional principle for me — almost a shorthand for what I believe Product Research is there to do:

Product Research helps teams make better product decisions.

I could explain the Research part of that sentence quite precisely. Interviews, usability tests, surveys, experiments, behavioural data and synthesis all have clear functions. What I had never really stopped to define was the second half of the sentence:

What exactly is a product decision?

The explanation behind it is simple, the answer seemed obvious for me.

A product decision is simply a decision about the product.

Okay. Interesting…

The longer I looked at it, the less precise that definition became. And I had the impression that we use this term constantly without ever really defining it.

Is choosing one onboarding flow over another a product decision? Certainly. Is deciding which customer segment to focus on also a product decision? Probably. What about changing the wording of a button, deciding not to build a feature or continuing with an existing solution because nobody questions it?

That is where the term becomes interesting. Products are shaped not only by the decisions teams consciously make. They are also shaped by the decisions nobody notices they are making.

So I started taking it apart.

1. A decision does more than select an option

The terminology gives us a useful clue. The English word decision comes from the Latin decidere, formed from de- and caedere, with the literal sense of cutting off. The German entscheiden carries a similar idea through scheiden: to separate, distinguish or divide.

A decision therefore does more than select an option or possibility. It also separates that possibility from others. When a team chooses one target group, it deprioritises another. When it builds one feature, resources are no longer available for something else. When it optimises one metric, it may accept a trade-off somewhere else. A decision creates direction partly by excluding alternatives.

That matters because product development is full of these exclusions. Some are explicit and discussed carefully. Others happen quietly through habit, time pressure or inherited assumptions.

2. Products are accumulated decisions

Once I started looking at products this way, I began to see them differently. Take almost any screen in a digital product. Why is this information shown first? Why does the user need to create an account at this point? Why are there three pricing plans? Why does this feature exist while another one does not? Why does the workflow require five steps instead of three?

None of these things simply appeared. At some point, explicitly or implicitly, someone made a decision.

A product does not consist only of features. A product can be understood as an accumulated decision history. What users experience today is the visible consequence of hundreds or thousands of earlier decisions.

Some were strategic. Some were based on research. Some came from technical constraints. Some were compromises. Some were made under pressure and some were inherited from people who are no longer part of the team.

So what? This changes the way we should think about product quality. If the product is partly the accumulation of past decisions, then improving a product also means improving the quality of the decisions that create it.

3. Product decisions are made by…

people. Product Managers, Designers, Engineers, Founders, Researchers — and often several of them together. Products do not make decisions. People do.

A product is ultimately the visible result of thousands of human decisions (let’s see what the future with AI brings). Every feature, every screen, every piece of copy and every flow exists because, at some point, someone decided: “This is how it should be.”

Seen this way, a product is not simply a collection of features. It is an accumulation of decisions made by humans.

That is exatly where Product Research becomes interesting to me. If products are accumulated decisions, Research can contribute before those decisions become embedded in the product. It can make the reasoning behind them more visible and help teams develop a shared understanding of the reality they are deciding about.

4. Not every team decision is a product decision

Of course, teams make decisions all day. We move meetings, change processes, reorganise roadmaps and adjust responsibilities. Those decisions may influence how the team works, but they do not necessarily shape what users later experience.

So I needed a more functional boundary. My current working definition is this:

A product decision is an explicit or implicit commitment that influences what problem a product solves, for whom it solves it and/or how people will experience and use the solution.

This definition is deliberately broader than “which feature do we build?”. It includes decisions about users, problems, priorities, functionality, workflows, language, pricing and design. It also includes the decision not to act, because not building something can shape a product just as strongly as building it.

Three parts matter here.

1. What problem are we solving?

2. For whom are we solving it?

3. How will people experience the solution?

5. Six types of product decisions I currently distinguish

When I began sorting different decisions from past projects, a more practical pattern started to emerge. I no longer think it is useful to classify product decisions by job function or by vague labels such as “design” or “operations.” What matters more is what the team is actually trying to decide and therefore what kind of uncertainty needs to be reduced.

I currently distinguish six types.

#1 Opportunity decisions

These establish where the team should focus before a concrete problem or solution has been chosen. They concern markets, customer segments, unmet needs and areas where value might be created.

Examples:

• Which market should we enter?

• Which customer group should we prioritise?

• Which unmet need is worth exploring?

• Which problem space deserves investment?

These decisions are broad and usually carry substantial consequences, because they shape many of the decisions that follow.

#2 Problem decisions

These determine what is actually happening and which problem deserves attention. A team may need to decide whether a certain pain point is important enough to solve, whether a behaviour reflects a genuine need or what is causing an observed problem.

Examples:

• What is actually causing the drop-off?

• Is this problem relevant enough to solve?

• Is the issue comprehension, trust, motivation or something else?

• Which user need should we prioritise?

This is where Product Research can have particularly high leverage. If the problem is misunderstood, strong execution can still lead to the wrong product decision.

#3 Solution decisions

These determine which intervention appears most appropriate once the problem is sufficiently understood. The question is no longer whether the problem exists, but what should be done about it.

Examples:

• Should we introduce a new feature?

• Should we redesign the current flow?

• Should this process be automated?

• Which concept should we pursue?

• Do we need a product solution at all?

At this stage, Research often helps teams compare alternatives and understand how well different concepts address the underlying problem.

#4 Experience decisions

These shape how the chosen solution works for users in practice. They concern usability, interaction, information architecture, language, hierarchy and sequencing.

Examples:

• Can users find what they need?

• Do they understand what happens next?

• Where should information appear?

• How should this step be worded?

• Which interaction pattern works best?

These decisions may appear smaller than strategic or solution decisions, but together they determine the actual experience users have with the product.

#5 Launch decisions

These determine whether a solution is ready to be exposed to users and under what conditions. The question is no longer only whether the solution works, but whether the remaining risk is acceptable.

Examples:

• Is this ready to launch?

• Should we release it to everyone or start with a smaller segment?

• Which problems must be resolved before release?

• What level of failure or friction are we willing to accept?

• Do we need another round of validation before rollout?

This type of decision is particularly important because teams often confuse “we have built it” with “we are ready to release it.”

#6 Performance and iteration decisions

These happen once a product, feature or change is in use. They determine whether the intervention is producing the intended effect and what should happen next.

Examples:

• Is the feature actually solving the problem?

• Did behaviour change in the way we expected?

• Should we improve, expand, maintain or remove it?

• Should we invest further?

• Do we need to revisit the original problem?

These decisions close the loop. They turn product development from a linear process into an ongoing cycle of learning and adjustment.

Taken together, the six types form a practical sequence:

Opportunity → Problem → Solution → Experience → Launch → Performance / Iteration

I find this model useful because each decision type asks a different question and therefore requires different evidence. The method should follow from the decision, not the other way around.

6. Some of the most important product decisions are invisible

The more I thought about this, the more I became interested in decisions that never look like decisions. Imagine a team has been targeting the same customer segment for three years. Nobody actively decides this quarter to continue targeting that group. They simply do. Its almost in their DNA, in their business identity.. Yet every roadmap discussion is still influenced by that inherited choice. Or imagine an onboarding flow has existed for two years. Nobody chooses it again today, but by not questioning it, the team effectively decides to preserve it.

This suggests that a product is shaped by at least two forms of decision-making.

There are explicit decisions, where options are discussed and a direction is consciously selected. There are also implicit decisions, where something continues because it remains unquestioned. The second category is harder to see and therefore harder to examine. Yet it may shape the product just as strongly as the first.

7. This changes the role of Product Research

If Product Research exists to improve product decisions, then its job cannot simply be to produce insights.

An insight sitting in a research repository does not improve anything by itself. Research creates value when it changes the understanding from which a decision is made.

It can reveal that an assumption does not hold. It can show that different stakeholders use the same term while referring to different problems. It can uncover behaviour nobody expected. Sometimes it changes something even more fundamental:

the decision itself.

I remember a project where a team was already deep in solution space, discussing which additional functionality should be introduced. Which version should we build? How complex would implementation be? Where should it appear? They were already several steps ahead. My instinct was not to stop the momentum, but to slow the decision down just for a moment and ask whether we were certain that the missing functionality was actually the problem. They said, we aren’t certain. So we went back to the users.

What we found was different from what the team had expected. The missing functionality was not the central issue. People were struggling to understand the existing solution. The interesting part was that Research did not help us choose between the options already on the table. It showed us that we had moved into solution space before the problem itself was sufficiently understood.

Research did not tell us which feature to build. It changed the question.

Instead of asking which additional feature should be developed, we had to ask why the existing experience was not understood in the way the team had assumed.

Exactly this distinction has stayed with me because it points to a broader function of Research.

Sometimes the most valuable outcome is not a better answer. It is discovering that the team was answering the wrong question. And that matters because a well-executed answer to the wrong question can still lead to a weak product decision.

8. A simple Product Decision Check

Before every important product decision, I find five questions useful:

• What exactly are we deciding? Can we express the decision in one clear sentence?

• What type of decision is this? Opportunity, problem, solution, experience, launch or performance/iteration?

• What alternatives are we excluding? Every decision closes off other possibilities. What are we consciously not choosing?

• What needs to be true for this decision to make sense? Which assumptions are carrying the decision?

• What do we actually know already? What evidence supports or challenges those assumptions and what uncertainty remains?

  
  

I like this model because it forces the team to make the reasoning behind a decision visible before discussing whether the decision itself is “good” or “bad.”

9. What I currently believe

I started with a seemingly simple question:

What is a product decision?

In short:

A product decision is an explicit or implicit commitment that influences what problem a product solves, for whom it solves it and/or how people will experience and use the solution.

But to be honest, my answer today is broader than I expected. A product decision is not merely a choice between two interface variants. It is more than that. It is more than a choice between options.

Understanding this is key, because the moment we see product decisions only as choices between options, we overlook everything that happens before the choice: how the problem was framed, which assumptions shaped the discussion, what evidence was considered, what remained uncertain and which alternatives were never put on the table in the first place.

A product decision is not defined by who makes it. It is defined by what it shapes.

And this is exactly where Product Research becomes relevant to me. Research does not simply help teams choose between existing options. It helps make the reasoning behind those options visible in the first place.

It helps teams understand what they are actually deciding about.

10. Central Insight

A product decision is more than a choice between options. It is the result of how a problem was framed, which assumptions shaped the discussion, what evidence was considered, what uncertainty remained and which alternatives were excluded before a team committed.

Five Takeaways for Product Teams

• Define the decision before discussing the options. Make explicit what the team is actually deciding about before comparing solutions.

• Make the assumptions behind the decision visible. Ask what needs to be true for the decision to make sense, instead of treating those assumptions as facts.

• Separate what you know from what you infer. Put evidence, interpretation and remaining uncertainty on the table before committing.

• Make excluded alternatives explicit. A decision is not only what you choose; it is also what you consciously leave behind.

• Use Product Research to improve the decision frame, not only to evaluate solutions. Sometimes the most valuable contribution of Research is revealing that the team is deciding about the wrong problem in the first place.

  
  

Before asking “Which option should we choose?”, make sure the team has shared understanding of what is being decided, why, on which assumptions and with what evidence.

The Research Table

Once the term product decision becomes clearer, another question immediately follows.

If product decisions are more than choices between options — if they are shaped by problem framing, assumptions, evidence, uncertainty and trade-offs — then understanding their quality becomes essential for every Product Team.

The next question on the Research Table is therefore:

What makes a product decision strong or weak / good or bad and how can teams recognize the difference?