Effective Writing

Product writing helps people decide: approve an investment, resolve a tradeoff or commit to a launch. State the ask, support it with evidence and make the alternatives clear. Use AI to draft from your reasoning.

Why this matters

PMs rely on arguments to coordinate people they do not manage. Written arguments travel beyond the meeting and preserve the rationale for a choice. Writing also tests whether evidence supports the recommendation.

Fast AI drafting increases the cost of weak thinking passed to readers. A 2025 HBR article by Kate Niederhoffer and colleagues called apparently finished but unhelpful AI output workslop. In its BetterUp survey of 1,150 US desk workers, 40% reported receiving it that month and estimated about two hours of rework per instance.

Useful product writing gives the reader a specific decision, sourced evidence, honest tradeoffs and a recommendation. This chapter covers objective, audience, structure, formats, persuasion and AI-assisted drafting. Chapters 35 and 36 cover presentation and stakeholder relationships.

Start with the objective and the reader

Narrow the objective until someone can say yes

Define the decision before drafting. “Improve agent quality” names a topic. “Approve a one-quarter hold on the autonomous tier before launch content lock” names an action a decider can accept or reject.

A narrowed objective has four parts:

• The action: what you want to happen, stated as a verb (approve, fund, choose, stop, agree).
• The decider: the one person whose yes makes it happen. If you can’t name them, you’re writing to the wrong reader.
• The deadline: when the decision is needed, and why that date.
• The scope: what’s included and, just as important, what isn’t.

Write the objective in one sentence. If a yes or no would leave the next step unclear, narrow it further. Separate independent asks.

Audience analysis

Aristotle’s Rhetoric distinguishes ethos (credibility), pathos (audience emotion) and logos (argument), as summarized by philosopher Christof Rapp. Readers weight these differently. Understand their evidence needs, personal stakes and trust in you before choosing the emphasis.

Map the proposal’s decider, veto holders, advisers and implementers, as you would a customer buying group (Chapter 01). Answer these questions for each:

AI summaries may become the first version readers see. Microsoft’s 2025 Work Trend Index reported AI use for internal communications among 68% of leaders at “Frontier Firms,” versus 46% globally. Put the ask in the opening so both readers and summarizers can find it.

The curse of knowledge

Chip and Dan Heath popularized the curse of knowledge in HBR (2006) and Made to Stick (2007). Experts overestimate shared understanding. Elizabeth Newton’s 1990 Stanford tapping study illustrates it: tappers who knew a song overestimated listeners’ ability to recognize its rhythm.

Ask an outsider, or a harness simulating a named audience, to mark unexplained acronyms, project names and assumed context. Define or remove each unclear reference.

Structure: answer first

The Pyramid Principle

Barbara Minto’s Pyramid Principle places one governing thought above supporting points, with evidence beneath each. Give the reader the recommendation before developing its reasons.

Group support so readers can choose their depth. An executive may need the main point and reasons, while an engineering lead examines one branch’s evidence.

As commonly taught from Minto’s book, the pyramid has a few working rules:

• Ideas at any level summarize the ideas grouped below them. If a key point doesn’t follow from its support, either the point or the support is wrong.
• Ideas in each group are the same kind of idea. Three reasons, three steps or three options; never two reasons and a step.
• Ideas in each group are in a logical order: by importance, by time or by structure.
• The groups should be mutually exclusive and collectively exhaustive (MECE). No overlaps, and nothing important missing.

SCQA: the opening that earns the answer

Minto also gave writers a way to open: Situation, Complication, Question. Her own materials describe it as a framework for finding the question already in the reader’s mind. The usual business shorthand adds the Answer, giving SCQA.

• Situation: something the reader already knows and agrees with. It establishes common ground.
• Complication: what changed, broke or is threatening. This is the reason the document exists.
• Question: the question the complication raises in the reader’s mind. Often it stays implicit.
• Answer: your governing thought, the top of the pyramid.

Keep SCQA to a short paragraph: shared situation, specific complication and an answer matching the objective. Use it for genuine problems and choices. Routine updates rarely need a dramatic opening.

BLUF and writing for executives

