Example library
Every example below is synthetic. They show how a review is designed, where it adapts, and what the report contains — not customers, results, or engagements. No customer names, logos, metrics, or outcomes appear anywhere on this site.
AI assistant: build, buy, partner, or stop
Follow the review as it changes shape. Each step is a decision about where the next unit of intelligence is worth spending.
Illustrative review story
Decision context and input packet
A 90-person B2B SaaS company must decide whether to build, buy, partner, or stop an AI assistant initiative before the next planning cycle. The CPO owns the decision.
Input packet: roadmap extract, two engineers' effort estimates, a vendor quote, twelve months of feature usage data, and the current price list.
Illustrative sample. Not a customer engagement; no client data is represented.
The same two options, no longer fuzzy
The review did not choose for the CPO. It made the comparison explicit and named the conditions under which each option is the right one.
Before review
- Option A feels roughly safer and more likely to work.
- Option B feels more ambitious and less certain.
The preference is intuitive. The trade-offs are fuzzy, and nobody can say what would have to be true for the other option to win.
After review
- Expected value
- A 1× (illustrative unit)B 2× (illustrative unit)
- Cost
- A 1×B 3×
- Execution risk
- A Lower — known workflowB Higher — new dependency
- Time to first evidence
- A One quarterB Three quarters
Conditional triggers
- Option B becomes the stronger choice only above a defined weekly-adoption threshold.
- Option B depends on an integration that is not currently on the roadmap.
The decision is still yours. The trade-offs are no longer hidden.
One review, three usable documents
With two options still live, a single long document would serve neither. The executive review is for choosing; each path is for delivering.
For choosing
Executive Decision Review
- Recommendation and the reasoning behind it
- The decisive trade-offs between alternatives
- Assumptions the answer rests on
- Remaining uncertainty, stated plainly
For executing, if chosen
Option A path
- Expected value and cost profile
- Milestones and sequencing
- Resources and dependencies
- Risks and decision triggers
For executing, if chosen
Option B path
- The corresponding execution path
- Where it diverges from Option A
- What must be true for it to win
- Early signals to watch
You use the short review to choose, then keep the selected path as operational material. This is a delivery structure, not necessarily more analysis.
What the report looks like
One founder-reviewed document. Recommendation first, then the reasoning, the disagreements, the triggers, and what the review could not establish.
- 01
Recommendation
Conditional: license for two quarters, instrument adoption against a stated threshold.
- 02
Credible alternatives
Build now · license · partner · stop, each with what it costs to be wrong.
- 03
Evidence and research
What is measured, what is estimated, and what is an assumption.
- 04
Disagreements
Where independent human experts diverged, and whether the dispute is factual.
- 05
Conditions that would change the conclusion
Named triggers, with the threshold for each.
- 06
Limitations
What the review could not establish, stated plainly.
Structure shown for illustration. No document is available for download.
Two more illustrative reviews
AI pricing and target-market decision
Price and package a new AI capability, and decide which segment the packaging should be optimised for, ahead of the annual price revision.
- Input packet
- Current price list and discount history
- Win/loss notes for the last two quarters
- Cost-per-request estimates from engineering
- Segment-level retention and expansion figures
- Expertise lanes considered
- B2B SaaS product and pricing
- GTM and positioning
- Cloud architecture and FinOps (cost behaviour only)
- Finance and capital allocation
- How the process adapted
- An early finding — that discount depth correlated with one segment rather than deal size — moved the review from “what price” to “which buyer we are pricing for”. A planned competitive-benchmark lane was dropped because it would have repeated known information.
- Material disagreement
- The pricing perspective favoured a usage-based module for margin protection; the GTM perspective argued procurement in the target segment would reject a variable line item. Both were right about different buyers, which exposed that the segment choice preceded the pricing choice.
Technical-debt and modernization prioritization
Decide which parts of a ten-year-old platform to modernize in the next two quarters, and in what sequence.
- Input packet
- Architecture overview and service inventory
- Incident history for eighteen months
- Delivery throughput and cycle-time data
- Committed enterprise roadmap items
- Expertise lanes considered
- Cloud architecture and FinOps
- Founder / general management (capacity and sequencing)
- Customer success and operations (support load)
- How the process adapted
- The review began with the subsystem the team named as the worst. Incident and cycle-time data did not support it as the delivery constraint, so attention shifted to the dependency chain behind the committed enterprise tier.
- Material disagreement
- The architecture perspective preferred a full extraction of the legacy component; the management perspective judged that unexecutable alongside the committed roadmap. The disagreement was about capacity, not correctness, and is reported as a sequencing constraint.
Would your decision look like one of these?
Describe it in a few lines. If a review is not the right instrument, we will say so before proposing anything.