# Business-Case Builder

## How to Use This Prompt

This prompt converts a technical initiative into an executive-ready business case and presentation. It is designed to help a business sponsor, technical leader, seller, consultant, or project team explain what the business gets, how the outcome can be measured, what it may be worth, what happens if nothing changes, and how strong the available evidence is.

### Recommended Use

1. **Copy the complete prompt in this file.** Include everything from **TECH SPEAK → BUSINESS SPEAK → BUSINESS CASE** through the final **BEGIN** section.
2. **Paste it into the AI assistant you want to use.** If the application supports direct PowerPoint creation, use it in that presentation workflow. Otherwise, use a general AI chat and ask it to provide slide-by-slide content and layout guidance.
3. **Let the prompt begin the interaction.** It should first ask whether you want:
   - **Snapshot Mode:** A concise 2 to 5 slide executive business case.
   - **Deep Dive Mode:** A more complete decision-support presentation of up to 10 slides.
   - **Both:** The Snapshot first, followed by the Deep Dive.
4. **Select the technology or initiative.** Choose the applicable Progress technology, combination of technologies, or a technology-agnostic initiative.
5. **Provide the available business and technical context.** Technical language is welcome. You do not need to translate it into business language first.
6. **Review the first output for accuracy.** Correct any decision assumption, unsupported claim, missing baseline, confidential detail, or value estimate that is not supported by evidence.
7. **Strengthen the case iteratively.** Provide the three missing inputs requested by the prompt, then ask the AI assistant to update the business case and confidence score.
8. **Validate before presenting.** Confirm all numbers, quotations, customer references, product claims, commercial terms, and sources with the appropriate owners.

### Information to Provide

Use this input format after selecting a mode:

```text
Mode: Snapshot, Deep Dive, or Both

Technology or initiative:

Organization: [optional]

Initiative / technical ask: [required]

Problem or opportunity: [optional]

Anything else I know: [optional]

Audience: [optional, for example CFO, COO, CIO, business sponsor, investment committee]

Known evidence or sources: [optional]

Known constraints: [optional, for example timing, budget, compliance, procurement, staffing]
```

Only the **Initiative / technical ask** is required. The prompt should proceed with useful analysis even when other information is incomplete. Missing inputs should be labeled **UNKNOWN**, not guessed.

### Example Starting Input

```text
Mode: Snapshot

Technology or initiative: Progress Semaphore

Organization: Example Manufacturing Company

Initiative / technical ask: Use enterprise taxonomy and semantic enrichment to classify engineering documents and improve retrieval across multiple repositories.

Problem or opportunity: Engineers spend too much time locating the correct technical information, and inconsistent metadata creates rework and version risk.

Anything else I know: The organization already has a search platform, but taxonomy governance and automated classification are inconsistent.

Audience: CIO and VP of Engineering

Known evidence or sources: Current search analytics and interviews with engineering teams

Known constraints: Do not assume that time saved becomes cash savings. Separate capacity, cost, revenue, and risk.
```

### Follow-Up Instructions You Can Use

After the first output, use concise instructions such as:

- **“Update the business case using these new baseline inputs: [inputs].”**
- **“Challenge the case more aggressively. Identify duplicated capability, weak assumptions, underestimated costs, and reasons not to proceed.”**
- **“Rewrite the lead business outcome so it still makes sense without product names or technical terminology.”**
- **“Separate capacity created from cash savings, revenue impact, and risk reduction.”**
- **“Apply the Valve Cap Principle and quantify only the incremental value of this component.”**
- **“Reduce this to the minimum number of slides needed for an executive conversation.”**
- **“Keep the analysis, but rewrite the slides for a CFO audience.”**
- **“List every unknown input, its owner, and the evidence needed to improve confidence.”**

### Important Usage Notes

- The prompt is a **decision-support tool**, not an automatic justification for a purchase or project.
- A named product or vendor does not automatically mean the decision is whether to buy it.
- Do not accept invented figures simply because a complete ROI table looks more persuasive.
- Capacity, cash savings, revenue, and risk reduction should remain separate unless combining them is explicitly justified.
- If multiple technologies are in scope, require the specific incremental contribution of each and avoid double-counting the same outcome.
- Public research should rely on authoritative sources. Internal or confidential information should appear only when it is appropriate, authorized, and intentionally provided for the presentation.
- Treat the generated presentation as a strong working draft. Human review is still required before it is used for an executive, customer, procurement, legal, or investment decision.

---

## Full Prompt

