Decision Support Workflow (R&D Style)

Most decisions don't fail because of bad information. They fail because of rushed framing - jumping to options before the problem is properly defined, comparing choices on the wrong criteria, or committing to a path without pressure-testing the assumptions underneath it.

This workflow is built on how experienced R&D leaders, engineers, and strategists actually make decisions under uncertainty. Instead of jumping straight to advice, it forces the decision through progressive layers of thinking. Each phase is designed to remove a specific type of cognitive error before the next layer begins.

The flow: Clarify → Define success → Explore → Compare → Stress-test → Decide → Execute

What goes in, what comes out

Inputs:

• A clear problem description (not a solution in disguise)
• Constraints (time, budget, resources, non-negotiables)
• A set of options already on the table (at minimum two; can be rough)

Outputs:

• A trade-off analysis across options
• A risk matrix
• A recommended path with justification
• A documented assumptions list

None of this requires a long meeting. A single focused session with the right inputs produces all four outputs.

Phase 1: Clarify the problem

Before evaluating any options, make sure everyone agrees on what the problem actually is.

This sounds obvious. It rarely happens. Most decision meetings start with people arguing about solutions to problems they've defined differently in their heads.

The test: Can you write the problem in one sentence without mentioning any solution? If the sentence contains a tool, technology, vendor, or approach - you've written a solution, not a problem.

Bad framing:

"Should we migrate to microservices?"

Good framing:

"Our deployment pipeline is causing 3-4 day delays when making changes to isolated features, and we need to reduce that without increasing team coordination overhead."

The good version immediately changes what options are even worth considering.

Questions that sharpen the framing:

• Why does this need to be solved now? What breaks if it isn't?
• Who feels the pain directly, and how does it manifest?
• What have we already tried, and why didn't it work?
• Is this a root cause, or a symptom of something upstream?

If the problem statement keeps shifting during this phase, that's a signal - you're probably solving the wrong thing. Pin the definition before moving forward.

Phase 2: Define what success looks like

Before comparing options, agree on what a good outcome actually is. This step eliminates entire categories of argument later.

Write down:

• The primary outcome you're optimizing for (speed, cost, reliability, reversibility - pick one)
• Two or three secondary outcomes that matter but are negotiable
• The constraints that are hard limits, not preferences

This table becomes the evaluation framework in Phase 4. Without it, the comparison becomes subjective and people default to advocating for the option they already preferred.

Watch for false constraints. "We can't change the database" is often a preference dressed as a constraint. Distinguish between what genuinely can't change and what hasn't been challenged yet. False constraints artificially narrow the option space.

Phase 3: Explore options without committing

Surface the realistic options before analyzing any of them. The goal here is breadth, not depth.

Rules for this phase:

• List at least three options. If you only have two, force a third - even an extreme one ("do nothing", "outsource completely", "start over").
• Don't evaluate yet. Just describe each option clearly enough that someone unfamiliar could understand it.
• Label the type of each option: incremental improvement, pivot, defer, hybrid, or external dependency.

Useful framing questions:

• What would we do if money weren't a constraint?
• What would we do if we only had half the time we think we have?
• What does the most conservative option look like?
• What has been tried in adjacent domains that we haven't considered?

The point of this phase is to avoid premature convergence. Most teams anchor on the first option discussed and spend the rest of the session defending or attacking it. Listing all options before evaluating any of them prevents that.

Phase 4: Compare trade-offs

Now apply the success criteria from Phase 2 to each option.

Build a trade-off matrix:

Weights should reflect Phase 2 priorities. If the primary objective carries 40% and an option scores low on it, no amount of secondary-criteria wins rescues it.

What to watch for:

• Options that score high on secondary criteria but low on the primary objective are usually the safe-feeling wrong choice.
• Options with low reversibility need higher execution confidence to justify the risk.
• If two options score similarly across all criteria, add a new criterion - you're missing a dimension that will matter in practice.

Don't collapse this into a single score too early. The matrix is meant to make trade-offs visible, not hide them behind a weighted average.

Phase 5: Stress-test the leading option

Before committing, break the preferred option on purpose.

Most decisions fail not because the option was wrong in theory but because an assumption embedded in it was wrong in practice - and no one checked.

For the leading option, document every assumption:

List every statement that must be true for this option to work as expected. Then challenge each one.

Pre-mortem the decision: Imagine it's six months from now and this decision has failed badly. What went wrong? Write it down. This surfaces risks that forward-looking analysis misses because people don't want to be the pessimist in the room.

Ask the adversarial questions:

• What would have to be true for the second-best option to actually be the right call?
• What new information in the next 30 days could change this decision?
• Who in the organization will push back hardest on this path, and are they seeing something we're not?

If stress-testing reveals that a low-confidence assumption is also load-bearing, either fix the assumption first or revise the option to remove the dependency.

Phase 6: Decide and document

A decision has three components: the path chosen, the reasoning, and the conditions under which it gets revisited.

Decision record format:

Decision: [What we're doing]
Date: [When this was made]
Owner: [Who is accountable]

Rationale:
- [Why this option over the alternatives - reference the trade-off matrix]
- [Key trade-offs we accepted]

Assumptions we're betting on:
- [List the load-bearing assumptions from Phase 5]

Conditions for revision:
- [Trigger 1: if X happens within Y timeframe, we revisit]
- [Trigger 2: if assumption Z turns out to be false]

Alternatives considered:
- [Option B: why not this]
- [Option C: why not this]

The decision record isn't bureaucracy - it's a forcing function. Writing down the rationale exposes weak reasoning before it's too late. Documenting revision conditions prevents sunk-cost attachment to a bad path six months later.

Do not delegate the final call to a committee, a consensus, or a vote. One person owns it. Others inform it. The owner is accountable for the outcome, not just the process.

Phase 7: Define the execution path

A good decision without a clear first move is just a plan. Define the first 30 days specifically enough that a team could start tomorrow without another meeting.

Execution checklist:

• Owner assigned with explicit accountability
• First milestone defined (what does "it's working" look like in 4 weeks?)
• Dependencies identified and de-risked (who or what can block this?)
• Load-bearing assumptions have owners and check-in dates
• Communication plan: who needs to know this decision was made, and when?
• Rollback or reversal plan defined (if relevant)

On sequencing: Don't start on all fronts at once. Identify the one thing that, if it fails, invalidates the entire plan - and go there first. If the critical assumption is about technical feasibility, that's your first spike. If it's about stakeholder buy-in, that's your first conversation.

The goal of this phase is to make the decision real - translating a document into motion.

Cognitive errors this workflow removes

Each phase targets a specific failure mode in decision-making:

The short version

1. Write the problem without mentioning any solution. If a solution is in your problem statement, rewrite it.
2. Agree on what success looks like before comparing options. Primary objective first, constraints second.
3. List at least three options before evaluating any. Always include a "do nothing" and an extreme option.
4. Use a matrix to make trade-offs explicit. Don't collapse to a single score too early.
5. List every load-bearing assumption in the leading option and stress-test them. Run a pre-mortem.
6. One person owns the decision. Document the rationale and the conditions for revisiting it.
7. Define the first 30 days before the meeting ends. Owner, milestone, first dependency to de-risk.

Good decisions don't require more information - they require better framing. This workflow is that framing.