BLUF, bottom line up front, places the request or conclusion before background. Army Regulation 25-50 is a common source for the military norm. Kabir Sehgal’s 2016 HBR adaptation also recommends action-oriented email subjects.

BLUF assumes the reader may read only the first two lines, so those lines must stand alone. Writing for executives adds three habits:

1. State the decision you need and the date in the first sentence. “I need your approval by Friday to…” respects a calendar full of other documents.
2. Give the recommendation, not just the options. Executives can overrule you. They can’t easily do your analysis for you. Show the options you rejected in one line each so they can see you considered them.
3. Make the cost of saying no visible. Every proposal has a “do nothing” option. Say what it costs and who pays.

Jakob Nielsen’s 1997 web-reading research found scanning more common than word-for-word reading. Todd Rogers and Jessica Lasky-Fink’s work on busy readers follows the same attention constraint. Use informative headings, opening claims and short paragraphs.

Amazon’s narrative culture

Amazon’s writing practices work through preparation, shared reading and revision. Length alone provides little of that value.

The six-page narrative

Bezos’s 2017 shareholder letter describes six-page narratives read silently at the start of meetings. He emphasizes repeated drafting, peer feedback, time away and fresh editing, suggesting that a strong memo can take a week or more.

The format works for three reasons:

• Prose exposes gaps. Bullet points let you place two ideas next to each other without saying how they connect. Narrative forces the connection.
• Silent reading puts everyone on the same page. The meeting starts from shared, complete context, so discussion goes straight to the hard parts rather than to the presenter’s delivery.
• The document outlives the meeting. It becomes the record of what was decided and why.

Amazon publishes no official six-page template. The outline in this chapter’s artifacts is this book’s recommended shape: context and the question, tenets or principles, the current state with data, the proposal, alternatives considered, risks and mitigations, the plan and the ask, with an appendix for detail.

The PR/FAQ and Working Backwards

Colin Bryar and Bill Carr describe the PR/FAQ as the core of Working Backwards. Before building, write a launch-day press release and FAQ to test the customer experience, value and delivery requirements.

According to the Working Backwards guidance, the press release has a standard shape:

• Heading: names the product in a way the target customer understands, in one sentence.
• Subheading: names the target customer and the benefit, in one sentence.
• Summary paragraph: the city, the outlet and the planned launch date, plus a summary of the product and its benefits.
• Problem paragraph: the customer’s problem, from the customer’s point of view.
• Solution paragraph(s): how the product solves it, how it differs from today’s alternatives and how to get started.
• Quotes and getting started: one quote from a company spokesperson, one from a hypothetical customer, how easy it is to start and where to go.

The external FAQ answers customer and press questions: pricing, operation, purchase and support. The internal FAQ examines demand, alternatives, market size, edge cases, delivery constraints, dependencies, regulation, economics, investment and the three largest failure risks.

Bryar and Carr limit the release to under a page and the FAQ to five. Reviews use silent reading, senior reviewers speaking last and line-by-line feedback. Working Backwards guidance suggests 15–20 minutes reading and about forty discussing. Draft quickly because repeated revision is expected.

For B2B PMs, the press release forces clarity about the customer and benefit, and the internal FAQ is where you confront the security review, the margin, the migration and the reasons it could fail.

What to borrow, and what not to

You don’t need Amazon’s culture to use its tools, but keep the parts that make them work:

The PM’s core documents

The one-page proposal

The one-page proposal supports one decision in a few minutes of reading. Use a compressed pyramid:

1. The ask (one or two sentences): the narrowed objective, the decider and the date.
2. Why now (SCQA in a short paragraph): situation, complication, the question.
3. The recommendation and three reasons, each with its strongest piece of evidence.
4. Options considered, including doing nothing, each with its cost.
5. Risks and what would change your mind.
6. Cost and next steps, with owners and dates.

State what evidence would change your mind so reviewers can evaluate both the recommendation and its limits.

The decision memo

A decision memo records a decision and why it was made. Two ideas from Bezos’s shareholder letters make it better.