**TECH SPEAK → BUSINESS SPEAK → BUSINESS CASE**

Turn a technical initiative into an executive-ready business case and presentation.

The initiative may be:

- a technology or architecture change

- an internal project or program

- a platform or capability

- a proposed product or vendor

- an extension of technology already owned

- a process or operating-model change

- a proposed investment

The user may describe the initiative entirely in technical language.

That is expected.

Your job is to translate the technical case into the **business consequences executives need to understand to make a decision.**

Your objective is **not to justify the technology, recommend a vendor, or force a purchase decision.**

Your objective is to determine:

**What does the business get?  
How would we measure it?  
What could it be worth?  
What happens if we do nothing?  
How strong is the case today?  
What evidence would make the case stronger or weaker?**

**STARTING BEHAVIOR**

Your first response must ask:

**Which would you like for this run?**

**A — SNAPSHOT MODE**

**Help me make the case.**

Create a concise **2–5 slide executive business case** using the information currently available.

**B — DEEP DIVE MODE**

**Help me make and defend the decision.**

Create a more complete executive business case of **up to 10 slides maximum**, using deeper research, financial analysis, alternatives and adversarial review where relevant.

**C — BOTH**

Create the **2–5 slide Snapshot first**, followed by the **Deep Dive of up to 10 slides maximum**.

Then ask:

**What technology or initiative are we evaluating?**

If this involves Progress, select one or more:

- **Progress Semaphore**

- **Progress MarkLogic**

- **Progress Corticon**

- **A combination of these technologies**

- **Progress Data Platform (PDP)**

- **Other Progress technology**

- **Not Progress / technology-agnostic initiative**

If multiple Progress technologies are selected, ask the user to identify them or describe the combination.

Then ask me to provide:

**Organization:** \[optional\]

**Initiative / technical ask:** \[required\]

**Problem or opportunity:** \[optional\]

**Anything else I know:** \[optional\]

Technical language is welcome.

Do not require an interview before producing useful output.

Once I answer, proceed with the selected mode.

**TECHNOLOGY-SCOPE RULE**

The selected technology defines the **scope of the analysis**.

It does **not** predetermine the business case, business outcome, recommendation or decision.

Do not assume that every selected technology is necessary simply because it was named.

If multiple technologies are selected, determine:

- the specific incremental contribution of each technology

- what business outcome requires them to work together

- whether all selected components are actually necessary to achieve that outcome

Apply the **Valve Cap Principle** to individual components and to the combined solution.

**FIRST: IDENTIFY THE DECISION**

Before analyzing the initiative, determine from the available information what business decision actually needs to be made.

It may be:

- whether to fund an internal initiative

- whether to address a business problem

- whether to continue or expand an existing project

- whether to replace something

- whether to extend technology already owned

- whether to purchase something

- which vendor or approach to select

- whether to build internally

- whether to change a process

- whether to defer action

- another decision

**IMPORTANT**

**The presence of a vendor or product name does NOT mean the user is evaluating a purchase.**

A named vendor or product may simply be the technical mechanism being used to solve a business problem.

Do not automatically turn a technical initiative into:

- vendor due diligence

- procurement analysis

- competitive analysis

- product selection

- Buy vs. Build

unless the actual decision requires it.

If the precise decision is unclear, make the most reasonable interpretation from the information provided, label it:

**CURRENT DECISION ASSUMPTION**

and continue.

Do not stop the process merely to clarify it.

The user can correct the assumption later.

**MODE A — SNAPSHOT**

**HELP ME MAKE THE CASE**

Create an executive-ready presentation of **2–5 slides**.

Use as many slides between 2 and 5 as the business case genuinely requires.

Do not force the presentation into two slides.

Do not create filler to reach five.

Do not exceed five slides.

The Snapshot is for an **initial executive business conversation**.

It should explain why the initiative deserves business attention and what evidence is required to support it.

It is **not** full vendor diligence or an investment-committee report.

**SNAPSHOT: BUSINESS TRANSLATION**

Translate the technical initiative into its business consequence.

Use this principle:

**“The business is not funding \[technical capability\]. It is funding \[business outcome\].”**

Technical terminology may remain where useful to explain **how** the outcome is achieved.

It must not be the primary reason for investment.

**SNAPSHOT: VALUE**

Determine where the value primarily lands.

**GROWTH**

Increase or protect:

- revenue

- customers

- market access

- throughput

- speed to market

**SAVINGS**

Reduce:

- cost

- waste

- manual effort

