Bain RAPID decision framework

1. What Is the Bain RAPID Decision Framework?

RAPID is a decision-rights framework that clarifies who does what in important decisions so organizations can decide faster and execute better. The acronym spells out five distinct roles:

• R – Recommend: Proposes a course of action, marshals facts, and shapes options against agreed criteria.
• A – Agree: Has formal veto rights on narrow, predefined grounds (e.g., legal, risk, brand). Must be consulted, and can block the recommendation if specific thresholds are breached.
• P – Perform: Executes the decision once taken; owns implementation and results.
• I – Input: Provides relevant facts and perspectives to the Recommender; no veto power.
• D – Decide: The single decision-maker who chooses among options after considering input and agreement constraints.

The aim is simple: name the one person who has the “D,” distinguish narrow veto (“Agree”) from broader advice (“Input”), identify who must deliver (“Perform”), and make one role responsible for building the case (“Recommend”). RAPID prevents slow, looping approvals and “decision by committee” that plague matrixed organizations.

In plain terms: RAPID says who recommends, who must agree (and on what), who is consulted, who decides, and who then does the work.

2. Origin and Background

RAPID was developed by Bain & Company and popularized in the Harvard Business Review article “Who Has the D? How Clear Decision Roles Enhance Organizational Performance” (2006) by Paul Rogers and Marcia Blenko. The framework was further elaborated in Decide & Deliver (Rogers, Blenko, Mankins, 2010). It emerged from client work addressing a common pain point: unclear decision rights that slowed execution and produced rework and conflict.

Bain’s contribution was to make veto rights explicit (Agree), separate them from advisory input, and insist on a single Decider. That discipline, combined with clear service levels and escalation rules, consistently accelerates cross-functional decisions.

3. How RAPID Works

RAPID applies at the level of a specific decision (or a small set of recurring decisions). You map the five roles to that decision, define criteria and service levels, and embed the roles in your governance and workflows.

The Five Roles (practical definitions)

• Recommend (R): One role (often a team lead) gathers input, generates options, assesses against agreed criteria, and delivers a clear recommendation and rationale. R ensures the “A” roles are consulted before finalizing the recommendation.
• Agree (A): A small number of roles with limited veto rights on clearly defined grounds (e.g., legal compliance, financial controls, brand/ethics, security). “A” is not a general approval step; it’s a targeted, policy-bound check. If multiple A’s exist, define the scope and tie-break rules.
• Perform (P): The implementation owner; accountable for execution once the D is made. P plans, resources, and delivers, reporting outcomes against targets.
• Input (I): Providers of data, expertise, customer insights, or operational realities. They inform R early and time-box their contributions. No veto rights.
• Decide (D): One person makes the call. The D weighs the recommendation, considers Agree constraints and Input, and commits the organization. “Single D” is the keystone of RAPID.

Design Principles

• Single D: Exactly one Decider per decision. Multiple D’s = no decision.
• Veto is narrow: Keep Agree roles few and tightly defined. If someone wants a say but not a veto, they are Input.
• Time-boxed consultation: Set response SLAs (e.g., A responds in 48 hours; I within 3 business days) and “silence = no objection” rules where appropriate.
• Map roles, not names: Use role families (e.g., “Risk Officer,” “Product GM”) so RAPID survives personnel changes.
• Separate decision from execution: Performing is a distinct accountability with its own plan, measures, and cadence.

Typical Sequence

1. “R” drafts criteria and options, gathers Input, and engages “A” early on narrow veto issues.
2. “R” finalizes a recommendation and submits it to “D” with evidence (including whether A concerns are resolved).
3. “D” decides; “P” executes; “I” and “A” are informed of the outcome.
4. Run a short post-decision review at pre-agreed milestones to learn and adjust.

4. When to Use RAPID

Most helpful when:

• Cross-functional decisions stall due to unclear approval paths or “design-by-committee.”
• Multiple functions must balance trade-offs (e.g., growth vs. risk vs. customer experience).
• Regulated contexts require explicit veto rights (legal, risk, security) but you still need speed.
• Recurring decisions need a consistent pattern (e.g., pricing changes, vendor selection, product launches).

Especially powerful: Portfolio choices, pricing/packaging, market entry / partner selection, product release/go-to-market decisions, third-party risk onboarding, and strategy deployment decisions with cross-BU impact.

Less suitable or potentially misleading:

• Real-time crisis management where pre-delegated incident command is faster than consultation.
• Purely hierarchical, single-function decisions (you don’t need the full framework).
• As org design: RAPID clarifies a decision; it doesn’t fix capacity, incentives, or strategy quality.

5. How to Apply RAPID: Step-by-Step

