---
title: "Product Decision Making Framework: 7 Steps"
description: "A product decision making framework as a 7-step checklist: problem, perspectives, evidence, trade-off, decision, reasoning and learning, with a worked example."
canonical_url: "https://builderscamp.com/guides/other/product-decision-making-framework"
date_published: "2026-09-26"
date_modified: "2026-09-26"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "other"
---

# Product Decision Making Framework

**TL;DR:** A good product decision making framework is a seven-step checklist you run before committing: name the problem, gather perspectives, split evidence into what you know, assume and don't know, state the trade-off, make the call, write the reasoning, and decide what you will learn. Run it in full for decisions that are hard to reverse, and use a lighter version for everything else.

## What is a product decision making framework for?

A product decision making framework is a short, fixed list of questions you answer before a call, so the decision can be explained, challenged and revisited later. Its job is not to make the decision for you. It stops the two failures that sink most product calls: solving the wrong problem, and presenting a guess as a fact.

Speed matters as much as rigour. In his [2016 letter to shareholders](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders), Jeff Bezos wrote that "most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you're probably being slow." That figure is a rule of thumb from one CEO, not a measured threshold, but it frames the checklist below correctly: the goal is a defensible decision with incomplete information, not certainty.

Bezos drew the same line on process. "Many decisions are reversible, two-way doors," he wrote in that letter. "Those decisions can use a light-weight process." Use the full checklist for the decisions that are hard to walk back.

## What are the seven steps of the checklist?

The checklist is seven questions, answered in order. Each one takes a few sentences, not a page.

1. **Problem.** What is the problem, stated without a solution in it? "Clinics lose revenue to empty slots" is a problem. "We need a reschedule button" is a solution wearing a problem's clothes.
2. **Perspectives.** Who sees this differently, and what does each of them care about? List the users, the business owner, engineering, support, and anyone who will have to live with the result.
3. **Evidence.** What do you know, what are you assuming, and what don't you know? Keep three separate lists.
4. **Trade-off.** Which of user value, business value and technical cost gives way, and by how much?
5. **Decision.** What exactly are you doing, including scope and what is out?
6. **Reasoning.** Why this option over the strongest alternative, in two or three sentences someone outside the room can follow?
7. **Learning.** What signal will tell you within a few weeks whether you were right, and when will you check it?