Classify the choice using Bezos’s 2015 Type 1 (hard to reverse) and Type 2 (reversible) distinction. Match evidence and review effort to it. Split decisions where possible: existing-customer pricing may be difficult to reverse, while a new-customer pilot offers a reversible test.

Bezos’s 2016 letter recommends deciding with roughly 70% of desired information and using disagree and commit after the choice. Record dissent alongside rationale so people can commit without losing their concern. File memos in the decision log (Chapter 29).

Strategy documents

Strategy documents argue where to play and how to win. Open with the guiding policy, use the diagnosis as context and complication, and group coherent actions beneath it. State excluded work. Chapter 03 explains Rumelt’s kernel.

Adapting a proposal into an email

For email or chat, name the action and deadline in the subject. Open with the ask, then three short reasons, the cost of inaction, a document link and the follow-up plan.

Keep the email under about 150 words; if it needs more, its job is to get the reader to open the proposal. If you send several, tailor the first line: lead with risk for the security reviewer and with revenue for the sales leader.

Persuasion: principles and their evidence

Use persuasion principles as lenses whose effects depend on context. Preserve evidence and genuine deadlines. Manipulative framing damages credibility with future reviewers.

Cialdini’s principles

Robert Cialdini’s Influence: The Psychology of Persuasion is the most widely read book on the subject. His organization, Influence at Work, now lists seven principles:

Unity is the newest of the seven; Cialdini added it in a later edition of the book.

Treat persuasion findings cautiously. Goldstein, Cialdini and Griskevicius’s 2008 hotel-towel study found benefits from social-norm messages. Bohner and Schlüter’s 2014 PLOS ONE replication did not reproduce the effect. One failure does not overturn the wider evidence, but it supports context-specific testing. Clear asks and evidence remain essential.

Made to Stick

Chip and Dan Heath’s Made to Stick (2007) asks why some ideas survive and others are forgotten. They offer six principles, abbreviated as SUCCESs:

• Simple: find the core of the idea and strip it down to that.
• Unexpected: break a pattern the reader expects, to get attention.
• Concrete: use specific, sensory detail instead of abstraction.
• Credible: give the reader a way to believe it, including details they can check.
• Emotional: make the reader care about something specific.
• Stories: tell a story that shows the idea in action.

For PM writing, concrete and stories do the most work. “Diagnosis quality issues may impact customer trust” is abstract and forgettable. “A responder accepted our root cause, rolled back the checkout service, and took checkout down for eleven minutes during a sale” is concrete, credible and emotional at once, and the reader will repeat it in the next meeting. Lead with one real incident, then generalize with the data.

Simple is the narrowed objective again: finding the core means deciding what to leave out, which is hard because everything you leave out is true.

How to apply it

This method works for any significant persuasive document; the time on each step scales with the stakes.

Before you write

1. Narrow the objective to one sentence with an action, a decider, a deadline and a scope.
2. Classify the decision as a one-way or two-way door. That sets the document type and how much evidence you need.
3. Analyze the audience: the decider and everyone who can veto or will be asked for an opinion. Name the objection most likely to sink the proposal.
4. Gather the evidence with sources. Ask your AI harness to pull data and documents through connectors, and keep the source next to every number.

Think on paper

5. Build the pyramid by hand. Don’t delegate this step; if you can’t build the pyramid, you don’t have a recommendation yet.
6. Write the SCQA opening, with an undisputed situation and an answer that matches the objective.
7. Write the “what would change my mind” line and the rejected options, including doing nothing.

Draft and test

8. Draft against the template. AI can draft from your pyramid, evidence and template; you rewrite it in your voice and cut what you don’t believe.
9. Run reader tests. Have the harness read as each key reader and list their first questions and the least credible claim. Then ask one real person outside the work.
10. Verify every claim against its source yourself. Fix or cut anything you can’t trace.
11. Cut every sentence that doesn’t support the governing thought. For high stakes, set it aside a day and cut again.

Ship and follow through

12. Adapt for the channel with a BLUF email or message that links the full document.
13. Pre-wire the vetoes: share the draft with people who can block it before the meeting, and fold in their objections (Chapter 36).
14. Record the decision in a short decision memo with reasons and dissent.