1. Define the decision and success criteria.

   Write a one-sentence decision statement (“Should we move to usage-based pricing in Segment X for FY?”). Agree criteria upfront (e.g., customer impact, unit economics, risk/compliance, operational feasibility, time-to-market). Clarify time horizon and guardrails.

2. List stakeholders and authority boundaries.

   Identify roles with material stakes: P&L owners, product/tech, operations, risk/legal/brand, platform, finance. Specify what each function can and cannot veto (e.g., privacy law compliance, capital exposure limits).

3. Draft the RAPID map (roles to this decision).

   Assign one “D.” Name the “R” (often the person closest to the customer/problem). Keep “A” to the few roles with bona fide veto rights. Add “I” for those who inform the recommendation. Name the “P” (execution owner). Map roles, not individuals.

4. Set service levels and escalation rules.

   Define SLAs for A and I responses (e.g., I within 3 days; A within 48 hours). Document the threshold for veto and the evidence needed. Define escalation if A objects (e.g., to the next common leader within 24–48 hours).

5. Clarify the Recommend bundle.

   “R” documents: options and trade-offs; how criteria are met; summary of Input; status of “Agree” concerns; and the proposed implementation path if approved. Keep to a brief decision memo (e.g., 2–4 pages).

6. Run the decision.

   R engages I and A; updates the recommendation; submits to D. D convenes a short decision forum if needed, then decides and records rationale and conditions (if any). “P” begins execution with a clear plan and milestones.

7. Record and communicate.

   Maintain a decision log (date, D, outcome, rationale, constraints, P owner). Inform relevant stakeholders; publish in the operating wiki or portfolio tool.

8. Post-decision review and refresh.

   At predefined checkpoints (e.g., 30/90 days), review results vs. criteria. Capture learnings; adjust RAPID roles if friction or gaps emerged. Refresh roles when strategy, regulation, or org design changes.

6. Example: RAPID for a SaaS Pricing & Packaging Change

Context: A 2,000-person B2B SaaS company wanted to shift mid-market customers to usage-based pricing. Prior attempts stalled over concerns from Sales, Finance, and Risk; decisions looped endlessly.

Decision: “Should we adopt a tiered usage-based pricing model for Segment M in FY, launching in Q3?”

Criteria: CLV uplift ≥ 8%, churn ≤ baseline, sales cycle time impact ≤ +10%, compliance with regional billing laws, platform cost variance ≤ +5%.

RAPID mapping:

• D: VP, Mid-Market P&L.
• R: Director of Pricing (product marketing).
• A: Legal (billing law compliance); Risk (credit/refund exposure thresholds); Brand (material changes to pricing disclosure).
• I: Sales Ops, Customer Success, Finance FP&A, Engineering (metering/entitlements), Data Science, Regional GMs.
• P: Product Marketing + Sales Ops (rollout), Engineering (metering), Finance Ops (billing), Enablement (training).

SLAs: Input within 5 business days; Agree responses within 48 hours with explicit legal/risk citations; if A objects, escalate to CRO/CFO within 24 hours for tiebreak. Decision within 10 business days of the recommendation.

Execution: R developed three options with modeled economics and pilot data; A concerns (regional billing disclosures; credit limits) were resolved with targeted guardrails. D approved Option B with conditions (cap on promotional credits). P executed: engineering delivered metering MVP; enablement trained sales; legal updated terms.

Outcomes (two quarters): CLV +9.1%; churn flat; sales cycle +5%; support tickets manageable; no legal exceptions. The RAPID map was reused for future pricing decisions with minor tweaks.

7. Strengths and Limitations

Strengths

• Clarity and speed: Single Decider, clear veto boundaries, and time-boxed input accelerate decisions.
• Balanced control: Legitimate constraints (legal/risk) are respected without hijacking the process.
• Scalable pattern: Reusable role maps for recurring decisions; easy to teach and audit.
• Execution ownership: “Perform” ensures decisions turn into results with a named owner.

Limitations

• Design effort: Requires discipline to define A boundaries and pick a single D—harder than it looks.
• Culture dependency: If leaders avoid making calls or weaponize vetoes, RAPID won’t rescue you.
• Not a strategy cure: Clear roles don’t compensate for weak analysis or poor options.
• Overuse risk: Applying RAPID to trivial decisions creates bureaucracy; use it where stakes and interdependence are high.

8. Common Pitfalls (and How to Avoid Them)

• Multiple D’s.
  What goes wrong: Deadlock; endless alignment cycles.
  Avoid by: Enforcing a single Decider; if necessary, elevate to the next common leader as the D.
• Agree sprawl.
  What goes wrong: Everyone wants veto; cycle time balloons.
  Avoid by: Limiting A to true veto roles with explicit grounds; move the rest to Input.
