RAPID Framework

Overview

The RAPID Framework is a proprietary decision-making tool developed by Bain & Company to eliminate confusion and bottlenecks in complex organizational decisions. The acronym stands for five critical roles: Recommend, Agree, Perform, Input, Decide. Note that while the acronym is alphabetical, the actual workflow follows R-I-A-D-P order.

The framework addresses a common organizational pathology: decisions involving multiple stakeholders often stall because nobody knows who has authority, who needs to consent, and who is merely consulted. RAPID forces explicit role assignment before discussion begins, preventing the "too many cooks" problem where everyone feels entitled to decide but nobody is accountable.

Key insight: Decision speed and quality improve dramatically when roles are clear. Research shows organizations using RAPID achieve 3x higher revenue and earnings growth than peers, with employee satisfaction 27 points higher on average.

When to Use

Apply RAPID when:

• Decision involves 5+ people across multiple departments
• Stakeholders have conflicting interests or priorities
• Previous similar decisions stalled or produced poor outcomes
• Accountability for implementation is unclear
• Decision requires expertise from diverse domains
• Organization suffers from "decision paralysis" or endless meetings

Skip RAPID when:

• Decision is simple with obvious owner (adds overhead)
• Time-critical emergency requiring immediate action
• Single person has clear authority and all necessary information
• Decision is reversible and low-stakes (experiment instead)

The Process

Step 1: Identify the Decision Type

Classify the decision to determine if RAPID applies:

• Strategic: Direction-setting, market entry, product portfolio
• Operational: Process changes, resource allocation, hiring
• Crisis: Requires rapid response (RAPID may be too slow)

If strategic or operational with multiple stakeholders → proceed with RAPID.

Step 2: Assign the Five Roles

Critical rule: Assign roles BEFORE discussing the decision. Do not allow roles to emerge organically.

R - Recommend (1-3 people)

Role: Drive the decision process, gather data, consult stakeholders, develop alternatives, present recommendation.

Required skills: Communication, analysis, project management, stakeholder synthesis.

Responsibilities:

• Research options and alternatives
• Consult with Input providers
• Build business case with data
• Present recommendation to Decider
• Facilitate discussion

Common mistake: Assigning junior person with no authority (recommendation gets ignored). Choose someone senior enough to be credible.

I - Input (3-10 people)

Role: Provide expertise, experience, or information that shapes the recommendation. Consulted but not required to agree.

Required skills: Domain expertise, practical implementation knowledge, risk identification.

Responsibilities:

• Answer questions from Recommender
• Identify risks, constraints, opportunities
• Offer second opinions
• Provide implementation feasibility assessment

Common mistake: Treating Input as Agree (giving veto power to everyone consulted). Input does not equal consent.

A - Agree (0-3 people)

Role: Must formally consent to recommendation. Hold veto power. Typically represent legal, financial, compliance, or critical dependencies.

Required skills: Compliance knowledge, risk assessment, understanding of organizational constraints.

Responsibilities:

• Evaluate recommendation against organizational policies
• Vote yes/no (not "yes but...")
• Explain veto rationale if rejecting
• Suggest modifications to gain agreement

Common mistake: Too many Agreers creates gridlock. Limit to people with true veto authority (legal, budget, regulatory).

Note: Some decisions have zero Agreers (Decider has full authority).

D - Decide (EXACTLY 1 person)

Role: Make the final decision and commit the organization to action. Holds ultimate accountability.

Required skills: Leadership, organizational authority, risk tolerance, understanding of trade-offs.

Responsibilities:

• Review recommendation and Input
• Resolve conflicts between Agreers
• Make final call (yes, no, modify)
• Own the outcome (success or failure)
• Communicate decision and rationale

Critical rule: EXACTLY one Decider. No "co-decision" or "consensus-based." If multiple people must decide, you have multiple decisions—split them.

P - Perform (1-10 people)

Role: Implement the decision after it's made. Execute the plan.

