Skip to content
Founders’ price Launch pricing for your first twelve months. 40 Playbooks, 40% discount for Founders. View the playbooks →

Decision Making Frameworks

TTool · Decision Making Frameworks

By , Editor · · What’s Next

“Structured approaches for making better decisions consistently, including RAPID (Recommend, Agree, Perform, Input, Decide), RACI for decisions, and various consensus and voting methods.”

The meeting ran an hour. Everyone contributed. Nobody knows what was decided — or by whom. It'll happen again next week.

Decision making frameworks are structured approaches for clarifying who has input, who decides, and how decisions get made. Pick a model — RAPID (Recommend, Agree, Perform, Input, Decide), RACI for decisions, consent-based methods — and match it to the decision's weight.

Five labelled roles laid out in a row, each with a single initial and a question: R recommend, A agree, P perform, I input, and D decide.
Method visual — Decision Making Frameworks

Different decisions warrant different frameworks. Reversible decisions can be made quickly; irreversible ones merit careful process. Reach for a framework when the team keeps re-opening settled decisions or when nobody's sure who has the final call.

The discipline prevents both analysis paralysis and premature closure. It fails when the framework becomes heavier than the decision it's meant to serve — trivial choices don't need a protocol, and applying one trains people to ignore the protocol when it matters.

Your next move: Who in your next meeting actually has the authority to decide — and does everyone else in the room know it, or are you about to hold a discussion that decides nothing?

What it looked like for them

Patient Communicator, 2010s. The founders built a patient portal that medical practices genuinely needed. Appointment reminders, prescription refills, lab results — every feature addressed a real workflow problem. Practices agreed it was better than what they had.

The sales conversations were encouraging. Then nothing happened. The problem wasn't the product. It was the decision to adopt. Inside each practice, no single person had the authority to switch patient-facing systems. The office manager deferred to the practice owner.

The practice owner deferred to the compliance team. The compliance team wanted a security review nobody had budgeted for. The decision to buy got caught in the same internal paralysis the product was designed to fix.

The founders' post-mortem is blunt: the product solved the workflow problem, but nobody had mapped the decision-making structure of the buyer. A framework for who decides, who inputs, and who can veto would have surfaced the stall before the pipeline filled with prospects who couldn't say yes.

- returns a SafeString and get.js throws on it }}
A move inside a Playbook

“The room has gone quiet and I don't know what to ask next.”

Open the Playbook →

Share the Playbooks