Why this is hard to get right
The Memo That Almost Killed the Deal
Marcus is a VP of Product at a 200-person B2B SaaS company. His team has been arguing for three weeks about whether to build a native document-signing feature or license an established vendor API. Engineering says build. Sales says buy. Finance hasn't weighed in yet.
The CEO wants a decision by Friday. Marcus needs to walk into that meeting with a one-page memo that ends the debate — not a deck that opens it back up.
His first attempt: he asked an AI assistant to "write a memo recommending whether we should build or buy document signing." The output was generic. It covered high-level pros and cons that anyone could Google. It didn't mention his 90-day release window. It didn't surface the SOC 2 compliance requirement. It had no score, no owner, no next step. His CFO would have laughed it out of the room.
The real problem wasn't the AI. It was the prompt.
Marcus didn't tell the model who the audience was. He didn't specify the evaluation criteria that actually mattered at his company — things like implementation time, data residency, and engineering headcount availability. He didn't give it a word limit, so the output ballooned to 900 words with no clear recommendation at the top.
When he restructured his prompt — specifying the stakeholders (CEO, CFO, Head of Engineering), the scoring rubric with a 1–5 scale, the six risk/mitigation pairs, and the hard constraint of 450 words — the output changed completely. The AI produced a memo with a clear recommendation in the opening line, a scored comparison table, five explicit assumptions, and a 30/60/90-day plan with named owners.
Marcus sent it to his CEO the night before the meeting. The CEO read it in four minutes, replied with two questions, and Marcus had answers ready. The meeting ran 22 minutes. Decision made: buy.
What changed wasn't the AI. What changed was the structure Marcus brought to the conversation. A well-built prompt forces you to decide what matters before you write a single word. It surfaces the assumptions you've been avoiding. It sets the constraints that keep the output usable.
That's what separates a memo that drives a decision from one that delays it. The harder part isn't getting AI to write well — it's knowing exactly what to ask for and being specific enough that the model can't default to generic output. The prompt is the thinking. Do that work up front, and the memo writes itself.
Common mistakes to avoid
Omitting the Stakeholder Audience
When you don't name who will read the memo, the AI writes at the wrong altitude. A CFO needs cost sensitivity front and center. An engineering head needs capacity and risk. Without audience context, you get a generic overview that satisfies no one and forces a full rewrite. Always name the specific roles who will approve the decision.
Skipping Explicit Evaluation Criteria
Asking for a build vs buy comparison without defining the criteria produces a vague pros-and-cons list. Scoring dimensions like time-to-ship, 12-month cost, and compliance must be stated in the prompt. Without them, the AI invents criteria that may not match your company's actual priorities, making the output untrustworthy for an exec decision.
Leaving Out the Recommendation Requirement
Many prompts ask for analysis but forget to demand a recommendation. The AI then hedges, presenting both sides equally and concluding with 'it depends.' Force the model to commit by stating 'include your recommendation in the opening line.' A decision memo that doesn't decide is just a summary.
Forgetting Word and Section Constraints
Without length and structure limits, AI output expands to fill the space. A 900-word memo with eight sections is not a one-page decision memo. Set a hard word limit (e.g., 450 words) and specify exact sections. This forces prioritization in the output and makes it actually usable in an exec meeting.
Not Surfacing Assumptions Explicitly
Build vs buy decisions rest on assumptions about team capacity, vendor reliability, and cost projections. If you don't ask the AI to list those assumptions explicitly, they get buried in the analysis. Require at least five named assumptions so stakeholders know what would change the recommendation — and can challenge them before the decision is made.
Treating 'Do Nothing' as a Non-Option
Most prompts compare build vs buy but skip the 'do nothing' scenario. That omission makes the memo look incomplete to a skeptical CFO or board member. Always include 'do nothing' as one of the evaluated options, even if only to show why it's inferior. It strengthens the recommendation by ruling out inaction with evidence.
The transformation
Write a memo about whether we should build or buy this feature and recommend what to do.
You’re a **VP of Product** writing a decision memo for **the CEO, CFO, and Head of Engineering**. Create a **one-page build vs buy recommendation memo** for: **[feature/capability]** in **[product]**. Include: 1. **Decision statement** and your recommendation. 2. **Options compared** (Build, Buy vendor A, Buy vendor B, Do nothing). 3. **Evaluation criteria** with a 1–5 score: time-to-ship (target **90 days**), 12-month cost, security/compliance, control, team capacity, customer impact. 4. **Assumptions** (list 5) and what would change the decision. 5. **Risks + mitigations** (at least 6). 6. **30/60/90-day plan** with owners. Tone: **direct, plain language**. Limit to **450 words**.
Why this works
Role and Audience Grounding
The After Prompt opens by assigning a specific role — 'VP of Product writing for the CEO, CFO, and Head of Engineering'. This isn't cosmetic. It tells the model what level of technical detail to use, which risks to emphasize, and how assertive the recommendation should be. Without this, the AI defaults to a neutral, academic tone that doesn't match exec expectations.
Structured Sections Remove Ambiguity
The After Prompt specifies six numbered sections — decision statement, options compared, scored criteria, assumptions, risks, and a 30/60/90-day plan. Each section has a named output requirement, so the model can't collapse them or combine them vaguely. This produces a memo that reviewers can scan in under five minutes and approve without clarification.
Scored Criteria Force Comparability
By requiring a 1-5 score across six named dimensions — including the hard constraint of 'time-to-ship targeting 90 days' — the prompt ensures all options are compared on the same terms. This prevents the AI from cherry-picking favorable factors for each option, which is the most common failure mode in vague build vs buy analyses.
Explicit Constraints Drive Usability
The 450-word limit in the After Prompt is not arbitrary. It forces the model to prioritize and eliminate filler. Combined with the 'one-page' framing, it ensures the output is actually reviewable before a meeting — not something that requires an executive to read for 20 minutes before forming an opinion.
Assumption and Risk Requirements Build Trust
Requiring five explicit assumptions and six risk-mitigation pairs does two things: it prevents the AI from treating uncertain inputs as facts, and it gives decision-makers a clear picture of what the recommendation depends on. This is the difference between a memo that earns sign-off and one that generates more questions than it answers.
The framework behind the prompt
The Decision Framework Behind Build vs Buy Memos
Build vs buy decisions fall into a category organizational theorists call structured decision problems — choices with multiple options, competing criteria, and stakeholders who weight those criteria differently. The challenge isn't identifying the options. It's comparing them on the same terms and surfacing disagreements before they derail the conversation.
The gold standard framework for this type of analysis is the Weighted Scoring Matrix, widely used in procurement, product strategy, and corporate finance. You define evaluation criteria, assign weights based on organizational priorities, and score each option. The math produces a ranked recommendation — but more importantly, it forces the team to agree on what matters before anyone argues for their preferred option.
A related approach from management consulting is the MECE principle (Mutually Exclusive, Collectively Exhaustive), developed at McKinsey. A well-structured build vs buy memo applies MECE thinking to the options list (build, buy vendor A, buy vendor B, do nothing covers all realistic paths) and to the risk list (risks shouldn't overlap or leave gaps). This is why the After Prompt requires at least six risks rather than letting the model stop at two or three.
The 30/60/90-day plan format comes from executive onboarding and project management practice. It forces the recommendation out of the theoretical and into the operational. Decisions without implementation plans stall. Exec teams have learned to distrust memos that end at the recommendation — they want to see who does what by when.
From behavioral economics, Kahneman's two-system thinking explains why explicit assumptions matter. Decision-makers often operate in System 1 (fast, intuitive) when reviewing analyses. Surfacing assumptions disrupts that and forces System 2 engagement — deliberate evaluation of what the recommendation actually depends on. A memo that buries its assumptions gets approved on vibes. A memo that lists them gets stress-tested properly.
Finally, the BLUF (Bottom Line Up Front) principle from military communication explains why the recommendation must appear in the first sentence. Executives read under time pressure. If the recommendation is buried on page two, many won't get there. BLUF is not just a style preference — it's a reading behavior accommodation that determines whether the memo actually drives a decision.
Prompt variations
You are a co-founder and CTO writing a decision memo for your founding team and lead investor.
Create a one-page build vs buy recommendation memo for: integrating real-time analytics into your early-stage B2B SaaS product.
Evaluated options: Build internally, License Mixpanel, License Amplitude, Do nothing.
Evaluation criteria (score 1-5 each):
- Time to ship (target: 60 days)
- 6-month all-in cost
- Engineering headcount required
- Vendor lock-in risk
- Customer-visible impact
Also include:
- A single clear recommendation in the first sentence.
- Three assumptions and what breaks the decision if they're wrong.
- Four risks with mitigations.
- A 30-day action plan with one owner per step.
Tone: direct and blunt. Maximum 400 words. Avoid corporate hedging.
You are a Director of IT writing a formal recommendation memo for the CIO and Procurement Committee.
Create a structured build vs buy recommendation memo for replacing the company's legacy employee onboarding system.
Evaluated options: Build on internal infrastructure, Buy Workday, Buy BambooHR, Extend current system with custom dev, Do nothing.
Evaluation criteria (score 1-5 each):
- Implementation timeline (target: 6 months)
- Total 3-year cost of ownership
- SOC 2 and data residency compliance
- Integration with existing HRIS and SSO
- Internal IT support burden
- Vendor support and SLA quality
Required sections:
- Executive summary with a clear recommendation.
- Scored comparison table.
- Six assumptions with confidence levels (high/medium/low).
- Eight risks and mitigations, flagging the top two as critical.
- A phased implementation roadmap: 30/60/90/180 days.
- Escalation criteria — what would trigger a decision reversal.
Tone: formal and compliance-aware. Maximum 600 words.
You are a Senior Engineering Manager writing an internal recommendation memo for your VP of Engineering and Product Director.
Create a technical build vs buy recommendation memo for: adding a PDF generation and export feature to the core product.
Evaluated options: Build from scratch using open-source libraries, Integrate a third-party API (e.g., PDFMonkey or DocRaptor), Do nothing and defer to Q3.
Evaluation criteria (score 1-5 each):
- Engineering effort in story points (build target: under 40 points)
- Ongoing maintenance burden
- Rendering quality and edge case handling
- API rate limits and cost at scale
- Time to first working prototype
Required sections:
- Recommendation with a one-sentence rationale.
- Side-by-side comparison on all criteria.
- Four technical assumptions with evidence or source.
- Five risks with mitigations and probability labels (likely/possible/unlikely).
- A sprint-level action plan for the next three weeks.
Tone: technical and precise. Use plain language, not jargon. Maximum 450 words.
You are a VP of Finance writing a recommendation memo for the CEO and Board of Directors.
Create a cost-focused build vs buy recommendation memo for: adopting an AI-powered contract review tool.
Evaluated options: Build a proprietary AI tool using internal engineering, License Harvey AI, License Ironclad, Do nothing.
Evaluation criteria (score 1-5 each):
- 12-month hard cost (include licensing, integration, and training)
- 24-month ROI based on legal hours saved
- Implementation risk and change management burden
- Data security and attorney-client privilege implications
- Vendor financial stability and contract terms
Required sections:
- Bottom-line recommendation in the first line.
- Scored comparison table with dollar estimates in each cell where possible.
- Five financial assumptions with sensitivity ranges.
- Six risks with mitigations, flagging two as financially material.
- Decision triggers — three conditions that would change the recommendation.
- Approval path and next steps with owners and dates.
Tone: precise and board-ready. Maximum 500 words.
When to use this prompt
Product leaders preparing an exec decision
Turn scattered inputs into a one-page recommendation that drives a yes/no call in a single meeting.
Engineering managers clarifying capacity tradeoffs
Compare build effort against vendor integration with shared criteria and explicit risks.
Finance partners validating cost assumptions
Force 12-month cost inputs and make assumptions visible before you commit spend.
Founders choosing tooling for a new market push
Decide fast when speed matters, without skipping security and long-term control.
Pro tips
- 1
Define the decision deadline so the memo matches the meeting cadence.
- 2
Specify non-negotiables like data residency, audit needs, or contract terms to avoid surprises.
- 3
List your top 3 customer outcomes so the scoring reflects real impact.
- 4
Add your best-guess numbers for build effort and vendor pricing so the memo stays grounded.
A standard build vs buy memo answers 'what should we do now?' A stronger memo answers 'what would change this answer?' That distinction matters when the decision will be revisited in 60 days.
Add this instruction to your prompt to get decision triggers:
'Include a section titled Decision Triggers with three specific conditions that would shift the recommendation. For each, name the threshold, the new preferred option, and the owner responsible for monitoring it.'
For example: 'If engineering capacity drops below two senior engineers available in Q3, the recommendation shifts from Build to Buy Vendor A.'
You can also add sensitivity ranges to your cost assumptions:
'For each cost assumption, provide a low/base/high range. Flag which assumptions carry the most financial risk if the base case is wrong.'
This technique is especially useful for board-facing memos or decisions with a 12-month payback period. It shows that the recommendation is robust — not fragile — and gives your CFO something to stress-test before sign-off.
Combined, these two techniques transform your memo from a point-in-time recommendation into a living decision framework that holds up under scrutiny.
The build vs buy framework applies across industries, but the scoring criteria change significantly by sector. Here's how to adapt the default prompt for three common contexts:
Healthcare and Life Sciences Prioritize HIPAA compliance, data residency, and audit trail requirements above cost. Add 'regulatory approval timeline' as a scored criterion. Require the risk section to flag any PHI exposure scenarios explicitly.
Financial Services and Fintech Weigh SOC 2 Type II certification, vendor financial stability, and contract exit terms heavily. Add 'regulatory reporting impact' as a criterion. Require the assumptions section to include data sovereignty and third-party audit implications.
Early-Stage Startups De-prioritize long-term maintenance burden and weight 'time to first customer value' above all other criteria. Limit the options to two (build vs. one vendor) to keep the decision fast. Drop the 90-day plan to a 30-day sprint plan.
Enterprise SaaS Add integration complexity with existing tech stack as a top-three criterion. Require the vendor options section to include contract negotiation leverage and multi-year pricing. Flag change management and training costs in the risk section.
In each case, keep the scored table and the explicit assumption list — those are universal. Only the criteria labels change.
A well-structured memo doesn't just inform a meeting — it can run one. Here's how to use the output format from this prompt as your meeting agenda:
Minute 0-3: Share the memo 24 hours in advance. Ask stakeholders to read only sections 1 and 2 (recommendation and comparison table) before the meeting.
Minute 3-10: Walk through the scored criteria table together. Ask each stakeholder: 'Are there any criteria here you'd weight differently?' Capture disagreements but don't resolve them yet.
Minute 10-18: Read the assumptions aloud. Ask: 'Which of these do we challenge?' This is where most real debates surface. The memo's assumption list transforms vague discomfort into specific objections.
Minute 18-25: Review the top two or three risks. Assign interim owners to monitor each one regardless of the final decision.
Minute 25-30: Force the decision. The recommendation is already in the memo. The question is: does the room accept it, modify it, or escalate it? Document the outcome in real time.
This structure works because the memo did the pre-work. The meeting doesn't generate the analysis — it stress-tests it. That's the difference between a 30-minute decision meeting and a two-hour alignment session.
When not to use this prompt
Avoid this prompt format in three specific situations:
When the decision is already made politically. If leadership has privately committed to a vendor or a build path, a recommendation memo won't change the outcome — it will only create a paper trail that contradicts the actual decision. In that case, use a simpler implementation planning prompt instead.
When you lack the data to score criteria honestly. If you're guessing at vendor costs, build timelines, and team capacity, the scored table produces false precision. A memo with made-up numbers damages your credibility more than no memo at all. Get real estimates first, then run the prompt.
When the decision is reversible and low-stakes. Not every tool choice needs a one-page exec memo. If you're choosing between two $200/month SaaS tools with a 30-day cancellation policy, this level of rigor wastes time. Use a lighter prompt — a simple pros/cons summary with a recommendation — and save the full memo format for decisions that commit significant budget, headcount, or architecture.
- For reversible tool trials, use a lightweight comparison table prompt instead
- For purely technical decisions without exec involvement, an engineering RFC format works better
- For decisions that require market research first, use a competitive analysis prompt before the memo
Troubleshooting
The memo doesn't include a clear recommendation — it just summarizes pros and cons
Add this line to the start of your prompt: 'Your first sentence must state your recommendation clearly. Do not hedge or say it depends.' You can also add: 'If the analysis is genuinely too close to call, state that explicitly and name the one additional data point that would decide it.' This forces the model to commit rather than defer.
The scored criteria table has identical or nearly identical scores across all options
The AI is averaging rather than differentiating. Add this instruction: 'When scoring, use the full 1-5 range. If two options score within 1 point on every criterion, flag that explicitly and explain why the decision is genuinely close.' Also specify your real constraints — if build truly takes 12 months and buy takes 6 weeks, state those numbers in the prompt so the time-to-ship scores reflect reality.
The 30/60/90-day plan uses generic role titles instead of real owners
Add a named team list to your prompt: 'For the action plan, assign owners using these roles: Sarah (Head of Engineering), James (VP of Finance), Priya (Product Lead). Do not use generic titles like the team or stakeholders.' Real names drive accountability and make the memo immediately actionable rather than theoretical.
The risks section lists generic risks that apply to any technology decision
Before the risk section instruction, add domain-specific context: 'Risks must be specific to this feature and this vendor landscape. Do not include generic risks like data breach or budget overrun without naming the specific cause in our context.' Also name your top concern explicitly: 'We are most worried about SOC 2 compliance and vendor contract flexibility — make sure those appear in the risk list.'
The output exceeds 450 words and the exec won't read it
Add a prioritization rule at the end of your prompt: 'If the output exceeds 450 words, cut detail from the scored criteria explanation first, then from the options comparison. Never cut the recommendation, assumptions, or action plan.' Run the output through a word counter and paste it back with 'This is 620 words. Cut 170 words using the rule above' as a follow-up prompt.
How to measure success
How to Evaluate the AI Output Quality
Before sending this memo to any stakeholder, run through this checklist:
Structural completeness
- The recommendation appears in the first sentence — not buried in the analysis
- All six sections from the prompt appear in the output
- The scored table includes all options and all criteria with numeric scores
Analytical quality
- Scores use the full 1-5 range — if everything clusters at 3, the model averaged rather than differentiated
- Assumptions are specific, not generic — 'engineering capacity of 2 senior engineers available in Q2' not 'sufficient engineering resources'
- Risks are named with causes, not just categories — 'Vendor API deprecation risk if DocuSign changes pricing model' not 'vendor dependency risk'
Usability for execs
- The memo is at or under 450 words
- The 30/60/90-day plan has named owners, not generic role titles
- The tone is direct — no hedging phrases like 'it may be worth considering'
Decision-readiness
- A stakeholder who reads only the first two sections knows what you recommend and why
- The memo invites challenge, not consensus — assumptions and risks are visible enough to disagree with
Now try it on something of your own
Reading about the framework is one thing. Watching it sharpen your own prompt is another — takes 90 seconds, no signup.
Turn your build vs buy context into a decision-ready memo prompt your exec team can approve in one meeting.
Try one of these
Frequently asked questions
Yes — but name placeholder vendors or categories rather than leaving it blank. For example, use 'mid-market vendor A' and 'enterprise vendor B.' The memo structure still works, and it will force you to identify what criteria matter before you shortlist vendors. You can run the memo again once you have real names.
Replace the default criteria in the prompt with the dimensions your company actually uses to evaluate tools. Common substitutes include:
- Regulatory compliance (HIPAA, GDPR) for healthcare or fintech
- Vendor ecosystem fit for companies with a dominant platform (e.g., Salesforce, AWS)
- Support model and SLA for ops-heavy teams
Keep the 1-5 scale — it makes cross-option comparison clean and fast.
Include this line in your prompt: 'Do nothing is included for completeness but assume organizational pressure to act — weight the analysis toward a decision between build and buy.' This lets the model score it fairly without letting it become the default fallback. You can also remove it from the options list if it's genuinely off the table.
Restate the limit at the end of your prompt: 'Do not exceed 450 words. If you exceed the limit, cut detail from analysis sections — never from the recommendation or risks.' Most AI models will comply with this constraint when it's explicit and includes a prioritization rule for what to cut.
Yes, with adjustments. Replace 'time-to-ship' with 'time-to-production.' Swap 'API integration' risks for supply chain or tooling risks. Keep the scored criteria table and the assumption section — those translate directly. The structure is decision-type agnostic. Change the domain language, not the format.
Add a data block to your prompt before the instructions: 'Use the following cost inputs: Build estimate: 3 engineers x 12 weeks x $12,000/week = $432,000. Vendor A annual license: $85,000. Integration estimate: $40,000.' Paste in your real numbers. The model will use them in the scoring and assumptions rather than guessing.
Add a line to your prompt: 'Note that the CEO prioritizes speed to ship; the CFO prioritizes 12-month cost. Where criteria conflict, surface the tradeoff explicitly rather than averaging it away.' This produces a memo that acknowledges the disagreement rather than hiding it — which is exactly what a good decision memo should do.
Run it once to get a draft, then iterate on the weakest section. Common second passes:
- 'Expand the risk section with two additional vendor-specific risks'
- 'Rewrite the 30/60/90-day plan with specific role owners, not generic titles'
- 'Tighten the recommendation paragraph to three sentences maximum'
Targeted iteration beats starting over every time.