• Unclear veto criteria.
  What goes wrong: A blocks on preference, not policy; conflict escalates.
  Avoid by: Documenting specific thresholds (e.g., GDPR compliance, risk exposure) and the evidence required.
• Silent A/I with no SLA.
  What goes wrong: Decisions stall waiting for responses.
  Avoid by: Time-boxing responses and defining “silence = no objection” for Input; explicit approve/fail for Agree.
• Weak Recommend.
  What goes wrong: D receives opinion, not options with evidence.
  Avoid by: Requiring R to present 2–3 options, criteria fit, risks, and implementation needs.
• Perform not named.
  What goes wrong: Decision is made; execution drifts.
  Avoid by: Assigning P and a simple execution plan with timelines and KPIs.
• No decision log.
  What goes wrong: Re-litigation; lost context.
  Avoid by: Keeping a lightweight log of D, rationale, conditions, and P owner.

9. How RAPID Relates to Other Frameworks

• RACI/RASCI: Broader responsibility matrices for deliverables. RAPID is decision-specific, with explicit veto (Agree) and a single Decider. Use RACI for project deliverables; RAPID for key decisions within that project.
• DACI (Driver, Approver, Contributors, Informed): Similar intent; “Driver” ≈ Recommend; “Approver” ≈ Decide; “Contributors” ≈ Input; no explicit veto role like Agree. Choose based on whether you need formal veto.
• Performance dialogues / OKRs: Use RAPID to assign decision roles for moving OKRs; performance dialogues become the forum where R presents, D decides, and P reports progress.
• Governance boards: RAPID can replace blanket board approvals with role-based, risk-tiered decision rights—keeping boards as escalation/tiebreak, not default deciders.
• Risk & compliance frameworks: Map “Agree” to second-line controls; codify criteria; track SLA adherence.
• Lean/DevOps/SRE: For release/change decisions, RAPID clarifies R/A/I/D/P; combine with policy-as-code to automate checks and reserve human veto (Agree) for high-risk cases.

10. Key Takeaways

• RAPID clarifies five roles for a decision: Recommend, Agree (narrow veto), Perform, Input, Decide—anchored by a single Decider.
• Keep “Agree” few and policy-bound; treat others as Input. Time-box responses and define escalation paths.
• Separate decision from execution: name the Perform owner and the plan. Record the decision and rationale.
• Use RAPID for cross-functional, recurring, or high-stakes decisions; don’t over-engineer trivial calls.
• Embed RAPID in templates, workflows, and performance dialogues; refresh role maps as context changes.

11. FAQs About RAPID

How is RAPID different from RACI?
RACI maps responsibility for deliverables; RAPID maps roles in a specific decision. RAPID’s “Agree” makes veto rights explicit; RACI doesn’t distinguish veto from advisory input. RAPID also enforces a single “D.”

Can one person hold multiple roles?
Yes, in smaller teams the same person might be R and D, or D and P. Be explicit to avoid conflicts (e.g., if D also has an A veto through another hat, clarify which role they’re playing).

How many “Agree” roles are typical?
As few as possible—often 1–3 (e.g., Legal for compliance, Risk for exposure thresholds, Brand for material reputation risk). If more are clamoring to be A, revisit criteria; they may be Input instead.

What if “Agree” blocks a critical decision?
Use documented criteria and SLAs. If A objects within scope, R revises the recommendation or escalates to the next common leader (or governance forum) for a timely tiebreak. Avoid letting A block on preference versus policy.

How long does it take to implement RAPID?
You can stand up RAPID for a single decision in days. Building a library of RAPID maps for a portfolio of recurring decisions typically takes 4–8 weeks, including SLAs, templates, and training.

Where should we start?
Pick one high-friction decision (e.g., pricing change, release authorization). Define criteria, map RAPID roles, set SLAs, run the decision, and log the outcome. Use the learning to scale to adjacent decisions.

Can RAPID work in Agile environments?
Yes. Use RAPID for decisions that cross squads or functions (e.g., release gates, cross-cutting architecture, pricing). Keep it lightweight and embed roles in your Definition of Ready/Done and sprint/PI ceremonies.

How do we embed RAPID in tools?
Add RAPID fields to decision briefs and workflow tickets (R, I, A, D, P). Automate notifications to I/A, track SLA timers, and store decisions and rationale in your portfolio tool or wiki for reuse and audit.

How do we know RAPID is working?

Track cycle time from recommendation to decision, number of loops, % of decisions with overdue A/I responses, escalation rate, and downstream rework. You should see faster, higher-quality decisions and smoother execution.

What if stakeholders can’t agree who has the D?
Escalate to the next common leader to assign the D. Ask: who bears P&L/risk for the outcome, and who has the best vantage to balance trade-offs? Multiple D’s signal design failure—fix before proceeding.