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. The framework has outlasted a lot of management fads specifically because it targets one narrow, well-defined failure mode, decisions with no clear owner, rather than trying to be a general-purpose project management system. That narrowness is a feature. RAPID doesn’t tell you how to run a meeting, how to prioritize a backlog, or how to structure a team. It only answers one question: for this specific decision, who does what, and who’s actually on the hook for the call.
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.”
| Role | Who | What they do |
|---|---|---|
| Recommend | Sales ops manager | Shortlists three vendors, runs trials, writes a recommendation with pricing and migration costs |
| Agree | IT security lead | Vetoes any vendor that fails the security review; can’t pick the winner |
| Input | Marketing lead, finance controller, 3 senior reps | Requirements, budget ceiling, workflow pain points, consulted, not voting |
| Decide | VP of Sales | Reads the recommendation, makes the call within one week, owns the result |
| Perform | Sales ops + IT admin | Run the migration and rollout |
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.
Treating Perform as an afterthought. Teams that skip naming the P upfront often discover, after the decision is made, that whoever actually has to execute wasn’t consulted on feasibility and now has to push back after the fact, reopening a decision that was supposed to be closed. Naming P at the same time as the other four roles, not after, is what prevents this specific failure mode, and it’s the pitfall most often skipped because Perform feels like the “obvious” role that doesn’t need explicit discussion the way Agree or Decide does.
A second worked example: a faster, lower-stakes decision
The CRM example above is a big, slow decision. RAPID works just as well compressed into days rather than weeks, and it’s worth seeing that scale too, since a lot of teams wrongly conclude the framework only fits major purchases.
A 15-person engineering team needs to decide whether to build an internal admin tool or buy an off-the-shelf one. It’s been raised in three stand-ups without resolution.
| Role | Who | What they do |
|---|---|---|
| Recommend | Senior engineer who raised the issue | Spends two days comparing build cost/timeline against three vendor options, writes a one-page recommendation |
| Agree | Engineering manager | Vetoes only if the recommendation blows the quarterly budget |
| Input | Two engineers who’d use the tool daily | Flag workflow requirements the vendor options might miss |
| Decide | Engineering manager | Same person as Agree here, since it’s a small team; makes the call within 48 hours of receiving the recommendation |
| Perform | The recommender | Implements or onboards whichever option wins |
Total elapsed time: four days, most of it the R doing the comparison work. The role assignment itself took ten minutes in a stand-up. This is the scale most teams should actually be using RAPID at, not the multi-week cross-functional version, and it’s worth noticing that the Decide and Agree roles collapsed onto one person here, which is completely normal on a team this size. Compare that to what usually happens without any named roles: the same “build vs. buy” question raised in three separate stand-ups, each time generating opinions from whoever’s in the room that day, with no single person accountable for actually closing it out. The four-day timeline above isn’t fast because the framework is magic, it’s fast because exactly one person was doing the analysis and exactly one person was waiting to make the call, instead of the decision diffusing across an entire team’s collective attention.
Rolling RAPID out to a team that’s never used it
The framework fails on introduction more often than it fails in practice, usually because it gets pitched as a permanent new process rather than applied to one specific stuck decision first.
Start with a single decision that’s actually stalled, not a hypothetical future one. Announcing “we’re adopting RAPID for all decisions going forward” invites the exact bureaucracy pushback that makes people resent the framework before they’ve seen it solve anything. Applying it once, visibly, to something that’s been stuck for a quarter demonstrates the value in a way an abstract rollout memo never will.
Name the roles out loud in the room, not in a document nobody reads before the meeting. A five-minute verbal walkthrough, “you’re R, you two are I, security is A, I’m D, ops is P”, gets more genuine buy-in than a slide with the same information, mostly because it forces immediate questions and pushback before the roles are locked in rather than after.
Expect the Agree role to be the point of friction. Almost every team’s first attempt at RAPID over-assigns A, because saying “you don’t get a veto, only input” to a senior stakeholder feels confrontational. It gets easier after the first decision closes faster than usual and the team notices; the second and third rollouts face much less resistance once there’s a visible result to point to.
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. It’s worth resisting the urge to run all three simultaneously on the same initiative just because each has its own dedicated fans on a team. Layering RAPID for the launch decision, DACI for the product roadmap, and RACI for the rollout tasks on one project is a reasonable division of labor across genuinely different questions, decision rights, product direction, and task ownership aren’t the same thing. Using two decision-rights frameworks for the same decision, on the other hand, just recreates the exact ambiguity both were meant to solve.
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.
How do you know if RAPID is actually working, versus just adding process?
Track two things across a handful of decisions: time from “decision opened” to “decision made,” and whether the same decision gets reopened afterward. A working RAPID setup should show decisions closing faster than the team’s historical baseline, and closed decisions staying closed rather than getting relitigated a month later by someone who felt cut out. If neither number improves after a few uses, the problem usually traces back to one of the pitfalls above, most often Agree inflation or a shadow D, rather than the framework itself being wrong for the team.
Does RAPID work for remote or fully async teams?
Yes, and arguably it matters more there than in person. In an office, an undefined decision owner can still get resolved by whoever happens to be loudest in the room. Async, that ambiguity just produces a Slack thread that nobody ever formally closes. Writing the RAPID roles into the decision document itself, who’s R, who’s A, who’s D, and by what date, gives a distributed team the same clarity an in-person meeting would provide informally, and it leaves a written record of who was actually accountable for the call.
What happens if the D makes a call that the Agree holder still disagrees with after voicing their veto?
If the Agree holder’s formal veto conditions are met, a regulatory issue, a security gap, a hard budget ceiling, they can block the recommendation and send the R back to revise. If their objection falls outside that scope, general disagreement with the direction, a difference in judgment, the D’s call stands, and that’s the entire point of separating Agree from Decide. Confusing “I disagree” with “I have veto grounds” is where Agree inflation comes from in the first place, and it’s worth revisiting that distinction explicitly when it comes up rather than letting the A role quietly expand into a second D.
Can the same person be R and D on the same decision?
Technically yes, but it defeats a large part of the framework’s purpose. The value of separating Recommend from Decide is that the D reviews someone else’s reasoning with fresh eyes rather than rubber-stamping their own analysis. On a very small team where literally one person has the context to do both, it can be unavoidable, but it’s worth treating as a compromise forced by team size rather than a pattern to default to whenever it’s convenient.