The AI lens

Building AI-powered products

• State uncertainty in numbers. An AI feature’s quality varies by case and over time, so “the agent is highly accurate” invites misreading. “Responders accepted the diagnosis in 64% of pilot incidents” can be checked and argued with. Put the measure, the sample and the period in the sentence (Chapter 31 covers evals).
• Write the failure case into the proposal. Every AI proposal needs a paragraph on what happens when the model is wrong: how the user will notice, what the blast radius is and how it’s contained.
• Write PR/FAQs for agents with the gatekeeper in the room. For AI products in enterprise markets, the internal FAQ should answer the security and compliance reviewer’s questions (data access, audit logs, model training on customer data, regulatory documentation) as fully as the customer’s. Chapter 33 covers the regulatory content.
• Don’t let the press release overclaim autonomy. “Resolves incidents automatically,” for a product that needs human approval for most actions, will be quoted back to you by customers and regulators.

Writing with AI: draft, don’t think

Delegate drafting, critique and checking. Keep the thinking: the objective, the pyramid, the recommendation and the judgment about what to leave out.

Nataliya Kosmyna and colleagues’ 2025 MIT preprint, “Your Brain on ChatGPT,” compared AI-assisted, search-assisted and unaided essay writing. The AI group showed weaker brain connectivity, ownership and recall of its prose. Its small sample, single task and preprint status limit inference. Use it as a prompt to protect authorship, not proof of a general cognitive effect.

Anthropic’s four AI Fluency practices fit writing: Delegation assigns drafting and critique, Description supplies audience, evidence and examples, Discernment checks tradeoffs, and Diligence verifies claims, protects confidential material and discloses AI use.

Voice

Give the assistant a few representative writing samples and a short style guide. Rewrite the opening, recommendation and risks yourself, preserving the judgment and voice the reader needs.

Verification

KPMG and the University of Melbourne’s 2025 global study of trust in AI found that 66% of employees rely on AI output without evaluating its accuracy and 56% say they’ve made mistakes in their work because of AI. A persuasive document is the worst place for those mistakes, because a wrong number in a proposal costs you credibility on every future proposal.

Make verification a step with a visible output: have the harness list every factual claim with its source, then check each yourself. Cut anything without a source, or label it as your estimate.

Disclosure

Disclosure is unsettled. KPMG’s US findings from the same 2025 study reported that 53% of US workers avoid revealing when they use AI and present AI-generated content as their own. One reason is that visible AI use carries a cost: Jessica Reif, Richard Larrick and Jack Soll reported in PNAS in 2025, across four preregistered experiments with 4,439 participants, that people who use AI at work are rated as less competent and less motivated by others.

Disclosure norms vary. ICMJE bars AI authorship, requires disclosure and holds human authors accountable. This book recommends a brief equivalent for significant PM documents: what AI drafted, which sources it used and who checked them. Example: “Drafted with AI from incident and support records; numbers checked against source systems by [name].”

The Beacon case: winning the hold

Narrowing the objective. Your first draft says “improve agent quality before launch,” a topic. You narrow it: “Approve launching Beacon Agents at Northlight Live with supervised remediation only, holding the autonomous tier one quarter while the two applied AI engineers extend the eval suite to autonomous actions; decision by the VP of Product before the launch content lock.” It asks for reallocation, not new budget.

The audience worksheet. The VP of Product decides, cares about the launch and the 38% growth story, and fears looking cautious in front of the CEO. The product marketing manager can’t veto but can make the decision expensive; their fear is a keynote rewritten at the last minute. Sam, the security and compliance reviewer, would likely block autonomous write access without stronger audit evidence, and EU customers are asking for AI Act documentation. Marcus, the economic buyer, needs an ROI story for a CFO who has already asked who pays when the agent makes an incident worse. Priya, the champion, needs to trust the agent won’t make things worse. The worksheet shows that the decider’s real objection is the launch narrative.