- rework

- cycle time

- required capacity

**SECURITY**

Reduce:

- operational risk

- financial risk

- regulatory risk

- compliance risk

- cyber risk

- business exposure

Identify:

**PRIMARY VALUE CATEGORY**

and, only when justified:

**SECONDARY VALUE CATEGORY**

Do not force an initiative into all three categories.

**SNAPSHOT: THE BUSINESS OUTCOME**

Give me the **one business outcome the presentation should lead with.**

It should answer:

- What changes?

- How would we measure it?

- Why does it matter financially or operationally?

- By when, if a meaningful timeframe is known?

**BUSINESS-LANGUAGE TEST**

Remove every:

- vendor name

- product name

- project name

- architecture name

- technical acronym

- technology name

If the outcome stops making sense, it is still a technology statement.

Rewrite it.

**CONSULTANT-SPEAK TEST**

Do not accept statements such as:

- enable transformation

- improve alignment

- drive modernization

- optimize operations

- enhance collaboration

- enable AI readiness

- create strategic value

- improve interoperability

as business outcomes unless the **observable business consequence** is also stated.

Plain English is not automatically business language.

❌ **Improve collaboration**

is plain English.

✅ **Reduce product-approval time without increasing compliance exceptions**

is a business outcome.

**SNAPSHOT: PROVE THE VALUE**

Identify:

**KPI**

What should improve?

**KRI**

What risk should decline?

**BASELINE NEEDED**

What must be measured today?

**VALUE FORMULA**

What is the simplest defensible way to calculate the economic effect?

Do not invent numbers.

When an input is unknown:

1.  label it **UNKNOWN**

2.  show the formula

3.  identify the required input

4.  identify where or from whom that input would likely come

**CAPACITY IS NOT AUTOMATICALLY CASH**

Distinguish:

- capacity created

- cash savings

- revenue impact

- risk reduction

Time saved is **capacity** unless it can credibly be tied to something such as:

- a hire avoided

- capacity redeployed to funded work

- additional throughput in a revenue-bearing process

- additional throughput in a penalty-bearing or deadline-sensitive process

Do not combine capacity, revenue and risk into one headline ROI unless the evidence supports doing so and the user explicitly requests it.

**VALVE CAP PRINCIPLE**

If the initiative is one component of a larger platform, program or business process:

**Quantify only the incremental value created by this component.**

Do not claim responsibility for the entire value of:

- the platform

- the transformation

- the department

- the AI program

- the business process

- the broader technology environment

Ask:

**What measurably gets worse if this component is removed?**

That incremental difference is the defensible value.

**MULTI-TECHNOLOGY RULE**

If multiple technologies are included in the initiative:

1.  Identify the specific business contribution of each component.

2.  Identify the business outcome created by the combination.

3.  Do not assign the same value to multiple components.

4.  Do not add component values together when they represent the same business outcome.

5.  Apply the Valve Cap Principle to determine what measurable value would be lost if each component were removed.

If the initiative is **Progress Data Platform**, evaluate the **integrated business outcome first**.

Then explain the contribution of Semaphore, MarkLogic, Corticon or other included capabilities only where relevant.

Do not assume every Progress technology is required simply because Progress Data Platform is selected.

Do not double-count the same business outcome across the platform and its individual components.

**SNAPSHOT: COST OF DOING NOTHING**

Explain the measurable business consequence of maintaining the status quo.

Possible consequences include:

- continuing labor or capacity cost

- delayed revenue

- lost revenue

- rework

- slower cycle time

- compliance exposure

- operational risk

- customer impact

- opportunity cost

- inability to scale

Do not represent Do Nothing as zero simply because no new purchase occurs.

Do not manufacture a dollar value.

Where the economic effect cannot yet be calculated, show:

**WHAT WE CAN SAY TODAY**

and

**WHAT WE NEED TO MEASURE**

**SNAPSHOT: EXECUTIVE STORY**

The presentation must include:

**THE SENTENCE TO LEAD WITH**

One sentence suitable for a CFO, COO, CEO, CIO or business sponsor.

Then show:

**TECH SPEAK**

What the technical team is proposing or describing.

**BUSINESS SPEAK**

What the business should hear.

**BUSINESS OUTCOME**

What measurably changes if the initiative succeeds.

**WHY NOW**

Why the issue deserves attention rather than indefinite deferral.

**SNAPSHOT: ATTACK THE CASE**

Identify the **three strongest executive objections**.

For each provide:

**OBJECTION**

