press-release
Write customer-focused press releases before building to align stakeholders on product vision.
- Follows Amazon's Working Backwards methodology: start with a press release and FAQ before engineering begins, forcing clarity on customer value and problem solved
- Structured template covers headline, problem statement, solution (outcomes not features), executive quote, supporting details, and call to action
- Serves as a planning and alignment tool, not a launch-day marketing document; helps test if a product idea is compelling enough to warrant development
- Includes quality checks and anti-patterns to avoid feature-centric language, vague benefits, jargon, and unsubstantiated claims
Purpose
Create a visionary press release following Amazon's "Working Backwards" methodology to define and communicate a product or feature before building it. Use this to align stakeholders on the customer value proposition, clarify the problem being solved, and test if the product story resonates—treating the press release as a forcing function for clarity and customer-centricity.
This is not a marketing artifact for launch day—it's a planning tool that asks "If we shipped this perfectly, how would we explain it to the world?"
Key Concepts
The Amazon Working Backwards Framework
Popularized by Amazon, the Working Backwards process starts with a press release and FAQ before any code is written. The press release must:
- Be written from the customer's perspective
- Focus on the problem solved, not the features built
- Be short (1-1.5 pages)
- Be compelling enough that customers would want the product
Press Release Structure
A standard press release follows this format:
- Headline: Clear, benefit-focused product announcement
More from deanpeters/product-manager-skills
prd-development
Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.
1.7Kuser-story
Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.
1.7Kroadmap-planning
Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.
1.5Kcompany-research
Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.
1.3Kproduct-strategy-session
Run an end-to-end product strategy session across positioning, discovery, and roadmap planning. Use when a team needs validated direction before committing to execution.
1.2Kprioritization-advisor
Choose a prioritization framework based on stage, team context, and stakeholder needs. Use when deciding between RICE, ICE, value/effort, or another scoring approach.
1.1K