The SCQA. Situation: Beacon Agents launches at Northlight Live, and diagnosis acceptance is the metric customers watch to decide whether to trust it. Complication: in the pilot, a confident wrong diagnosis led a customer to roll back the wrong service, and the autonomous tier would let that kind of action run without a human. Question: do we ship the autonomous tier on schedule? Answer: ship supervised remediation on schedule and hold the autonomous tier one quarter, until it clears an extended eval suite.

The pyramid. Three reasons, one kind (each is a risk the hold removes):

1. It protects trust with users. Priya and Dana’s willingness to accept diagnoses is the product’s leading indicator, and one autonomous mistake at launch would reset it.
2. It protects the buyer story. Marcus buys on MTTR and ROI; net revenue retention is 118%, and an agent-caused outage at a reference customer would put expansion at risk.
3. It clears the gatekeepers. Sam’s review and EU customers’ documentation requests are easier to satisfy for supervised actions, so the launch reaches more customers.

The “what would change my mind” line: if the eval suite shows the autonomous actions meeting the regression bar on every release for six weeks before the content lock, ship the autonomous tier as planned.

Persuasion, honestly. You lead with the eleven-minute checkout outage rather than a paragraph about “quality risk.” You tie the ask to the North Star the VP already set (incidents resolved with Beacon’s help per week), quote Priya from the post-incident review with her permission and use the real content lock as the only deadline.

Doing it with AI. Through connectors, the harness pulls the post-incident review and every support ticket mentioning the rollback. You give it your pyramid, the audience worksheet and the one-page template, then rewrite the ask, recommendation and risks yourself. Reader tests as the VP and as Sam surface the question you’d missed: what does the keynote say instead? You add a paragraph offering product marketing a different story (“the agent that tells you when it’s not sure”), drawn from the eval work.

The claims check lists every number with its source, and one fails: the draft says gross margin “fell from 81% to about 70%,” while the finance report says 72%. The model had drifted toward a figure from another document’s cost discussion. You fix it and add the disclosure line at the bottom: “Drafted with Claude from the incident review and support data; numbers checked against source systems by [your name].”

The email. The VP will decide between meetings, so you adapt the one-pager into an email:

Subject: Decision needed before content lock: hold Beacon Agents autonomous tier one quarter

I recommend we launch Beacon Agents at Northlight Live with supervised remediation and hold the autonomous tier one quarter. I need your decision before the content lock.

• Trust: one autonomous mistake at launch would reset responders’ trust in diagnosis.
• Revenue: our buyers renew on MTTR; an agent-caused outage at a reference account puts expansion at risk.
• Reach: supervised actions clear security reviews and EU documentation requests faster.

If no, we ship as planned and I’ll add a launch-week rollback plan. The one-pager (with what would change my mind) is linked. I’ll walk product marketing through a revised keynote story either way.

The outcome. The VP approves, on condition of a written go or no-go on the autonomous tier at the next quarterly business review, judged against the eval bar in the one-pager. Your decision memo records the product marketing manager’s dissent (“a weaker keynote”) and their commitment. The keynote leads with diagnosis that shows its evidence.

Product 360 artifacts

# Audience analysis · [Document or proposal] · [Date]

**Narrowed objective (one sentence):** [Action] by [decider] by [date], scope: [included / excluded]
**Decision type:** One-way door / Two-way door / Split (explain)
**Document type:** Email / One-page proposal / Decision memo / Six-page narrative / PR/FAQ

## Readers
| Reader | Role in decision (decide / veto / advise / execute / informed) | What they know | What they believe now | What they care about and are measured on | What they fear | How they will read it | Lead appeal (ethos / pathos / logos) |
|---|---|---|---|---|---|---|---|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |

## The objection most likely to sink this
[Who holds it, in their words, and how the document answers it]

## Curse-of-knowledge check
Terms, acronyms and references a reader outside the work won't know:
- [Term]: define / remove

## Pre-wiring plan
| Reader | Share draft by | Channel | Their feedback | How the document changed |
|---|---|---|---|---|
| | | | | |

# [Title that states the recommendation, e.g. "Hold the autonomous tier one quarter"]

**Decision needed from:** [Name]   **By:** [Date and why that date]   **Author:** [PM]   **Decision type:** One-way / Two-way door

## The ask
[One or two sentences the decider could approve by replying "yes."]