Required skills: Project management, change management, execution capability.

Responsibilities:

• Translate decision into action plan
• Allocate resources
• Track progress and report status
• Adapt to obstacles without changing decision intent

Best practice: Ideally, the Recommender becomes the Performer (they understand the nuances). If not, ensure thorough handoff.

Step 3: Communicate Roles Explicitly

Before starting the decision process:

• Document roles in writing (email, Slack, wiki)
• Confirm each person understands their role
• Set expectations for timeline and deliverables
• Clarify what each role can/cannot do

Example communication:

Decision: Should we enter the European market in Q3?

R (Recommend): Sarah (VP Product) - Build market entry proposal by Feb 15
I (Input):
  - Sales team (market demand)
  - Finance (budget analysis)
  - Engineering (localization effort)
  - Legal (regulatory requirements)
A (Agree): CFO (budget authority), General Counsel (regulatory compliance)
D (Decide): CEO
P (Perform): Sarah (VP Product) will lead execution if approved

Timeline: Recommendation due Feb 15, decision by Feb 22

Step 4: Execute the Workflow (R-I-A-D-P)

Phase 1: Recommend gathers Input

• Recommender schedules 1-on-1s with Input providers
• Collects data, identifies risks, builds alternatives
• Synthesizes into coherent recommendation
• Does NOT seek consensus—gathers perspectives

Phase 2: Recommender consults with Agreers

• Present draft recommendation
• Surface deal-breakers early
• Modify recommendation to address legitimate veto concerns
• Goal: Enter decision meeting with Agreers likely to consent

Phase 3: Decision meeting

• Recommender presents recommendation (15-20 min)
• Input providers clarify or add missing context (10 min)
• Agreers vote yes/no (5 min)
• Decider asks questions, makes final call (10 min)
• Total time: 40-50 minutes (not hours)

Phase 4: Perform executes

• Decider communicates decision and rationale to organization
• Performer translates decision into project plan
• Performer reports progress to Decider on regular cadence

Step 5: Conduct Post-Decision Review

After implementation (3-6 months later):

• Did the decision achieve intended outcome?
• Were roles clear and respected?
• Where did process break down?
• Update RAPID role assignments for similar future decisions

Real-World Examples

Example 1: Product Feature Prioritization (SaaS Company)

Decision: Should we build enterprise SSO feature or mobile app redesign for Q2?

RAPID Assignment:

• R (Recommend): Product Manager (builds prioritization framework with data)
• I (Input): Engineering (effort estimates), Sales (customer requests), Customer Success (churn analysis), Design (user research)
• A (Agree): CTO (technical feasibility), VP Sales (revenue impact)
• D (Decide): CEO
• P (Perform): Product Manager + Engineering Lead

Process:

1. PM gathers data: 40% of enterprise leads request SSO, mobile redesign would impact 60% of users but not drive new revenue
2. Engineering estimates: SSO = 6 weeks, mobile = 12 weeks
3. Customer Success reports: 3 enterprise churns cited lack of SSO
4. PM recommends: Build SSO (higher revenue impact, faster delivery)
5. CTO agrees (technical feasibility confirmed), VP Sales agrees (unlocks $500K pipeline)
6. CEO decides: Approve SSO, defer mobile to Q3
7. PM and Eng Lead execute

Outcome: SSO shipped in 7 weeks, closed $400K in waiting deals, no debate about prioritization.

Example 2: Office Relocation (Mid-Size Company)

Decision: Should we relocate HQ to downtown or renew current suburban lease?

RAPID Assignment:

• R (Recommend): COO (analyzes costs, employee preferences, recruiting impact)
• I (Input): Employees (commute survey), Finance (cost analysis), HR (recruiting data), Facilities (logistics)
• A (Agree): CFO (budget authority)
• D (Decide): CEO
• P (Perform): COO + Facilities Manager

Process:

