Writing an Internal Press Release for a Product Idea

How to write an internal press release: the one-page working backwards press release that opens a PR/FAQ document before anything is built.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

An internal press release is a one-page announcement of a product that does not exist yet, written as if it launched today. It is the first half of the PR/FAQ document in Amazon's Working Backwards method, and the rest of the process depends on it. The FAQ answers questions the press release raises, the review meeting critiques it, and the go or no-go decision is made on it. Nobody outside the company reads it. The imagined reader is the customer the product is for.

Colin Bryar and Bill Carr, the former Amazon executives who wrote the book on the process, set the length: the press release is "a few paragraphs, always less than one page" (Amazon's excerpt from Working Backwards). The limit is deliberate. A page leaves room for the customer, the problem, the solution and the reason to care, and nothing else. It also forces the author to decide which of the product's many possible benefits is the one that matters.

Writing the working backwards press release first changes what the author thinks about. A normal launch announcement is written at the end, when the product is fixed. Written at the start, it pulls attention away from current capabilities, competitors and the P&L and onto a single question: would the customer who reads this want the product? Bryar and Carr call the press release "a forcing function to ensure that the creator of the new product idea is focused on the customer" (PR/FAQ instructions).

This skill is useful for any customer-centric product development work where the team needs to agree on a direction before investing. The draft is cheap. The authors say a first draft should take only a few hours, so it is realistic to write press releases for several competing ideas and compare them. A weak press release is useful too: if the author cannot make the customer benefit compelling on one page, that is early evidence the idea needs work.

The output of this skill is one page. The FAQ that follows it is covered in Drafting the FAQ Section of a PR/FAQ.

How It Works

The press release follows a fixed structure. The template Bryar and Carr publish lists the parts in order (PR/FAQ instructions):

• Heading: the product's name, phrased so the target customer would understand it.
• Subheading: one sentence naming the customer and the benefit they get.
• Summary paragraph: opens with the city, the media outlet and a proposed launch date, then summarizes the product and its benefits.
• Problem paragraph: the problem the product solves, written from the customer's point of view.
• Solution paragraph or paragraphs: how the product solves that problem, and how it differs from what customers use today.
• Quotes and getting started: one quote from a company spokesperson, one from a hypothetical customer, and a short note on how to get started.

Two parts carry most of the weight. The subheading forces a choice of customer, and the template is direct about it: "If you think your product is for everyone, you are mistaken." The solution paragraph forces a comparison. The template suggests a sentence of the form "Today, customers with this problem use x, y, or z products to meet their needs," followed by where those products fall short and how the new product addresses the gap. If the new product solves the same problem in roughly the same way, the authors say to go back to the drawing board.

The launch date should mean something. The template asks for the date you actually expect to launch, rough in early drafts and firm by the last one. A date that is obviously invented tells reviewers the author has not thought about delivery.

The quotes do different jobs. The spokesperson quote says why the company built the product. The customer quote says what changed in the customer's life, in words a real customer might use. Both are hypothetical, and a reader should be able to tell that. Their value is that writing them exposes whether the author can imagine a customer caring.

Reviewers then test the draft. At Amazon, a common executive question when reviewing the features in a press release is "so what?", and if the product is not meaningfully better (faster, easier, cheaper) than what is already out there, the authors say it isn't worth building (book excerpt). ProductPlan's summary of the method cites former Amazon director Ian McAllister on spending a lot of time revising and cutting the release, and adds that a draft the team finds uninspiring is a good indicator the idea lacks something.

Step-by-Step Guide

Step 1: Name the customer

Write one sentence describing the customer segment: who they are, what situation they are in, and what they are trying to get done. Make it narrow enough that a colleague could decide whether a given person belongs to it. Pull the details from evidence you have, such as support tickets, sales calls, reviews or interviews. If you find yourself writing "businesses" or "users" with no qualifier, stop and pick the segment whose problem is sharpest.

Step 2: Write the heading and subheading

Name the product in words the customer would understand, and keep internal code names out of it. Then write a one-sentence subheading that names the customer and the benefit they get. The subheading is the hardest sentence in the document, because it commits you to one customer and one main benefit. Write several versions and keep the one a customer would most want to read on.

Step 3: Write the summary paragraph

Open with a city, a media outlet and the date you expect to launch. Summarize what the product is and what it does for the customer in two or three sentences. Resist listing features. A reader who stops after this paragraph should still know who the product is for and why they would want it.

Step 4: Write the problem paragraph

Describe the problem the way the customer experiences it today: what they do now, what it costs them, and what goes wrong. Write from their point of view, in their language. If several problems compete, pick the one that matters most to the customer. The template also asks you to consider whether enough customers have the problem and would pay to solve it, since a problem that fails either test is not worth solving (PR/FAQ instructions).

Step 5: Write the solution paragraph

Explain how the product solves the problem you just described, directly and simply. Name what customers use today and why it falls short, then say how the new product is better. Keep the solution focused on the stated problem and leave out features that address other needs. For a complex product you may need a second paragraph, but check each sentence against the problem paragraph.

Step 6: Add the quotes and the getting-started paragraph

Write a spokesperson quote that explains why the company built the product. Write a customer quote that describes the change in the customer's day in plain words. Close with how a customer gets started and where they would go to learn more. Keep getting started short; if it needs a long explanation, the experience is probably too complicated.

Step 7: Cut and test the draft

Cut every sentence that does not help the customer decide. Replace jargon and internal terms with plain words. Then test the draft: ask "so what?" of every claimed benefit, and cover the product and company names to see whether the customer and the benefit are still clear. Read it aloud to someone outside the team and ask what they think the product does.

Step 8: Hand the internal press release on to the FAQ

Share the draft with your manager and one or two peers, then start the FAQ with the questions they raise. Keep a list of the assumptions the press release makes, since each one will need an answer in the internal FAQ. Expect the press release to change after review; the process in Iterating PR/FAQ Documents Through Feedback assumes several drafts.

Best Practices

• Write the problem paragraph before the solution. When the problem is vague, the solution grows to fill the space with features.
• Keep one main benefit. A press release that claims five benefits usually has not decided which customer it serves.
• Use numbers only when you can defend them. A concrete claim about time or money saved is stronger than an adjective, but reviewers will ask where it came from, so note the source in the FAQ.
• Write the competitive sentence honestly. Naming what customers use today, including spreadsheets or doing nothing, makes the improvement easier to judge.
• Write press releases for competing ideas in the same format. Comparing several one-page drafts side by side is cheaper and clearer than debating the ideas in a meeting.
• Keep the launch date realistic. Update it with each draft so the final version carries the date the team would commit to.

Common Mistakes

• Starting from the technology: A press release that opens with the architecture or the model is written for the team. Rewrite it so the first two paragraphs say nothing about how the product is built.
• Describing everyone as the customer: A broad customer makes every later sentence vague. Pick the segment with the sharpest problem and write for them; other segments can get their own press release later.
• Listing features instead of an experience: A list of capabilities does not tell the reader what changes for them. Describe what the customer can now do that they could not do before.
• Writing it after the decision is made: A press release written to justify a project already approved will never kill a bad idea. Write it while the decision is still open.
• Treating the first draft as final: The first draft is where the thinking starts. Plan for review and revision before anyone treats the press release as the plan.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Working Backwards

Related Skills

• Drafting the FAQ Section of a PR/FAQ
• Defining the Customer Experience Before Building
• Identifying Minimum Lovable Requirements
• Running PR/FAQ Review Meetings
• Iterating PR/FAQ Documents Through Feedback
• Using Working Backwards in PM Interviews

Sources

• Working Backwards LLC: PR/FAQ Instructions and Template
• About Amazon: excerpt from Working Backwards
• ProductPlan: Working Backwards (the Amazon Method)

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.