## Why now
[Situation: what the reader already accepts.] [Complication: what changed, with a number.] [Question: what this raises.] [Answer: the ask, restated.]

## Recommendation and reasons
1. **[Reason 1]**: [strongest evidence, with source]
2. **[Reason 2]**: [strongest evidence, with source]
3. **[Reason 3]**: [strongest evidence, with source]

## Options considered
| Option | What it costs | Why not |
|---|---|---|
| Do nothing | | |
| [Option B] | | |
| **Recommended** | | |

## Risks and what would change my mind
- Risk: [risk] · Mitigation: [mitigation]
- I would change my recommendation if [specific, observable condition].

## Cost and next steps
| Step | Owner | Date |
|---|---|---|
| | | |

---
*How this was made: [e.g. "Drafted with an AI assistant from (sources); every number checked against source systems by (name)."]*

# PR/FAQ · [Product or feature] · Draft v[n] · [Date]

**Author:** [PM]   **Reviewers:** [names]   **Status:** Draft / In review / Approved / Shelved

## Press release (under one page)

### [Heading: the product named so the target customer understands it, one sentence]
#### [Subheading: who the customer is and the benefit they get, one sentence]

**[City] · [Outlet] · [Planned launch date]**: [Summary paragraph: what the product is and its main benefit.]

**The problem.** [The customer's problem, from the customer's point of view, in their words.]

