The RAPID Framework for Rapid Decision Making, Explained With a Worked Example

The RAPID framework for rapid decision making is a tool from Bain & Company that assigns five distinct roles to any big decision: Recommend, Agree, Perform, Input, and Decide. Its core idea is blunt — most decisions stall not because the answer is hard, but because nobody knows who actually gets to decide. RAPID fixes that by naming exactly one person who holds the D, and giving everyone else a defined, limited role.

Bain partners Paul Rogers and Marcia Blenko introduced the model in their 2006 Harvard Business Review article “Who Has the D?”, and it’s still one of the most-used decision frameworks in 2026. Here’s what each letter means, a worked example, when it earns its overhead, and how it compares to DACI and RACI.

What each RAPID letter means

The letters aren’t sequential — the process doesn’t go R, then A, then P. They’re roles, and one person can hold more than one on small decisions.

R — Recommend

The person who does the work of the decision: gathers data, consults the Input holders, weighs options, and writes a concrete recommendation. This is 80% of the effort. A good R shows up with “we should do X, here’s why, here’s what we rejected,” not a menu of options and a shrug.

A — Agree

People with formal veto power over the recommendation — almost always legal, compliance, security, or finance. An A can force the R back to revise, but can’t substitute their own preferred answer. Keep this list brutally short. Every A you add is a lane where the decision can park indefinitely.

P — Perform

Whoever executes once the decision is made. Naming the P up front does two things: the R sanity-checks feasibility with the people who’ll do the work, and the P isn’t blindsided by a decision that lands in their lap fully formed.

I — Input

People consulted for expertise or data. Their input must be sought and genuinely considered — and can then be overruled. This is the pressure-release valve of RAPID: stakeholders get heard without getting a veto, which is exactly the distinction consensus cultures fail to make.

D — Decide

One person. Not a committee, not “leadership,” not a vote. The D reviews the recommendation, makes the call, and owns the outcome. If you can’t name the D in one name, you haven’t finished setting up the decision.

A worked example: choosing a new CRM

A 60-person company is replacing its CRM. Sales, marketing, finance, and IT all care. Historically this exact decision has died twice in “evaluation phase.”

Notice what this kills. Marketing can’t veto the choice because their favorite tool lost — they were Input, and their requirements were weighed. IT can block on security but can’t relitigate price. And the decision can’t dissolve into a fourth evaluation cycle, because the VP of Sales visibly owns making the call by a date.

The whole thing took five weeks. The previous two attempts had each burned a quarter.

When to use RAPID (and when not to)

RAPID has setup cost. You’re writing down roles, briefing people on what Input does and doesn’t mean, and policing the boundaries. That overhead pays for itself only on certain decisions:

• Cross-functional decisions where no single manager owns all the affected teams — vendor selection, pricing changes, org design, market entry.
• Recurring decision types you can template once — e.g., every “build vs. buy” call uses the same RAPID map with names swapped in.
• Decisions that have stalled before. If something has been “under discussion” for two quarters, the missing ingredient is almost always a named D.
• High-stakes, hard-to-reverse calls where you want the reasoning documented.

Skip it for reversible, single-team decisions. Assigning five roles to choose a standup time is process cosplay. A useful threshold: if the decision affects multiple teams or would cost more than a week to undo, RAPID; otherwise, just let the obvious owner decide.

Pitfalls that break RAPID in practice

Agree inflation. The most common failure. Politeness turns every senior stakeholder into an A, and you’ve rebuilt the consensus swamp with extra paperwork. Rule of thumb: an A must have a formal, defensible reason to veto — regulatory, legal, security, budget authority. “Is senior and will be annoyed” is Input.

A weak R. If the recommender brings three options and no opinion, the D ends up doing the analysis themselves and the framework collapses into how decisions already worked. The R role is a real assignment with real hours attached.

The shadow D. The org chart says the product director holds the D, but everyone knows the CEO will overrule. If that’s reality, give the CEO the D honestly — a framework that pretends power sits where it doesn’t makes cynics out of everyone involved.

Input theater. Consulting people after the recommendation is already written. Input holders can tell, and next time they’ll escalate around the process instead of through it.

No deadline on the D. RAPID names who decides but not when. Add a date. An undated decision right is just a nicer place for the decision to stall.

RAPID vs. DACI vs. RACI

These three get confused constantly, and one of them isn’t even a decision framework.

DACI (Driver, Approver, Contributors, Informed) comes from Intuit and is popular in product teams — Atlassian ships a DACI template in Confluence. It’s genuinely close to RAPID: the Driver maps roughly to the R, the Approver to the D. The practical differences: DACI has an explicit Informed group and no separate veto role, so approval and veto collapse into one person. DACI is lighter; RAPID’s separate A role earns its keep in regulated or security-heavy environments where “can veto” and “gets to choose” genuinely need to be different people.

RACI (Responsible, Accountable, Consulted, Informed) is for ongoing work and task execution, not decisions. A RACI chart tells you who does the monthly reporting; it tells you nothing about who picks the reporting tool. Teams that stretch RACI to cover decisions usually discover the “Accountable” column has three names in it — which is the exact disease RAPID exists to cure.

Pick by problem: decisions stalling across teams, RAPID. Product decisions in a low-bureaucracy org, DACI. Confusion about who does recurring work, RACI.

FAQ

What does RAPID stand for?

Recommend, Agree, Perform, Input, Decide. Each letter is a role in a decision: the Recommender builds the proposal, Agree roles hold narrow veto power, Input roles are consulted, one person Decides, and Perform executes the outcome. The letters describe roles, not a sequence of steps.

Who created the RAPID framework?

Bain & Company. Partners Paul Rogers and Marcia Blenko popularized it in their 2006 Harvard Business Review article “Who Has the D?”, based on Bain’s work on organizational decision effectiveness. RAPID is a registered trademark of Bain.

Can one person hold two RAPID roles?

Yes, and on smaller decisions they usually should — the R and the P are often the same person, and a team lead might hold both I and A. The one rule that never bends: the D is a single named individual, not a group.

What’s the difference between RAPID and RACI?

RAPID governs decisions; RACI governs work. RAPID answers “who gets to make this call?” while RACI answers “who is doing this task and who needs to know about it?” Using RACI for decision rights is the most common way teams end up with several people who all believe they’re the approver.

Is RAPID worth it for small companies?

For most day-to-day calls, no — under about 20 people, decision rights are usually obvious. It becomes worth the overhead for the handful of cross-functional, hard-to-reverse decisions a small company makes each year, like pricing, a rebrand, or a major platform choice.