Most advice about the spade decision-making framework starts with a template. That's backwards.
A founder doesn't usually stall because the business lacks another worksheet. The stall happens earlier, when a signal is visible but the decision remains unnamed. You keep reviewing the channel, adjusting the offer, asking for another opinion, or waiting for cleaner evidence. The business keeps paying for the delay.
SPADE is useful only if it moves you from recognition to commitment. If it produces a polished record without forcing a call, it's administrative theatre. The point isn't to document indecision. It's to eliminate enough noise that you can choose a direction and make the choice real.
Table of Contents
- Why Founders Reach for Another Framework at the Wrong Moment
- The Decision Filter and What It Refuses to Be
- The Five Levels From Recognition to Committed Action
- The People Step When There Is No Team
- Two Founder Decisions Run Through the Filter
- Shadow Patterns That Break the Filter
- A One-Conversation Checklist and Where to Go Next
Why Founders Reach for Another Framework at the Wrong Moment
The popular advice is to find the right framework, install it, and let the process solve the decision. Founders know how this usually ends. They compare SPADE with OODA, RICE, decision matrices, and a growing shelf of mental models, then spend another session deciding which tool deserves attention.
That's not decision-making. It's decision avoidance with better vocabulary.
The spade decision-making framework originated at Square, where Gokul Rajaram and Jeff Kolovson developed it as a five-part method covering Setting, People, Alternatives, Decide, and Explain. First Round Review describes SPADE's origin and operating logic. Its strength is practical. It gives a difficult choice a defined context, named responsibility, visible alternatives, a decision point, and a way to explain the reasoning.
But a founder's decision rarely arrives in that clean shape.
You're not choosing between abstract options in a corporate planning room. You're deciding whether to raise prices while clients are still buying, stop a channel that might recover, take on a partner who could open a market, or shut down an offer that has become a drag on the business. The raw material is partial. The pressure is personal. The cost of delay is often disguised as more analysis.
Practical rule: A framework earns its place only when it shortens the distance between noticing a fork and committing to a direction.
The OODA loop is built for a different problem. Its Observe, Orient, Decide, Act sequence is designed for uncertainty and rapid change, with the Orient phase doing the critical work of turning observations into a usable mental model. Research on advanced OODA design emphasizes the importance of orientation in decision quality. SPADE is more useful when the issue is ownership, trade-offs, and commitment.
That distinction matters because decision fatigue degrades planning, working memory, attention, and cognitive flexibility after repeated acts of deciding. The conceptual review of decision fatigue explains how repeated choices can impair executive functions. A founder carrying too much decision load doesn't need more inputs by default. They need fewer discretionary branches.
The question is simple: what would this framework force you to stop considering?
The Decision Filter and What It Refuses to Be
I use SPADE as a Decision Filter, a structured way to move from a recognized situation to a committed action. It runs upstream of execution. That means it comes before the new dashboard, hiring plan, automation, habit, or project board.
The original Square model uses Setting, People, Alternatives, Decide, and Explain. For a founder working alone or with a small operating group, the labels matter less than the function. Each level should remove ambiguity and narrow the field.
The filter is not:
- A meeting template: It doesn't exist to give a recurring meeting a more serious shape.
- A RACI replacement: Named responsibility matters, but SPADE isn't a generic delegation system.
- A brainstorming prompt: Generating options is only one part of the work.
- A justification tool: You shouldn't use it to decorate a decision you've already made.
- A productivity system: It won't organize your tasks or manage your calendar.
- A mental-model library: It isn't a collection of concepts to consider indefinitely.
- An execution playbook: It helps establish direction, not every downstream task.
- Coaching or motivation: It can expose a decision. It can't supply your commitment.
The founder-grade version treats each step as a gate. If the situation isn't clear, you don't need more options. If the problem is misframed, a detailed comparison will only produce a precise answer to the wrong question. If the choice is already obvious, forcing artificial alternatives creates delay.
The load-bearing move is recognition. You notice that a pricing model no longer matches the value delivered. You see that a channel consumes attention without earning its place. You realize that the partnership you're negotiating would make the business more complex without improving direction.
The rest of the filter contains that recognition. It turns a vague internal signal into a decision another person can understand, challenge, and act on.
For a concise working definition, use the Decision Filter as the upstream instrument. The filter doesn't promise certainty. It forces a clean relationship between what you see, what you're choosing, and what you'll do next.
The Five Levels From Recognition to Committed Action
SPADE is often presented as a five-step acronym. For a founder, the more useful version is a five-level filter: Situation, Problem, Alternatives, Decision, and Execution. The names differ from Square's original Setting, People, Alternatives, Decide, and Explain structure, but the operating intent is aligned. You're moving from context to responsibility, choice, and communication.
The levels aren't fields to fill. They're gates. A level is complete when it has removed the uncertainty that blocks the next one.
Situation names what changed
Start with the observable condition, not your preferred explanation.
A pricing reset might begin with a simple recognition: the business is attracting work, but the current pricing leaves too little room for delivery quality and founder attention. That's the Situation. It tells you why the decision exists now.
Don't smuggle the answer into the description. “Our prices are too low” is already a conclusion. “The current pricing creates delivery pressure and reduces capacity for higher-value work” gives you a condition to examine.
Problem defines the actual choice
The Problem is not the symptom. It's the decision that the symptom creates.
Suppose churn has increased. The problem isn't “churn is bad.” The problem might be whether to narrow the customer profile, change onboarding, alter the offer, or stop serving a segment that creates support burden without durable value.
This level protects you from treating every visible metric as an instruction. A churn signal can lead to a product decision, a positioning decision, a customer selection decision, or no immediate decision if the evidence doesn't yet justify intervention.
Alternatives expose the available paths
List the alternatives, not decorative ones.
For an underperforming offer, the options might be to sunset it, expand it with a clearer target customer, raise the price and reduce scope, or retain it while changing acquisition. You don't need an exhaustive catalogue. You need enough contrast to prevent the first emotionally attractive answer from becoming the only answer.
Skipping Alternatives is valid when recognition is already clear and the decision is reversible. The filter should reduce load, not create ceremony.
Decision makes the call
The Decision is a sentence that a person can act on.
“We're going to think about repositioning the offer” is not a decision. “We're ending the offer for new clients and keeping existing commitments through the current delivery cycle” is a decision. It has a boundary, an owner, and an implication.
Execution means committed action
Execution here isn't a project plan. It's the first visible act that proves the decision exists.
A pricing reset becomes a revised proposal, a new sales conversation, and a date when the old price stops being offered. A channel shutdown becomes paused spend, a customer communication, and a clear reassignment of the time it consumed.
The filter is complete when the decision changes behaviour. Documentation supports that change, but documentation isn't the outcome.
The People Step When There Is No Team
The People step is where SPADE often gets misapplied by solo founders. In Square's model, explicit roles separate input from accountability and approval. A practical explanation of SPADE's People step distinguishes the Decision Maker, Approver, and Consultants.
A solo founder doesn't need to manufacture a committee. They do need to prevent private reasoning from becoming unquestioned reasoning.
Translate People into three structural checks:
- Named critic: Choose one advisor, peer, or former operator who will argue against the proposed call. Don't ask for general thoughts. Ask what would make the decision wrong.
- Written dissent: Capture the strongest objection in your own words before committing. If you can't state the objection clearly, you haven't tested the decision.
- Accountability timestamp: Set a specific date and surface where you'll revisit the call if reality diverges. This isn't permission to reopen the decision every week. It's a defined test of the assumptions behind it.
The point is not consensus. Consensus is often the wrong target for a founder. You need enough friction to expose a blind spot, then one person must own the choice.
Stakeholder polling creates a different failure mode. You ask several people what they think, collect softer opinions, and mistake the volume of input for decision quality. The founder remains responsible, but the decision becomes harder to state because everyone has added a qualification.
Use People to stress-test the call, not to distribute ownership you still carry.
Two Founder Decisions Run Through the Filter
The filter doesn't decide for you. It discloses whether you've decided.
Consider a seed-stage founder reviewing a channel that has underperformed for two quarters. The founder says the choice is whether to “fix or pivot.” That wording already hides the issue.
| Level | Stalled channel decision | Clean partnership decision |
|---|---|---|
| Situation | The channel has underperformed for two quarters, but recognition arrived six weeks late. | A partnership offer creates a credible route into a market the founder already wants to enter. |
| Problem | The question silently narrows to revenue, ignoring founder time, customer fit, and strategic distraction. | The question is whether the partner's access justifies the added complexity and reduced control. |
| Alternatives | No options are written down. “Pivot” becomes a vague substitute for choosing. | The founder compares accepting, rejecting, or proposing a narrower pilot with defined boundaries. |
| Decision | A mood produces a soft pivot. The channel remains alive and keeps consuming attention. | The founder chooses a bounded partnership with explicit responsibilities and a review trigger. |
| Commitment | Nothing changes materially because the call was never stated as a kill, pause, or redesign. | The proposal is revised, the partner receives a clear response, and the internal owner is named. |
The channel decision looks analytical from the outside. It has metrics, conversations, and repeated review. The filter shows a different reality. Recognition was delayed, framing was narrow, alternatives were absent, and the final language preserved optionality.
That's not a bad spreadsheet. It's avoidance.
The partnership decision runs cleanly because the founder is willing to define the trade-off. The partnership isn't treated as “an exciting opportunity.” It's treated as a choice between access, control, complexity, and direction. A dissent is captured. The commitment has a visible first action.
This is why frameworks should disclose rather than decorate. The first scenario doesn't need a better scoring model. It needs the founder to say what will stop, what will continue, and what evidence would justify reconsideration.
Shadow Patterns That Break the Filter
Founders rarely break SPADE by misunderstanding a label. They break it by using structure to protect the same avoidance that structure was meant to expose.
I call these Shadow Patterns, recurring distortions that make a decision look active while keeping the founder uncommitted.
Recursive Recognition
You reopen the same decision every Monday. The notes change slightly. The call doesn't.
This is avoidance wearing a process costume. The founder keeps “updating the situation” because moving into alternatives would force a trade-off.
Fake Pluralism
You invent three options because the framework appears to require them. One option is viable. One is a fantasy. One exists only to make the preferred answer look considered.
The fix is not to generate more ideas. State the constraint that eliminates the false options. A filter that removes paths is working correctly.
Discounted Commitment
You name a decision, then weaken it with language such as “for now,” “unless something changes,” or “we'll probably revisit this soon.” Some conditions deserve review. Others are just a way to keep the old path emotionally available.
The underlying pattern is Architecture as Avoidance, a setup that keeps you moving without making you accountable to an outcome. If the same decision returns untouched, the process isn't the problem. The founder skipped the level that would have made the call costly.
You can find a sharper diagnostic for these distortions in Shadow Patterns in decision-making. Use it to inspect the behaviour around the framework, not just the framework itself.
A One-Conversation Checklist and Where to Go Next
Run one decision through the filter in a single focused session. Don't begin by building a workspace or choosing software. Write the decision in one sentence, set a 30-minute window, and don't polish the record until each level has cleared.
Use this sequence:
Name the situation. What changed, and what makes the decision live now?
Completion test: another person can describe the condition without borrowing your interpretation.State the problem. What choice is in front of you?
Completion test: the sentence contains a decision, not a symptom.List the alternatives. What paths remain after the constraints are honest?
Completion test: every option is feasible enough to evaluate, and you've stated why any obvious path is excluded.Make the call. Which direction are you choosing?
Completion test: the sentence tells someone what will happen and what will stop.Define committed action. What visible act will make the decision operational?
Completion test: the action has an owner and a clear surface, such as a proposal, customer message, offer page, or budget change.Run the solo People check. Who will challenge the call, what is the strongest objection, and when will you review the assumptions?
Completion test: the dissent is written and the review trigger is specific.Check for a Shadow Pattern. Are you looping, inventing options, or softening the commitment?
Completion test: you can name the avoidance mechanism without turning it into another research task.
The decision-making framework template can help you turn this sequence into a reusable record. Keep the record short. The value sits in the decision, the rejected paths, the strongest assumption, and the first committed action.
If the same decision appears next week untouched, ask one question: which level did you skip?
Lucas Hubert Advisory works with founders on strategic direction, market moves, business structure, AI adoption, and other high-stakes decisions that need resolution. If you want to apply this filter to a live founder decision rather than collect another framework, visit Lucas Hubert Advisory.
