Writing Internal Press Releases for Product Concepts
This skill teaches you how to draft a concise, customer-centric internal press release that forces clarity about who the customer is, what problem they face, and why your proposed solution matters, all before any code is written or design work begins.
Start by writing a headline that captures the customer benefit, then draft a short opening paragraph naming the target customer, their problem, and your solution. Add three to four paragraphs covering how the product works, a customer quote illustrating the emotional payoff, and a clear call to action. Revise until a reader unfamiliar with the project can understand the entire value proposition without asking clarifying questions.
Outcome: You produce a one-page internal press release that any person in your organization can read and immediately understand the target customer, the problem being solved, and the solution's key benefits, enabling aligned decision-making before committing engineering resources.
Prerequisites
- A clearly identified customer segment you intend to serve
- A hypothesis about the specific problem or unmet need for that customer
- Basic familiarity with the Working Backwards framework and the role of the PR/FAQ document
- Access to at least one stakeholder or peer who can review drafts critically
Overview
An internal press release is a one-page document written as if your product has already launched and a journalist is announcing it to the world. It is the centerpiece of the Working Backwards method. Unlike a product requirements document or a pitch deck, the press release is written from the customer's perspective. It names who the customer is, describes the problem they struggle with today, and explains how the product solves that problem in plain, jargon-free language. The format forces you to articulate the end state of value delivery before anyone discusses technical architecture, sprint plans, or resource allocation.
The specific artifact you produce is a document between 500 and 1,000 words, structured with a headline, a subheadline, a dateline paragraph, three to four body paragraphs, and a fictional customer quote. This document becomes the anchor for all downstream decisions. When a design question arises, the team checks the press release. When scope creep threatens, the team re-reads the press release. When leadership asks what the project is about, you hand them the press release. It is not a throwaway exercise. Teams that practice this skill rigorously report that the press release saves weeks of misaligned effort because disagreements about vision surface on paper instead of in code reviews.
Writing an effective press release is harder than it looks. The constraint of plain language eliminates the hiding spots that technical jargon provides. You cannot write "leveraging cutting-edge AI" and call it a benefit. You must instead say something like "customers get personalized recommendations in under two seconds without leaving the checkout page." This precision is exactly the point. If you cannot articulate the benefit in a sentence a customer would actually care about, you do not yet understand the product well enough to build it. The press release is a test of understanding disguised as a writing exercise, and among the most underrated product manager skills in modern practice.
Success looks like this: a colleague in a completely different department reads your press release cold and can answer three questions correctly: Who is this for? What problem does it solve? Why would someone care? If they can, the document is working. If they cannot, you iterate.
How It Works
The internal press release works because it exploits a specific cognitive trick: writing in the format of a finished announcement forces you to commit to concrete claims about value. When you write "Company X today announced Product Y, which helps [customer] do [thing] 50% faster," you have made a testable statement. That statement can be debated, verified, and refined. Compare this to a typical product brief that says "We will build a tool that improves efficiency." The brief is unfalsifiable. The press release is not.
The structure of the document maps directly to the decisions a product team must make. The headline answers "What is the single most important benefit?" The subheadline answers "Who is this for and why should they care?" The opening paragraph answers "What exactly does this product do?" The body paragraphs answer "How does it work from the customer's perspective?" The customer quote answers "What does the emotional payoff feel like?" The closing paragraph answers "How does someone get started?" By filling in each section, you are sequentially resolving the questions that, left unanswered, cause teams to build the wrong thing.
The press release also functions as an alignment test. When you share the draft with stakeholders, disagreements become visible immediately. One executive may read the headline and say, "That is not the most important benefit." Another may read the customer quote and say, "Our actual customers would never describe their problem that way." These objections are enormously valuable. They surface misalignment that would otherwise remain hidden until much later in the development cycle, when changing direction is expensive.
Within the Working Backwards framework, the press release is the first half of the PR/FAQ document. The second half, the FAQ section, addresses the hard questions the press release deliberately avoids. The press release paints the aspirational picture. The FAQ pressure-tests it. Together, they form a complete proposal that can be evaluated by leadership without requiring a prototype.
One important nuance: the press release is not a marketing document. It will never be published externally. Its audience is internal decision-makers. This means you do not need to worry about brand voice, legal compliance, or competitive positioning. You need to worry about clarity. The best internal press releases read like explanations to a smart friend who knows nothing about your industry. They avoid acronyms, skip buzzwords, and use specific numbers wherever possible. The constraint of writing for an uninformed reader is what makes the exercise so effective at exposing fuzzy thinking.
Step-by-Step
Step 1: Define the target customer in one sentence
Before you write a single word of the press release, write down a one-sentence description of the specific customer you are building for. This is not a market segment or a demographic bucket. It is a description of a real type of person with a real daily context. " The description should include who they are, what context they operate in, and a hint at the friction they experience.
Write this on a separate sheet of paper or at the top of your document as a reference line. Every sentence you write afterward must serve this person. If a sentence would not matter to this customer, cut it.
Tip: Test your customer description by asking: could I find five real people who match this description and interview them this week? If the description is too vague to identify real individuals, it is too vague to write a press release for.
Step 2: Write the headline as a customer benefit
The headline is the single most important sentence in the document. It should communicate the primary benefit to the customer in plain language, not announce a feature or use your company's internal terminology. A useful formula is: [Company Name] Launches [Product Name], Helping [Customer] [Achieve Specific Outcome]. " The headline must pass the "so what" test.
" and have a point, the headline is not specific enough. Write five to ten headline variations before selecting one. Place the customer and their benefit as close to the front of the headline as possible. Avoid superlatives like "revolutionary" or "groundbreaking" because they communicate nothing concrete.
Tip: Read each headline candidate aloud. If it sounds like something a real newspaper would run, it is probably specific enough. If it sounds like a tagline on a billboard, it is probably too abstract.
Step 3: Write the subheadline to expand context
The subheadline is one to two sentences that add the context the headline could not fit. If the headline names the benefit, the subheadline explains who specifically gets it and under what circumstances. " The subheadline should introduce the mechanism of the product in enough detail that the reader understands roughly how the benefit is delivered. It should not introduce a second benefit.
Stay focused on the single value proposition from the headline and make it more concrete.
Tip: The subheadline is the sentence most likely to get quoted by a stakeholder summarizing the project. Optimize it for that use case. Would someone in an executive meeting read this sentence aloud and have it make complete sense without additional context?
Step 4: Draft the opening paragraph with the dateline structure
, "Seattle, WA, January 15, 2025"), then states the announcement in one sentence, followed by two to three sentences that provide essential context. The first sentence should essentially restate the headline in slightly different words. The next sentences should name the problem being solved, quantify it if possible, and briefly state why existing solutions fall short. 2 hours per week compiling data from multiple analytics platforms into a single report.
" This paragraph sets up the stakes.
Tip: Use a real or realistic date that is 6-12 months in the future. This creates a concrete mental model of the launch timeline and helps the team calibrate scope.
Step 5: Write two to three body paragraphs explaining how it works
These paragraphs describe the product experience from the customer's perspective, not the engineering architecture. Walk through what the customer does: they sign up, connect their tools, click a button, and receive a report. Be specific about the sequence of actions and the results of each action. The first body paragraph should cover the core workflow.
The second paragraph should describe one secondary benefit or feature that reinforces the primary value proposition. If there is a third paragraph, use it to address scale, reliability, or a differentiator that matters to the customer. Avoid listing features. Instead, describe outcomes.
" Every sentence should make the customer's life feel easier, faster, or less frustrating.
Tip: After drafting, highlight every sentence that describes a feature rather than an outcome. Rewrite each one as an outcome. If you cannot rewrite it as an outcome, the feature may not matter to the customer, and you should consider cutting it.
Step 6: Write a fictional customer quote
The customer quote is a paragraph attributed to a named, fictional customer that captures the emotional response to the product. It should sound like something a real person would say in a testimonial, not like marketing copy. A good quote names the old way of doing things, describes the frustration, and then describes the relief or delight of the new way. For example: "'I used to spend every Monday morning pulling numbers from six different dashboards and pasting them into a slide deck,' said Maria Chen, VP of Marketing at CloudScale.
'Now I open ReportBot on Monday morning and the deck is already there, with insights I would have missed doing it manually. '" The quote serves two purposes. First, it tests whether you understand the emotional journey of your customer deeply enough to voice it. Second, it gives leadership a concrete image of the customer's experience that abstract benefit statements cannot achieve.
Tip: Write the quote first in your own voice as a straightforward benefit statement, then rewrite it as dialogue from the customer's mouth. If the customer would never actually say the words you wrote, the benefit is probably not real or not expressed correctly.
Step 7: Write a closing paragraph with a call to action
The final paragraph tells the reader what happens next. " In the internal version, this paragraph describes the intended path from awareness to usage. It should answer: How does a customer discover this product? What is the first action they take?
What does the free or trial experience look like? This paragraph forces you to think about the go-to-market motion early. If you cannot describe a simple path from discovery to value, the product concept may have a distribution problem that is worth addressing now. Keep this paragraph to three to four sentences.
Tip: The call to action is the paragraph most teams skip or write lazily. Resist this impulse. The path to first value is one of the hardest product decisions, and thinking about it at the press release stage saves significant rework later.
Step 8: Review for jargon, vagueness, and missing specifics
Read the entire document from top to bottom as if you are encountering the product for the first time. Circle every word or phrase that a customer would not use in their own vocabulary. Replace or remove each one. " If you do not have the specific number, write a placeholder like "[X]% faster" and flag it for research.
Vague claims are a signal that the thinking is not yet complete. Finally, confirm that the document answers five questions clearly: Who is the customer? What is their problem? What is the solution?
How does it work? Why is it better than the status quo?
Tip: Hand the press release to someone outside your team and ask them to summarize it back to you in two sentences. If their summary does not match your intent, the document has a clarity problem. Their paraphrase reveals what the document actually communicates versus what you meant.
Step 9: Circulate for feedback and prepare to iterate
Share the press release with three to five stakeholders who represent different perspectives: a potential customer (or a proxy like a customer success team member), a technical lead, a business stakeholder, and at least one person completely unfamiliar with the project. Ask each reader three specific questions: What do you think this product does? Who do you think it is for? What is the one thing that is unclear or that you do not believe?
Collect responses in writing before holding a group discussion. Written feedback prevents anchoring. Expect that the first draft will require substantial revision. Most press releases go through four to seven drafts before they reach a state where every reader answers the three questions consistently.
This iteration process is the subject of the iterating PR/FAQ documents skill.
Tip: Track which section of the press release generates the most disagreement across reviewers. That section almost always points to an unresolved strategic question about the product, not a writing problem. Address the strategic question first, then rewrite the section.
Examples
Example: B2B SaaS tool for a small product team
A four-person product team at a startup is considering building an automated user research synthesis tool. They have conducted customer interviews and know their target customer is a solo product manager at a Series A B2B SaaS company who conducts 5-10 user interviews per month but has no dedicated UX researcher. The PM currently spends 4-6 hours per batch manually reviewing transcripts and extracting themes.
" The opening paragraph quantifies the problem: PMs at early-stage companies conduct research but lack the time to synthesize it rigorously, leading to decisions based on the last two interviews rather than the full set. The body paragraphs walk through the user uploading a Zoom recording, receiving a tagged transcript within 10 minutes, and seeing a theme dashboard that highlights frequency and sentiment. The customer quote comes from "Priya Sharma, PM at CloudHR": "I used to feel guilty about how little of my interview data I actually used. " The closing paragraph describes a free tier with five interviews per month.
The first draft takes 90 minutes. After two rounds of feedback from a customer success teammate and the CTO, the team tightens the headline and removes a paragraph about competitive positioning that belonged in the FAQ.
Example: Enterprise platform feature for a large organization
A product team at a 2,000-person enterprise software company is proposing a new compliance automation module for their existing platform. The target customer is the VP of Compliance at a financial services firm with 500+ employees, who currently manages SOX compliance through a patchwork of spreadsheets and quarterly audit cycles. The team has six stakeholders who need to approve the concept, and the press release will be presented at a quarterly product review.
The team designates one PM as the primary author. " She deliberately avoids the phrase "end-to-end compliance management" because it is vague and overused. The subheadline names the three specific actions the module automates: evidence collection, control testing, and audit trail generation. Body paragraphs describe a compliance officer logging in, seeing a dashboard of control statuses updated in real time, clicking into a control to see automatically collected evidence linked to the relevant policy, and generating an audit-ready package with one click.
The customer quote comes from "James Park, VP of Compliance at Meridian Financial": "My team used to spend the last three weeks of every quarter in a panic, chasing down evidence and reconciling spreadsheets. " The team circulates the draft to all six stakeholders individually, collecting written feedback before the group review. Two stakeholders disagree about whether the headline should emphasize speed (three days) or risk reduction. This disagreement surfaces a strategic question about the module's positioning, which the team resolves in a 30-minute discussion.
The press release goes through five drafts over two weeks before the quarterly review.
Example: Consumer mobile app for a two-person founding team
Two co-founders are exploring a mobile app that helps parents of children aged 5-10 find age-appropriate local activities on weekends. They have interviewed 15 parents in their city and discovered that the core frustration is not a lack of activities but the effort required to discover, evaluate, and coordinate them across scattered sources like Facebook groups, Eventbrite, library websites, and word of mouth.
" The opening paragraph paints the problem: parents want enriching weekend experiences but the discovery process is fragmented and time-consuming, so many families default to the same three activities on repeat. The body paragraphs describe a parent opening the app on Thursday, seeing three recommended activities for Saturday with time, location, cost, and a one-sentence description tailored to their child's interests, and tapping to add them to a shared family calendar. The customer quote comes from "Lisa Huang, parent of two in Portland": "On Thursday night I used to ask our neighborhood Facebook group what was happening this weekend and get 40 replies, half of them for teenagers. " The call to action describes downloading the app and setting up a child profile in 90 seconds.
The founders use this press release to align on scope before building an MVP, cutting a social feature they had been excited about because it did not appear anywhere in the press release and therefore was not core to the value proposition.
Example: Internal tool at a mid-size company
A platform engineering team at a 300-person company wants to build an internal developer portal that consolidates service documentation, runbooks, and ownership information. The target customer is an on-call engineer who gets paged at 2 AM and needs to understand an unfamiliar service quickly. The team has data showing that the average incident resolution time increases by 40 minutes when the on-call engineer has not previously worked on the affected service.
The tech lead writes the customer sentence: "On-call engineers at our company who get paged for services they did not build and currently spend 15-25 minutes locating the correct runbook, identifying the service owner, and understanding the service's dependencies before they can begin debugging." The headline reads: "Engineering Team Launches ServiceMap, Helping On-Call Engineers Understand Any Service in Under Three Minutes." The subheadline adds: "ServiceMap automatically generates and maintains a single page per service with architecture diagrams, runbooks, ownership contacts, and dependency graphs, pulling directly from code repositories and infrastructure configuration." The body paragraphs describe an on-call engineer receiving a PagerDuty alert, clicking a ServiceMap link embedded in the alert, and landing on a page that shows the service's architecture, its three most common failure modes with resolution steps, and the Slack handle of the owning team. The customer quote is from "Dev Patel, Senior SRE": "Before ServiceMap, getting paged for a service I had never touched meant 20 minutes of Slack archaeology trying to find a runbook that might not exist. Now I click one link and everything I need is on one page." The closing paragraph explains that ServiceMap is pre-populated for all 47 production services and updates automatically when engineers merge changes to service configuration files. The 40-minute incident resolution improvement data point appears in the opening paragraph as the quantified stake, giving leadership a clear business case embedded in the narrative.
Best Practices
Write the headline before anything else and do not proceed until you are satisfied with it. The headline forces the hardest decision, which is choosing the single most important customer benefit. If you write the body first, you will hedge and try to serve multiple benefits, producing a muddled document that persuades no one.
Keep the entire document to one page, roughly 500-1,000 words. Length discipline prevents you from hiding weak thinking behind volume. If the value proposition is clear, one page is enough. If one page feels insufficient, the product concept may be trying to serve too many customers or solve too many problems simultaneously.
Use the customer's language, not your company's language. Read support tickets, sales call transcripts, and forum posts from your target customer segment. Borrow their exact phrasing. When the press release uses words the customer actually uses, it reads as credible. When it uses internal terminology, it reads as detached.
Include at least one specific, quantified claim about the improvement the product delivers. "50% faster" is better than "faster." "Saves 6 hours per week" is better than "saves time." If you do not yet know the number, write a placeholder and treat it as a research task. The act of committing to a number forces the team to think about measurement from day one.
Write the customer quote early in the drafting process, not as an afterthought. The quote is where empathy lives. If you struggle to write a believable quote, you may not understand the customer's emotional experience well enough. Use the difficulty as a diagnostic signal and go talk to more customers before continuing.
Separate the press release from the FAQ. The press release paints the aspirational picture. The FAQ interrogates it. Mixing skepticism into the press release weakens its narrative clarity. Save hard questions, edge cases, and technical challenges for the FAQ section, where they belong.
Date the document and version it. When a press release goes through seven drafts over three weeks, you need to know which version each stakeholder reviewed. Use a simple naming convention like "PR-v1-2025-01-15" and store all versions so you can trace how the product vision evolved.
Read the press release aloud. Awkward phrasing, run-on sentences, and unclear antecedents are far easier to catch when spoken. If you stumble over a sentence while reading it aloud, a reader will stumble over it silently too.
Common Mistakes
Writing about features instead of customer outcomes
Correction
The most common failure mode is a press release that reads like a feature list: "Product X includes AI-powered analytics, customizable dashboards, and Slack integration." This happens because the writer is more familiar with what the product does than with what the customer gets. To catch this, review every sentence and ask, "Would the customer care about this sentence?" If the answer depends on the customer understanding how the feature works, rewrite the sentence to describe the outcome of using the feature. "Customizable dashboards" becomes "Managers see only the metrics relevant to their team, without asking IT to configure anything."
Targeting multiple customer segments in one press release
Correction
Writers often try to make the press release appeal to several audiences: small businesses, enterprises, developers, and end users. This produces a document that resonates with no one because each sentence tries to serve too many masters. " Pick one customer. Write the press release for that customer.
If the product genuinely serves multiple segments, write separate press releases for each and see which one is strongest. That is your lead segment.
Using the press release to justify the project internally rather than describe customer value
Correction
Some press releases drift into internal justification language: "This product aligns with our Q3 strategic priority of expanding into the mid-market." This happens because the writer is thinking about the internal audience who will approve the project rather than the external customer who will use it. The press release should read as if a journalist wrote it for a customer-facing publication. If a sentence would not appear in TechCrunch or a trade blog, it does not belong in the press release. Move internal justification to the FAQ section or a separate internal memo.
Making the customer quote sound like marketing copy
Correction
" Real customers do not talk like this. They talk about specific frustrations and specific relief: "I used to dread Monday mornings because of the reporting. " The signal that a quote is too polished is that it could apply to almost any product in the category. Rewrite the quote with a specific detail that only applies to your product's unique approach.
Ground it in a moment in the customer's day.
Treating the first draft as final and skipping iteration
Correction
Teams under time pressure write one draft, get general approval, and move on to building. This defeats the purpose of the exercise. The press release's value comes from the iteration cycle, where each round of feedback exposes a new layer of unclear thinking. If the document has not been through at least three revision cycles with different readers, it has not been tested rigorously enough.
Watch for the pattern where everyone says "looks good" without specific feedback. That usually means reviewers skimmed it rather than engaged with it. Ask pointed questions: "Do you believe the quantified claim in paragraph two?
Burying the benefit below background context
Correction
Many press releases open with two paragraphs of market context and company background before getting to the actual product announcement. This mimics bad real-world press releases but is even more damaging in the internal version, where the reader needs to understand the value proposition immediately. The customer benefit should appear in the headline and be reinforced in the first sentence of the opening paragraph. Background context belongs in the FAQ section, not the press release.
If you find yourself writing "The market for X is projected to reach $Y billion by 2027" in the first paragraph, you are stalling. Cut it and lead with the customer.
Other Skills in This Method
Iterating PR/FAQ Documents Through Multiple Feedback Cycles
How to revise and strengthen a PR/FAQ document through successive rounds of leadership and cross-functional feedback, knowing when the document is ready to greenlight development.
Drafting the FAQ Section of a PR/FAQ Document
How to write both external (customer-facing) and internal (stakeholder-facing) FAQs that stress-test assumptions, address risks, and surface hard questions early in the product process.
Running PR/FAQ Review and Critique Sessions
How to facilitate Amazon-style narrative review meetings where stakeholders silently read the PR/FAQ document and then provide rigorous, structured feedback to sharpen the product concept.
Identifying Minimum Requirements by Working Backwards from Launch
How to use the Working Backwards process to ruthlessly scope down to the minimum set of technology, infrastructure, and features needed for a viable customer experience.
Using Working Backwards Thinking in Product Manager Interviews
How to apply customer-obsessed, Working Backwards reasoning to answer product sense, strategy, and prioritization questions in product manager interviews.
Defining the Desired Customer Experience Before Building
How to start from the ideal end-state customer experience and systematically work backwards to identify the features, services, and technology required to deliver it.
Frequently Asked Questions
How long should an internal press release be?
Aim for 500-1,000 words, which typically fits on one page. This constraint is intentional. A longer document lets you avoid the hard work of prioritizing which benefits matter most. If you find yourself exceeding 1,000 words, you are likely trying to cover too many customer segments or too many features. Cut until every remaining sentence directly serves the target customer's primary problem.
Should I write the press release before or after the FAQ section?
Write the press release first. The press release establishes the aspirational vision. The [FAQ section](/skills/drafting-frequently-asked-questions-documents) then stress-tests that vision by addressing hard questions, technical feasibility, business risks, and edge cases. If you write the FAQ first, skepticism will bleed into the press release and dilute its clarity. Complete a full draft of the press release before switching to the FAQ. You will inevitably revise the press release after writing the FAQ, but the starting sequence matters.
How do I write an internal press release when I do not have quantified data about the customer problem?
Use placeholder brackets for specific numbers, like "[X]% of managers spend [Y] hours per week on this task," and treat each placeholder as a research task. The press release draft reveals exactly which data points you need, which is one of its most practical benefits. Conduct five to ten customer interviews focused on quantifying the problem. Even rough estimates from real customers ("I probably spend four or five hours a week on this") are far better than invented numbers. Never fabricate statistics, even in an internal document, because fabricated numbers distort the team's sense of the opportunity.
Can I write a press release for an incremental feature improvement, or is it only for new products?
You can write a press release for any change significant enough that a customer would notice and value it. The test is whether you can write a compelling headline. If the headline reads, "Company X Updates Button Color on Settings Page," the change is too small. If the headline reads, "Company X Launches Bulk Editing, Letting Managers Update 500 Employee Records in One Click Instead of One at a Time," the change has a clear customer benefit and the press release format works. For very small improvements, a brief product brief or ticket description is more appropriate.
How many people should review the press release draft, and who should they be?
Three to five reviewers with diverse perspectives produce the best feedback. Include at least one person who represents the customer's point of view (a customer success manager, a support engineer, or an actual customer if possible), one technical stakeholder who can flag feasibility concerns, and one person completely unfamiliar with the project who can test whether the document is self-explanatory. More than seven reviewers slows the process without proportional improvement. Collect written feedback from each reviewer individually before any group discussion to prevent anchoring.
Why does my press release keep drifting from the customer's perspective to internal justification language?
This drift happens because the writer is unconsciously optimizing for the approval audience (leadership) rather than the stated audience (the customer). It is especially common in large organizations where project approval requires demonstrating strategic alignment. The fix is mechanical: after each draft, search for phrases like "aligns with our strategy," "supports our roadmap," "drives revenue," or "expands our market." Move every such phrase to the FAQ section under an internal stakeholder question like "How does this align with our company strategy?" The press release itself should contain only language a customer-facing journalist would write.
How do I handle a press release when leadership disagrees about the target customer or primary benefit?
This is the press release working exactly as designed. Disagreement about the customer or benefit is a strategic misalignment that the press release has surfaced. Do not try to resolve it by writing a vague compromise that covers multiple customers or benefits. Instead, write two or three competing versions of the press release, each committed to a different customer or benefit. Present all versions side by side in the [review session](/skills/running-pr-faq-review-meetings). The concrete specificity of competing press releases makes the trade-offs tangible in a way that abstract strategy discussions cannot. The team picks the version that best fits the company's strengths and the customer's urgency.