**The solution.** [How the product solves it, how it differs from today's alternatives (including doing nothing), and how to get started.]

"[Quote from a company spokesperson: why we built it.]" said [name, title].

"[Quote from a hypothetical customer: the outcome in their words.]" said [persona, role, company type].

**Getting started.** [How easy it is to start, and where to go.]

## External FAQ (customers and press)
1. How much does it cost?
2. How does it work?
3. How do I get help?
4. Where and how do I buy it?
5. [What does it access, and how is my data handled?]

## Internal FAQ (stakeholders; five pages or fewer for the whole FAQ)
1. Who has this problem, how many of them are there and how many will pay?
2. How does this beat the alternatives on quality, cost or speed? Who are the competitors?
3. How big is the market we can actually serve?
4. What edge cases matter, and how do we handle them?
5. What are the hardest technical, operational, legal and design problems? What new capabilities do we need?
6. What do we depend on (partners, platforms, other teams)?
7. What regulatory or compliance questions apply?
8. What are the unit economics, the upfront investment and the time to payback?
9. For AI products: what is the autonomy level, how do users notice when it's wrong and what is the blast radius?
10. What must be true for this to succeed, and what are the top three reasons it could fail?

# [Title stating the proposal] · Narrative · [Date]

**Author:** [PM]   **Meeting:** [date]; silent reading in the first minutes   **Decision needed:** [one sentence]

This outline is a recommended shape, not an official format. Write in full paragraphs; tables and charts are fine where they carry data. Six pages is a ceiling.

## 1. Context and question (half a page)
The situation, the complication and the question this document answers. End with the answer in one sentence.

## 2. Tenets (a few lines)
The principles we're using to decide, stated so a reader can disagree with them.

## 3. Where we are today (one page)
The current state, with data and sources. What customers say, in their words. What we've tried.

## 4. The proposal (one and a half pages)
What we'll do, for whom and why. How it serves the tenets. What success looks like, in metrics.

## 5. Alternatives considered (half a page)
Each serious alternative, including doing nothing, and why we didn't choose it.

## 6. Risks and mitigations (half a page)
What could go wrong, how we'd know early and what we'd do. What would change our mind.

## 7. Plan and ask (half a page)
Milestones, owners, cost and the specific decisions needed from this meeting.

## 8. Open questions
What we don't know yet, and how we'll find out.

## Appendix (not counted in the six pages)
Supporting data, detailed models, customer evidence, glossary.

---
*How this was made: [AI use and verification line]*

# Decision: [the decision, stated as a sentence] · [Date]

**Decider:** [Name]   **Author:** [PM]   **Status:** Proposed / Decided / Revisited
**Decision type:** One-way door / Two-way door / Split: [which part is which]
**Information confidence:** [roughly how much of what we'd want to know we have, and what's missing]

## Context
[Two or three sentences: the situation and complication.]

## Options
| Option | Benefits | Costs and risks | Reversible? |
|---|---|---|---|
| | | | |

## Decision
[What was decided, by whom, and the main reasons.]

## Dissent and commitment
| Person | Concern | Committed? |
|---|---|---|
| | | Yes / No |

## Conditions and review
- We will revisit if: [observable trigger]
- Review date: [date]   Forum: [governance forum or business review]

## Consequences
[What changes now: roadmap, owners, messages to customers or teams.]

Subject: [Decision needed / FYI / Approval needed] by [date]: [the ask in under ten words]

[Name],

[The ask in one sentence that can be answered with one word.] [The date and why.]

- [Reason 1, one line]
- [Reason 2, one line]
- [Reason 3, one line]

[Cost of saying no, one sentence.] [What you'll do if you hear nothing, and when.]

Full proposal: [link]

[Your name]

---
Checks before sending:
- Under about 150 words.
- The first line works alone in a preview pane or an AI summary.
- First line tailored to this reader's main concern.
- Every number checked against its source.

Prompts

Goal: Turn a topic into a decision a reader can approve.
Paste in: your current draft ask or the problem in a few sentences, who you think decides and any deadline you know about.

I'm a product manager writing a proposal. Here is what I want to achieve: [draft ask or problem].

1. Rewrite it as one sentence with four parts: the action (a verb), the one person who decides, the deadline and the scope (what's included and excluded).
2. If my draft actually contains more than one ask, list them separately and tell me which should come first and why.
3. Give me three alternative versions, from the most ambitious to the most conservative, and the likely objection to each.
4. Tell me what information you'd need to make the ask sharper. List missing information as questions for me to answer.

Check the output: imagine the decider replies with one word. If neither "yes" nor "no" would tell you what to do next, narrow it again. Make sure the decider named is a real person with the authority, not a committee.

Goal: Know who has to agree and what each of them fears before you draft.
Paste in: the narrowed ask, the list of readers with their roles, and anything you know about their goals and past positions (meeting notes, prior emails, strategy documents). Use an approved tool for internal documents.

For this proposal: [ask], complete an audience analysis for these readers: [readers and roles].

For each reader give: their role in the decision (decide, veto, advise, execute or informed), what they likely know, what they likely believe now, what they're measured on, what they're probably afraid of, how they'll read the document, and which appeal (credibility, emotion or logic) will matter most to them.

Then name the single objection most likely to sink the proposal, who holds it and how the document should answer it.

Rules: base every claim about a reader on the material I gave you, and cite it. Where you're guessing, label it "guess."

Check the output: the "guess" labels are where you need a conversation, not a better prompt. Confirm the biggest objection with at least one real person before drafting.

Goal: Get a first draft fast without handing over the thinking.
Paste in: your pyramid (governing thought, three key points, evidence with sources under each), the template for the document type, the audience analysis and two or three samples of your own writing.

Draft a [one-page proposal / decision memo / six-page narrative] using this template: [template].

The argument is fixed. Use my governing thought and key points exactly; don't add, merge or reorder them. Use only the evidence I've provided, and keep the source next to every number. Open with a Situation, Complication, Question, Answer paragraph. Put the ask in the first two sentences.

Match the voice of my writing samples: sentence length, directness, how I state recommendations. Avoid generic phrases, filler transitions and summary endings. Write "[NEEDS EVIDENCE]" wherever the template asks for something I haven't given you.

[pyramid]
[audience analysis]
[writing samples]

Check the output: rewrite the ask, the recommendation and the risks section yourself. Search for "[NEEDS EVIDENCE]" and either supply the evidence or cut the claim. Delete any sentence you wouldn't say aloud in the meeting.

Goal: Find the questions and weak claims before the real reader does.
Paste in: the draft and a short description of the reader (role, goals, what they fear, how much time they have).

Act as [reader description], who has [two minutes] to read this and will decide [the ask].

1. In one sentence, what do you think I'm asking for? If it's unclear, say so.
2. List the first three questions you'd ask.
3. Identify the one claim you find least credible and explain why.
4. Name the option or risk you think I've ignored.
5. Tell me whether you would say yes, no or "not yet," and what would change your answer.

Be direct. Don't soften the critique, and don't invent facts about the company that aren't in the draft.

[draft]

Check the output: if the simulated reader misstates the ask, fix the first two sentences before anything else. Treat the simulation as a rehearsal; then ask one real person to do the same test.

Goal: Make sure no unverified number, name or quote leaves your desk.
Paste in: the final draft and the source documents or data the claims came from, or connect the harness to them. Use an approved tool for confidential data.

List every factual claim in this draft: each number, percentage, date, name, quote, product capability and comparison. For each, give:
- the exact sentence it appears in,
- the source document and location it came from,
- whether the source supports it exactly, roughly (for example rounded or paraphrased), or not at all.

Flag any claim with no source as "UNSOURCED." Flag any rounding or paraphrase that changes the meaning. Don't correct the draft; just report.

[draft]
[sources]

Check the output: open the source yourself for every number in the first paragraph and every number in the recommendation. Fix or cut every UNSOURCED claim, or label it as your estimate.

Goal: Carry the ask into the channel where the decision will actually be made.
Paste in: the one-page proposal and the name, role and main concern of the email's reader.

Turn this proposal into an email to [reader], whose main concern is [concern].

- Subject line: the kind of request (decision, approval or information), the date and the ask in under ten words.
- First line: the ask, in one sentence that can be answered with one word, plus the date.
- Then three one-line reasons, with the one closest to [concern] first.
- Then one sentence on the cost of saying no and one on what I'll do if I hear nothing.
- End with the link placeholder to the full proposal.

Keep it under 150 words. Don't add claims that aren't in the proposal.

[proposal]

Check the output: read only the subject and first line, as if in a preview pane. Could the reader decide from those? Confirm every reason appears, with evidence, in the proposal.

Goal: Test whether the customer benefit is clear before anyone builds.
Paste in: the product hypothesis, the target persona and their job story, known alternatives, any pricing and cost assumptions and what you know about risks.

Write a PR/FAQ for [product] with:
1. A press release under one page: heading (one sentence naming the product for the customer), subheading (customer and benefit, one sentence), summary paragraph with [city], [outlet] and [launch date], problem paragraph in the customer's words, solution paragraph (including how it differs from today's alternatives), a spokesperson quote, a hypothetical customer quote and how to get started.
2. An external FAQ: price, how it works, support, how to buy and how data is handled.
3. An internal FAQ: who has the problem and how many will pay, competitive advantage, serviceable market, edge cases, hardest problems, dependencies, regulation, unit economics, and the top three reasons it could fail.

Use only the facts I've provided. Mark customer quotes as hypothetical. Where I haven't given you a fact the FAQ needs, write the question and "[OPEN]" instead of an answer.

Check the output: if the press release would bore the target customer, the product isn't clear yet. Count the "[OPEN]" items; they're your research plan. Make sure the press release doesn't claim more autonomy or capability than the product will have at launch.

Anti-patterns

Checklist

• The ask is one sentence with an action, a decider, a deadline and a scope, and it appears in the first two sentences.
• The decision is classified as a one-way or two-way door, and the document type and length match it.
• An audience analysis covers the decider and everyone who can veto, and names the objection most likely to sink the proposal.
• The pyramid was built by the author: one governing thought, about three key points of the same kind, evidence under each.
• The opening uses SCQA where there’s a real decision, with an undisputed situation and a specific complication.
• Options include doing nothing, with its cost, and the document says what would change the author’s mind.
• Persuasion principles are used honestly: real deadlines, named sources, representative evidence.
• Every number, name, date and quote has been traced to its source by the author.
• The ask, recommendation and risks are in the author’s own voice.
• Confidential data went only into approved AI tools, and a disclosure line states how AI was used and what was checked.
• A BLUF email or message carries the ask to the channel where the decision will be made.
• People who can veto saw the draft before the decision meeting.
• The decision, reasons and dissent are recorded in a decision memo.