Steps 1 and 3 do most of the work. A decision with a clear problem and an honest evidence split is usually easy to make, and a decision that feels impossible usually has a problem statement that still contains a solution. The [problem statement template](https://builderscamp.com/guides/templates/problem-statement-template) is the tool for step 1.

## Why split evidence into what you know, assume and don't know?

Separating the three stops confident opinions from outranking real data, and it also stops real data from being dismissed as opinion. Ideas that look minor can be worth far more than anyone expects. Ron Kohavi and Stefan Thomke describe in [Harvard Business Review](https://hbr.org/2017/09/the-surprising-power-of-online-experiments) a Bing headline change that sat as a low priority for more than six months; when an engineer finally tested it, it increased revenue by 12%, which they estimated at more than $100 million a year in the United States alone. One experiment at one search engine is not a base rate for your product, but it shows how badly a team can misjudge an idea when an assumption about its value is treated as known.

In practice, write the three lists side by side. "Known" only holds things you have observed or measured. "Assumed" holds everything the plan depends on that nobody has checked. "Don't know" holds the questions nobody can answer yet. The [knowns and unknowns matrix](https://builderscamp.com/guides/glossary/knowns-and-unknowns-matrix) is a longer version of the same exercise if you need to run it with a team.

## What does the checklist look like on a real trade-off?

Consider an original example: a booking app used by physiotherapy clinics. Patients book appointments through the app, and clinics pay a monthly subscription. Patients have asked, repeatedly, to reschedule their own appointments instead of calling the front desk.

**Problem.** Patients who need to move an appointment often cannot reach the clinic by phone during working hours, so some simply don't turn up, and the clinic loses a slot it could have filled.

**Perspectives.** Patients want to reschedule in two taps. Clinic owners, who pay the subscription, fear that easy rescheduling means patients moving appointments at the last minute. Engineering flags that the calendar sync with two clinic management systems occasionally lags, which could create double bookings.

**Evidence.** Known: support tickets and app reviews from patients mention calling the clinic to reschedule; clinic owners have raised no-shows on customer calls. Assumed: that self-service rescheduling reduces no-shows rather than increasing late changes. Don't know: how often the sync lag would produce a double booking at real volumes.

**Trade-off.** Full self-service maximises patient value but puts clinic trust and data integrity at risk. No self-service protects clinics but keeps the no-show problem.

**Decision.** Ship rescheduling with a cutoff each clinic sets (for example, no changes within 24 hours of the appointment), only for clinics on the calendar system with reliable sync, as a pilot.

**Reasoning.** The cutoff answers the owners' main fear, the sync restriction removes the double-booking risk, and the pilot turns the key assumption into something measurable before the full rollout.

**Learning.** Compare no-show and late-change rates for pilot clinics against their own previous period and against non-pilot clinics, and review the result on a date set in advance.

The decision gave something to each side and made the losing edge explicit: patients at clinics on the other calendar system wait longer. That sentence belongs in the record, because it is the first thing someone will ask about in three months.

## How do you write a decision down so it can be revisited?

Write a decision record the day you decide, not after the launch, when memory has already been edited by the outcome. Keep it to one page with these fields:

| Field | What to write |
|---|---|
| Date and owner | Who made the call and when |
| Decision | One sentence, including scope and what is out |
| Options rejected | The strongest alternative and why it lost |
| Evidence | Known, assumed and unknown, as three short lists |
| Trade-off accepted | Which of user, business or technology gives way |
| Reversibility | Easy to undo, or expensive to undo |
| Signal and review date | What would prove you wrong, and when you will look |

The review date is the field that makes the record useful. Without it, nobody rereads the page, and the team loses the one piece of feedback that would improve the next decision: whether the reasoning, not just the result, held up.

## When is a decision checklist the wrong tool?

The strongest objection to any decision framework is that it slows teams down and turns every small call into a meeting. That objection is right for reversible decisions. Changing button copy, reordering a settings page or adjusting an email subject line can be undone in a day, and the fastest way to learn is to ship and watch.

Use the full checklist when at least one of these is true: the decision is expensive to undo, it changes what several teams build, or stakeholders already disagree. For everything else, a two-line version (problem and signal) is enough. The skill is choosing the weight of process to match the weight of the decision, which is a large part of what people mean by [product sense](https://builderscamp.com/guides/glossary/product-sense).

## How does Builders Camp teach product decision making?

The [Product Sense bootcamp](https://builderscamp.com/bootcamps/product-sense) covers decision-making under uncertainty across 3 live sessions of 90 minutes each over 2 weeks, directed by [Mihaela Draghici](https://builderscamp.com/guides/profiles/mihaela-draghici): working with weak or misleading data, trade-offs between user value, business needs and technical constraints, and how to evaluate a decision when outcomes are mixed. Its practical challenge ends with a written decision memo, members get the bootcamp's Decision Making Template, a PDF worksheet for reasoning through a call under uncertainty and writing it up as a recommendation, and the [product sense case study exercise](https://builderscamp.com/guides/challenges/product-sense-thin-data-decision) lets you try the format on your own situation first.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. [See the Product Sense bootcamp](https://builderscamp.com/bootcamps/product-sense?utm_source=guide&utm_medium=organic&utm_campaign=product-decision-making-framework) for the next cohort and the self-paced version.

## Frequently asked questions

### What is a product decision making framework?

It is a fixed set of questions you answer before committing to a product call, so the decision rests on a stated problem, named evidence and an explicit trade-off rather than on who argued hardest. The version on this page has seven steps: problem, perspectives, evidence, trade-off, decision, reasoning and learning.

### How is this different from a prioritization framework like RICE?

RICE ranks many candidate items against each other with a score. A decision checklist works on one call at a time, usually one where the options are not comparable on a single number, such as a trade-off between user trust and short-term revenue. Many teams use both: RICE to shortlist, the checklist for the hard call at the top of the list.

### Should every product decision go through all seven steps?

No. Small, reversible decisions deserve a light process, and running a full checklist on them slows the team for no gain. Save the full seven steps for calls that are expensive to undo, affect several teams, or where stakeholders already disagree.

### What goes in the evidence step?

Three lists: what you know from data or direct observation, what you are assuming, and what you do not know yet. Keeping them separate stops an assumption from being presented as a fact in the meeting where the decision gets made.

### How do you write a product decision down?

Record the date, the decision in one sentence, the options you rejected, the evidence split into known, assumed and unknown, the trade-off you accepted, the signal that would prove you wrong, and a date to review it. A short page is enough; the point is that someone can reread it in three months.

### What if the decision turns out to be wrong?

The written record tells you which part failed: the problem framing, a specific assumption, or the trade-off itself. That is far more useful than a general sense that the launch disappointed, and it lets you change direction without relitigating the whole decision.

### Where can I practise this kind of decision?

The Builders Camp product sense case study exercise asks you to take one ambiguous situation, separate the request from the problem, weigh two options and write a decision memo. The Product Sense bootcamp works through the same skills live over 3 sessions.

## Sources

- [Amazon: Jeff Bezos, 2016 Letter to Shareholders](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders)
- [Harvard Business Review: The Surprising Power of Online Experiments, by Ron Kohavi and Stefan Thomke](https://hbr.org/2017/09/the-surprising-power-of-online-experiments)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.