Product Announcement Playbook

Laura Spiekerman of Alloy APIs tweeted a question regarding information sharing at startups that spawned some really interesting responses.

As a product manager who has worked in organizations of various stages (seed at Blispay, mid-size high growth at Millennial Media & Bill Me Later, and large-cap at PayPal), I’ve needed a simple process for communicating updates of high profile initiatives. Processes such as the one I outline below are as beneficial, if not more beneficial, for me than for the broader org.

Note that I chose to focus this post on updates specific to projects or new product development, not broader company updates (which is partly what Laura was asking about). For the latter, the main thing we did consistently was a company-wide meeting every Friday that focused on growth, product announcements, and highlights from all other areas of the business.

Below is an example process that I’ve followed for several high profile initiatives. My recommendation to product managers (or startup operators) will be to create a process of your own if one doesn’t exist. If the ‘why’ and ‘what’ isn’t clear to you, then you won’t be able to do a good job. Sometimes it’s your job to push for clarity amongst stakeholders.

Goals

• Steer a team towards a successful outcome (the goal of every product manager).
• Communicate early, often, and in a very easily consumable format. Iterating on words is the cheapest form factor to iterate on. Avoid stakeholders claiming that they’re surprised by the way something works, looks, or by how long development is taking.
• Remain laser-focused on the end customer and minimum required necessities to satisfy business goals.
• Paint the big picture so everyone knows where you’d like to go eventually even though you’re not going there initially.
• Begin thinking early about all of the necessary details aside from just development (test plans, rollout plans, data retention, training, pilot programs, seasonal impacts, 3rd party contracts, etc.).
• Have a single repository of all things ‘x project’ to reference in the future.
• Have a repeatable process that scales across the organization for any project or product that will take >3 months.

Process

1. Write the ‘Announcement Post’ which is essentially a Memo / Amazon Working Backwards Press Release / Product Marketing doc. This part takes a lot of time. Potentially a couple of weeks. Perhaps much longer. Focus on the ‘why’ and the ‘what’ instead of the ‘how.’
2. Review it with stakeholders, individually and as a group. Iterating on this artifact at this stage is significantly cheaper and easier than waiting until you’re in the middle of development. That doesn’t mean everyone will be locked into what was agreed upon without the ability to make changes if needed. At least with this framework, communication of the strategy shift and alignment across groups should be easier.
3. Create the ‘Announcement Roadmap’, which at this stage should have links to future ‘Monthly Updates’ as well as some high-level big milestones that you hope to deliver. Start with higher fidelity for the next 1–3 months and lower fidelity in later months.

4. Write the first ‘Monthly Update’, which is essentially a newsletter-style post. Before the month, it primarily contains To-do’s, but as the month progresses, scratch them off and put them in the ‘Done’ section. At the end of each month, it should read as a newsletter of everything that was completed with relevant links out to important artifacts.

5. As time goes on, increase the fidelity of the Announcement Roadmap and continue chipping away at upcoming Monthly Updates.

6. Over-share all of this content, frequently. Assume your team is fully remote, even if they aren’t. It will encourage you to stay on top of producing all of this content and sharing it.

H/t to Amazon

A “Working Backwards Press Release” is an approach to product development that has been popularized by Amazon. I’ve never worked at Amazon, so below is my interpretation of the approach based on what I’ve read by Ian McAllister and others, and how I’ve chosen to interpret the process. My process above clearly isn’t the same, but this approach inspired it.

For new initiatives, you would write an internal press release which would announce the finished product. It would center around how it solves a problem for the customer, how current solutions (internal or external) fail, and how the new solution will blow existing solutions out the water. The idea is that you keep iterating on the Press Release until you have something ready for production. “Iterating on a press release is a lot less expensive than iterating on a project itself.”

As a project moves through development, the Press Release should be used and referenced frequently; it’s a guiding light. If you find your team building and talking too much about things that aren’t in the press release then you know you’re focusing too much on creep and need to narrow your focus again. This keeps you focused on achieving the actual customer benefits and not building extraneous stuff that takes longer to build, more resources to maintain, and doesn’t provide real customer benefit (at least not enough to warrant inclusion in the press release).