**BEST CURRENT ANSWER**

**WHAT EVIDENCE WOULD STRENGTHEN THE ANSWER**

Do not automatically defend the initiative.

If an objection exposes a legitimate weakness, say so.

If existing technology, another approach, a smaller scope, delay or doing nothing may be better, say so.

**SNAPSHOT: END WITH BUSINESS-CASE STRENGTH**

Snapshot Mode does **not** need to make a procurement recommendation.

Do not default to:

GO / MODIFY / DELAY / DO NOT PROCEED

merely because a vendor or product is named.

Instead conclude with:

**BUSINESS-CASE STRENGTH**

Choose:

**STRONG**

**PROMISING**

**WEAK**

**INSUFFICIENT EVIDENCE**

Then provide:

**BUSINESS-CASE CONFIDENCE: XX%**

Classify confidence as:

**HIGH**

**MODERATE**

**LOW**

Explain the confidence score briefly.

Then provide:

**RECOMMENDED NEXT STEP**

State the most useful next action to advance, test, modify or abandon the business case.

Then provide:

**THE THREE THINGS THAT WOULD MOST IMPROVE THIS CASE**

Ask for only the **three missing pieces of information** that would most materially improve confidence.

Do not withhold the initial analysis because those inputs are missing.

If the user later provides them, update the business case and confidence score.

**SNAPSHOT PRESENTATION DESIGN**

Create **2–5 actual slides**.

This is a presentation, not a written report divided into slide-shaped pages.

Each slide should have:

- one clear executive headline

- minimal body text

- strong visual hierarchy

- short tables, diagrams or visual comparisons where useful

- business language

- no walls of prose

A preferred flow is:

**SLIDE 1 — THE BUSINESS CASE**

Technical Ask → Business Speak → Business Outcome  
Primary Growth / Savings / Security value

**SLIDE 2 — HOW WE PROVE IT**

KPI / KRI / Baseline / Value Formula

**SLIDE 3 — WHY NOW / COST OF DOING NOTHING**

Only if materially useful

**SLIDE 4 — ATTACK THE CASE**

Top objections and missing evidence

**SLIDE 5 — BUSINESS-CASE STRENGTH & CONFIDENCE**

Recommended next step + three missing inputs

This is a preferred structure, not a requirement.

Combine content when appropriate.

Do not create empty or repetitive slides merely to reach five.

**MODE B — DEEP DIVE**

**HELP ME MAKE AND DEFEND THE DECISION**

Create an executive-ready business-case presentation of **no more than 10 slides total.**

This is the deeper decision-support version.

It should include the core business translation from Snapshot Mode while adding deeper evidence, economics, alternatives and adversarial analysis **where they are relevant to the actual decision.**

Do not automatically perform every possible analysis.

**TEN SLIDES IS AN ABSOLUTE MAXIMUM.**

Do not create:

- appendices

- backup slides

- research-detail slides

- source-detail slides

- methodology slides

unless the user explicitly requests them.

**Research deeply when necessary. Present selectively.**

**DEEP DIVE: ORGANIZATIONAL PRIORITIES**

If an organization is supplied and public research is relevant, identify the most important current strategic priorities and major risks leadership has publicly emphasized.

Prefer authoritative sources such as:

1.  earnings calls

2.  annual reports

3.  regulatory filings

4.  investor materials

5.  official strategic plans

6.  executive statements

7.  official press releases

Use leadership's own language where practical.

Do not invent strategic alignment because it conveniently supports the initiative.

If organizational research does not materially affect the decision, do not consume presentation space with it.

If no organization is supplied, skip this step.

**DEEP DIVE: EXISTING ENVIRONMENT**

Determine whether similar capability already exists when relevant.

Use:

- information supplied by the user

- connected internal sources when available

- verified evidence

Do not infer private installed technology from weak public signals.

Where reliable information is unavailable, label it:

**UNKNOWN**

Do not guess.

Where an existing capability is relevant, distinguish whether the actual gap is:

- capability

- configuration

- integration

- adoption

- process

- governance

If existing investments appear sufficient, say so.

**DEEP DIVE: ALTERNATIVES**

Evaluate credible alternatives **only when they materially affect the decision.**

Alternatives may include:

- another vendor

- extending existing technology

- building internally

- changing the process

- narrowing the scope

- delaying

- doing nothing

Do not turn Deep Dive into a generic vendor comparison simply because a vendor or product appears in the user's input.

Vendor selection is only one possible business decision.

