Skip to main content

Press release process

Press Release Process

warning

This is an early draft and isn't yet up to our standard. You can contribute improvements.

Definition & Summary: Using Amazon's famous "working backwards" product development method -- writing a press release and FAQ for a proposed product at the start -- to ensure clarity of vision and market fit . While not an attack on competitors per se, it's a leadership strategy to guarantee any initiative you undertake has a clear, compelling value proposition, effectively outmaneuvering competitors who might build less focused offerings.

Detailed Explanation: Popularized by Amazon, the Press Release (PR) FAQ process forces teams to articulate the customer benefit, problem solved, and excitement factor of a new product as if launching it to the public . The idea is to simulate the end state (launch) at the beginning, aligning everyone on what success looks like. Key principles: focus on customer needs, simplicity of message, and clear differentiation (if you can't write an exciting press release, maybe the idea isn't exciting). Origins: Jeff Bezos mandated this to avoid building stuff with no market narrative. For leadership, this process ensures your strategy produces initiatives that can be communicated simply and attract buzz -- meaning you're more likely to build something customers actually want (which in turn is an offensive advantage over competitors building bloated or misaligned solutions).

Real-World Examples:

  • Amazon: Almost every product (Kindle, AWS service, Echo) at Amazon began with an internal press release draft. For instance, AWS Lambda's team wrote an internal PR about a service that lets developers run code without managing servers (clear value). This upfront clarity guided development. By launch, the messaging was spot-on and adoption was quick, while competitors took longer to articulate serverless computing. Amazon's use of this process has been credited with launching very customer-centric, sharply defined products -- an edge over competitors who might release confusing or half-baked services.

  • Other companies adopting it: Netflix has reportedly used a similar approach for feature development -- writing the blog announcement first to frame the why/how. This allowed them to beat competitors in clarity -- e.g., when introducing "Downloads for Offline Viewing," having a crisp narrative helped communicate it better than others who added similar features with less fanfare.

  • Hypothetical: A SaaS startup uses Press Release process for all major new features. By doing so, they avoid feature creep and always highlight what's newsworthy. Over time, customers notice that every update from this company seems meaningful and well thought out (versus a rival that dumps long release notes full of minor tweaks). This builds stronger brand trust and media coverage. Strategically, they've made sure internally that they don't waste resources on things that wouldn't sound good on a press release -- a filter that aligns product strategy with marketing and customer excitement.

When to Use / When to Avoid:

  • Use when: Developing new products or major features in any context. It's a versatile strategy for ensuring market-driven development. Use especially if your organization has a history of internal, tech-driven projects that later struggle to explain their value. Press release process can correct that by making value prop central from the start . Also use if cross-team alignment is an issue -- the PRFAQ serves as a single-page vision everyone references.

  • Avoid when: Perhaps in extremely secretive innovations where writing a press release could leak (though internally it's still within confidentiality). There are few downsides except that it's a cultural shift -- teams might resist the unusual practice ("why are we writing fantasy press releases?"). If not taken seriously, it doesn't work (it's not just writing, it's truly conceptualizing from customer perspective). Also avoid if an initiative legitimately has no marketing angle (very back-end infrastructure improvements -- though even then, an internal press release focusing on internal user, e.g. devs, could help clarity).

Common Pitfalls:

  • Faking it: Teams might write a glowing press release but not actually let it influence design (checking the box rather than iterating on the product idea based on it). This yields no benefit. The doc must cause reflection: "if this PR doesn't sound amazing, how do we change the product to make it amazing?"

  • Lack of follow-up: The PRFAQ should be updated as product changes or used as a spec to verify implementation meets the envisioned benefits. If it's written and then ignored, it's wasted.

  • Overhyping risk: One must also deliver what's in the press release. If you promise those features, ensure they make it, else at launch you'll have a disconnect (press release process is internal, but it should be grounded enough that you can actually achieve that story).

Related Strategies: Focus on User Needs (press release process is an implementation of that doctrine -- forcing user-centric view), Brand & Marketing (makes marketing an integral part of dev, so product naturally fits marketing), it's not directly about competitors but ensures your output is compelling, indirectly outflanking competitors with clarity and user focus.

Further Reading & References:

  • Bezos' mandate: Amazon's Working Backwards methodology (there are many articles, and an actual book titled "Working Backwards" by ex-Amazonians). They detail how PRFAQ shaped Kindle, AWS, etc., and why it gave Amazon an edge in product strategy .

  • Wardley note -- mentions "the best way... force writing of press release before project starts because no-one can write a press release for something unexplored" indicating this process prevents doing nebulous pioneering with no clear outcome.

  • Medium -- likely referencing an Art of Strategy piece that lists Press Release Process as a strategic tool (as we see line mentioning it with Wardley context).