Why you should write more than one product press release.

Most product people have heard the advice to ‘write the press release’ at the beginning of a new product effort. It’s great advice! But I think it can be improved by ‘prototyping through press releases’ or simply writing several variations.

If you’re not familiar, the method was

popularized by Amazon⁠

where they called it the ‘PR FAQ’ process. The press release ritual spread widely throughout our industry due to it’s effectiveness at getting teams aligned early in the lifecycle of an effort.

Why? Writing a customer-centric press release forces a team to clearly articulate what problems they will solve and why a customer will care. And importantly, it’s written in plain language and not internal jargon.

Oftentimes, teams will kickoff and immediately wade into the complexity and decisions ahead of them. And it’s too easy to get carried by the momentum of early ideas and solutions. That’s the time to stop and write the press release, or several versions!

The problem with writing just one press release.

One trap I’ve observed with this classic ritual is writing just one press release, then making only minor tweaks to the details based on minor comments.

Whenever I see this happening, I think of Laseau’s Funnel and the overlapping funnels of Elaboration and Reduction (as often read in Bill Buxton’s books

Sketching User Experiences⁠

⁠

⁠

The problem occurs when the first version of the press release anchors the product direction too early in the process. So instead of being a generative exercise that helps team tease apart different directions they might pursue, it becomes reductive to the problems they already know the most about, and their initial set of ideas and solutions.

What most people forget during this process is that testing product directions with simple press releases is one of the fastest, cheapest ways to iterate on the early customer and product direction. Instead of writing code, you’re simply writing and iterating on text over the course of a couple days. It’s what I call prototyping with press releases. This small amount of time spent in the Elaboration phase has the potential to save weeks or more of designing and writing code.

Below is a diagram to illustrate the problem using the same Laseau funnel diagram.

⁠

⁠

In the diagram above, the team sped past the generative, elaboration phase and settled on a first version of a press release that is now anchoring the product direction.

⁠

The solution: write multiple press releases.

One simple tweak can make this ritual more effective.

Write two or three divergent press releases, then let the team read, compare, react. Ask for their feedback on two levels ー quick reactions and deeper reflection. Below is what that looks like using the funnel diagrams.

⁠

⁠

This is a similar approach most product teams are accustomed to with design explorations. Designers will frequently present a range of low-fidelity explorations in the beginning to begin teasing apart what is important and what doesn’t work. In this case, presenting two or three press releases creates a similar effect ー less nitpicking the details and more discussion around the problem and core strategy.

Don’t take my word for it though,

Try It⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.