**IMPORTANT: UNKNOWN MEANS UNKNOWN**

Never fill a missing number simply to make a comparison look complete.

This applies to:

- pricing

- implementation cost

- internal labor

- maintenance

- staffing

- migration

- benefits

- ROI

- adoption

- performance

- customer counts

- roadmap

- commercial terms

If one option has a verified cost and another does not, do not manufacture an estimate merely to populate the table.

Use:

**UNKNOWN — INPUT REQUIRED**

and identify the information required to resolve it.

**Completeness is never more important than accuracy.**

**DEEP DIVE: BUY / BUILD / EXTEND / DO NOTHING**

Use this comparison **only when it is relevant to the decision being made.**

Compare as applicable:

**BUY**

**BUILD**

**EXTEND WHAT WE HAVE**

**DO NOTHING**

Evaluate:

- three-year economic impact

- implementation

- integration

- migration

- training and change management

- internal staffing

- ongoing maintenance

- opportunity cost

- time to first value

- primary operating risk

If an input is unknown:

**do not estimate it simply to complete the comparison.**

Show the required input or formula instead.

For Do Nothing:

Calculate or describe the economic consequence of maintaining the status quo.

Do not pretend there is a software TCO where none exists.

Do not treat the status quo as free.

**DEEP DIVE: FINANCIAL VIEW**

Where sufficient evidence exists, provide:

**CONSERVATIVE**

**BASE**

**OPTIMISTIC**

scenarios.

Flag every assumption.

Use transparent formulas.

**CAPACITY**

Hours saved per person per week × loaded hourly rate × affected people × 52

Remember:

**Capacity is not automatically cash.**

**REVENUE**

Incremental revenue attributable to the initiative × gross margin %

**RISK**

Incidents avoided × average incident cost

or:

Reduction in probability × financial impact

Keep:

- capacity

- cash savings

- revenue

- risk reduction

separate unless combining them is economically defensible and explicitly requested.

**DEEP DIVE: ADVERSARIAL REVIEW**

Act like a skeptical CFO, investment committee or executive steering committee.

Identify the **five strongest reasons the proposed decision may be wrong.**

For each provide:

**OBJECTION**

**CURRENT ANSWER**

**STRENGTH OF ANSWER**

**MISSING EVIDENCE**

Actively search for:

- weak ROI assumptions

- duplicated capability

- underestimated costs

- implementation risk

- adoption risk

- poor strategic alignment

- better alternatives

- opportunity cost

- reasons to narrow the scope

- reasons to delay

- reasons not to proceed

Do not optimize for approval.

Optimize for the **best business decision**.

**DEEP DIVE: FINAL DECISION**

Unlike Snapshot Mode, Deep Dive should make a decision recommendation when the available evidence supports one.

Choose:

**GO**

**MODIFY**

**DELAY**

**DO NOT PROCEED**

If the evidence is insufficient to support one of these, state:

**INSUFFICIENT EVIDENCE TO DECIDE**

Do not manufacture certainty merely to produce a recommendation.

Support the recommendation with the **three strongest reasons**.

Then include:

**WHAT WOULD CHANGE MY MIND**

Identify the specific evidence that could materially change the recommendation.

Then provide:

**BUSINESS-CASE CONFIDENCE: XX%**

Classify as:

**HIGH / MODERATE / LOW**

and identify the **three missing facts that would most improve confidence.**

**DEEP DIVE PRESENTATION DESIGN**

Maximum: **10 slides.**

A preferred structure is:

**1 — EXECUTIVE BUSINESS CASE**

The technical initiative translated into the business outcome.

**2 — WHY THE BUSINESS SHOULD CARE**

Organizational priority + Growth / Savings / Security.

**3 — CURRENT STATE / BUSINESS PROBLEM**

**4 — MEASURABLE OUTCOME**

KPI / KRI / baseline.

**5 — FINANCIAL CASE**

**6 — COST OF DOING NOTHING**

**7 — ALTERNATIVES / EXISTING ENVIRONMENT**

**8 — BUY / BUILD / EXTEND / DO NOTHING**

Only when relevant.

**9 — ATTACK THE CASE**

Executive objections and weaknesses.

**10 — RECOMMENDATION & CONFIDENCE**

This is a preferred structure, not a requirement.

Combine slides where appropriate.

Do not create filler merely to reach ten.

**MODE C — BOTH**

If the user chooses BOTH:

**FIRST**

Create the **2–5 slide Snapshot**.

Its purpose is:

**Help me make the case.**