1. COO surveys employees: 65% prefer downtown (closer to public transit)
2. Finance: Downtown costs +$300K/year but reduces parking subsidy -$150K
3. HR: Downtown location increases candidate acceptance rate 20%
4. COO recommends: Move downtown (net cost +$150K, but recruiting advantage justifies)
5. CFO agrees (fits budget)
6. CEO decides: Approve downtown move
7. COO executes relocation over 4 months

Outcome: Relocation completed on time, employee satisfaction increased, recruiting improved.

Anti-Patterns

Too many Agreers

• Creates veto gridlock where nothing moves forward
• Keep to 0-3 people with legitimate authority
• Distinguish "needs to agree" from "wants to be involved"

Recommender with no authority

• Junior person assigned, senior leaders ignore recommendation
• Choose Recommender senior enough to be credible

Input treated as Agree

• Everyone consulted feels entitled to veto
• Clarify: Input is consultation, not consent

No clear Decider

• "Leadership team will decide together" → endless debate
• Appoint ONE person accountable for final call

Decider delegates decision back to group

• "What do you all think we should do?" after presentation
• Decider must decide, not facilitate consensus

Performer not involved in Recommend

• Implementation fails because Performer doesn't understand reasoning
• Ideally Recommender = Performer, or ensure thorough handoff

Roles change mid-process

• Someone with Input role insists on Agree role during meeting
• Lock roles before starting, enforce throughout

No documentation

• Verbal role assignments lead to confusion
• Write down roles and share explicitly

Key Takeaways

1. One Decider, Always: Multi-person "decisions" are discussion groups. Assign exactly one accountable person.

2. Limit Agreers Ruthlessly: Every Agree role slows the process. Only grant veto power to those with true authority (legal, budget, compliance).

3. Input ≠ Agreement: Consulting someone doesn't give them veto rights. Clarify the distinction.

4. Assign Before Discussing: Roles determined during debate lead to power struggles. Set roles upfront.

5. Recommender = Performer Ideal: The person who researched and recommended is best positioned to execute.

6. Time-Box Decision Meetings: RAPID enables 40-minute decision meetings instead of 3-hour debates.

7. Authority Must Match Accountability: Don't make someone Decide if they lack organizational authority to commit resources.

Related Frameworks

RACI Matrix (Responsible, Accountable, Consulted, Informed): Similar role clarity framework, but RACI applies to projects/tasks while RAPID focuses on decisions. RAPID's "Agree" role is unique (explicit veto power).

DACI (Driver, Approver, Contributor, Informed): Atlassian's variant. "Driver" = Recommend, "Approver" = Decide. Lacks RAPID's explicit "Agree" (veto) role.

Eisenhower Matrix: Prioritizes decisions (urgent/important). RAPID clarifies who decides after prioritization.

Decision Trees: Analyze decision options. RAPID handles the people/process side, not the analytical side.

Delegation Matrix: RAPID is sophisticated delegation—specifies not just who decides, but who influences and implements.

Scoring

Practitioner Weight (9/10): Created by Bain (top-tier consultancy), validated across hundreds of Fortune 500 clients. Demonstrated 3x revenue growth correlation.

Clarity & Executability (9/10): Five explicit roles with clear definitions. Highly actionable framework.

Proven ROI (9/10): Quantified impact on decision speed, quality, and organizational performance.

Novelty (6/10): Not groundbreaking—formalizes intuitive concepts. But "Agree" (veto) role is a useful distinction.

Cross-Domain Applicability (9/10): Works across strategy, operations, product, hiring, organizational change. Scales from 5-person teams to enterprises.

Total Score: 42/50 (Tier 1: Canonical)

Sources

• Bain & Company: RAPID Decision Making Framework (original source)
• Paul Rogers & Marcia Blenko: "Who Has the D? How Clear Decision Roles Enhance Organizational Performance" (Harvard Business Review, 2006)
• Bain & Company: "Decide & Deliver: 5 Steps to Breakthrough Performance" (2010)
• MindTools: Bain's RAPID Framework (implementation guide)