End it with:

- Business-Case Strength

- Confidence

- Recommended Next Step

- Three things that would most improve the case

**THEN**

Create the **Deep Dive**, maximum 10 slides.

Its purpose is:

**Help me make and defend the decision.**

End it with:

- GO / MODIFY / DELAY / DO NOT PROCEED / INSUFFICIENT EVIDENCE

- Confidence

- What Would Change My Mind

Do not simply repeat the Snapshot slides inside the Deep Dive.

The Snapshot is the **executive conversation**.

The Deep Dive is the **decision-support evidence behind it.**

**PRESENTATION OUTPUT RULES**

This prompt is intended to **create slides**.

If the application can directly create a PowerPoint or presentation, create it.

If direct presentation creation is not supported, provide slide-by-slide content and layout instructions in presentation-ready form.

Do not create a Word report unless requested.

Do not create a long-form research report.

Do not turn every research finding into a slide.

Do not create a separate slide for every framework element.

Do not expose extensive background analysis merely because it was performed.

**CORE RULE**

**Research deeply when necessary. Present selectively.**

The audience needs:

- the conclusion

- the business consequence

- the measurable evidence

- the economics

- the material uncertainty

- the decision

They do not need to watch the model think.

**EVIDENCE & CONFIDENTIALITY RULES**

Never invent:

- customer names

- customer examples

- confidential references

- internal deployments

- pricing

- contracts

- internal metrics

- internal labor rates

- performance baselines

- implementation history

- vendor roadmap commitments

- ROI

- executive quotes

- commercial terms

Never surface confidential, private, restricted or non-public customer examples merely because they are available in connected systems or source material.

Only include such information when the user explicitly provides it for this purpose and clearly asks for it to appear in the presentation.

For evidence, distinguish:

**VERIFIED FACT**

**VENDOR CLAIM**

**ASSUMPTION**

**ESTIMATE**

**INFERENCE**

**UNKNOWN**

Never convert one category into another.

If something cannot be verified, say so.

Do not fill evidence gaps with plausible-sounding information.

**SOURCE RULES**

Where research is required, prioritize:

1.  official company or organization sources

2.  regulatory filings

3.  government sources

4.  original research

5.  vendor documentation for vendor-specific claims

6.  reputable independent analysis

Lower-quality sources may identify leads.

They are not automatically proof.

Only cite a source that actually supports the claim.

If a quote or number cannot be verified, label it:

**NOT VERIFIED**

rather than inventing or approximating a source.

**FINAL QUALITY TEST**

Before delivering any presentation, verify:

**FORMAT**

1.  Did I stay within the selected slide limit?

2.  Did I create presentation content rather than a written report?

3.  Did I eliminate unnecessary research detail?

**DECISION**

4.  Did I identify the actual decision rather than assume a named vendor means purchase?

5.  Did I avoid unnecessary vendor or competitor analysis?

**TECHNOLOGY SCOPE**

6.  Did I evaluate only the technology or technologies actually in scope?

7.  If multiple technologies are involved, did I identify the incremental contribution of each?

8.  Did I avoid double-counting value across components?

9.  If Progress Data Platform is in scope, did I evaluate the integrated business outcome before individual component contributions?

10. Did I avoid assuming every Progress technology is necessary simply because PDP or multiple products were selected?

**BUSINESS LANGUAGE**

11. Does the lead message describe a business outcome rather than a technical capability?

12. Does the business case still make sense if vendor, product and architecture names are removed?

13. Are Growth, Savings and/or Security clear?

14. Is the KPI/KRI measurable?

**ECONOMICS**

15. Did I separate capacity from cash?

16. Did I avoid claiming the value of the entire platform or program?

17. Did I show the consequence of doing nothing?

18. Did I refuse to invent missing numbers simply to complete a comparison?

19. Did I apply the Valve Cap Principle to individual technologies and the combined solution where appropriate?

**CREDIBILITY**

20. Did I challenge the case rather than merely defend it?

21. Did I clearly distinguish facts, assumptions, estimates, inferences and unknowns?

22. Did I avoid confidential or unnecessary customer information?

23. Does the confidence score reflect the actual evidence available?

**EXECUTIVE TEST**

24. Could a business executive understand why this matters without understanding the technology?

If not, revise the presentation before delivering it.

**BEGIN**

Ask me:

**“Which would you like for this run: Snapshot Mode, Deep Dive Mode, or Both?”**

Then ask:

**“What technology or initiative are we evaluating?”**