(2019-06-19) Munro PR/FAQs For Product Documents - everything Product Managers Need To Know

Robert Munro: PR-FAQs for Product Documents — Everything Product Managers Need to Know. (See Amazon Meeting Memo)

A PR FAQ follows a fairly strict format:

• A Press Release (PR), written from the future point-of-view of when the new product is released.
• A Public FAQ, detailing the questions that a customer might have about the product, written as if it is public product documentation that is released at the same time as the PR.
• An Internal FAQ, answering any questions from internal stakeholders that have come up during the product development process.

Basic PR FAQ Format

A press release is typically one to one and a half pages

The FAQs are open-ended for how long they can be, and this is where the biggest differentiation occurs between simpler and more complicated products. For example, a simpler feature might have 2 pages of FAQs and a more complicated product might have 20 pages of FAQs.

The PR FAQ is a good gating function. If you can’t create a PR that is clear to all your stakeholders, then it is probably a bad product idea: maybe you are cramming too many things into one product, or the impact of the product is not addressing a real pain-point.

Template for a PR FAQ

Press Release

FAQs

Internal FAQs

An FAQ might include wireframes of a product with a strong UX component, or a link to separate wireframe documents, but the PR should rely on text alone

Why does the PR FAQ format work?

1. Customer-centric

2. Makes your assumptions explicit

The PR FAQ should therefore contain enough information for someone to argue why this particular product/feature is the most important next feature to work on.

3. Interpretable by any stakeholder

At AWS, I had to get sign-off for my products from about 50 different people: sales, legal, design, localization, marketing, multiple engineering teams, etc. At the start of my conversations with each one, they asked for the PR FAQ

4. Increases the ownership of stakeholders

That fact that anyone can add to a PR FAQ is a strength for ensuring buy-in

5. Can be created by any stakeholder

It is likely that a PM will still guide the product development process, but the first idea can come from anyone.

For one of AWS’s recent Machine Learning products, the first PR FAQ was written by an intern on the Science team.

The more product leadership experience I get, the more deeply I believe that it’s product’s role to facilitate the product development process, not to define what products and features should look like

How does this PR FAQ format differ from Amazon?

1. Allow some design elements in your FAQs

Amazon’s product process is famously text-driven. I never saw a PowerPoint presentation when I was there except for external talks. The UX Designer I worked with was one of the strongest ever, but relative to anywhere else I’ve worked design came into the product process late.

I agree that the PR should be kept to text

This can be very simple and framed as a question: Q. What do the wireframe look like for the MVP of this product?

For the review meetings, don’t let these design elements become the starting point for people’s interpretation of the product: that is exactly what the text-based approach is trying to avoid

2. Allow more details about potential solutions

As with design elements, these can be added to the FAQs as questions, like: Q. Can our existing database solution support this new product?

While a product document should be independent of the technical solution, it can help to include some details that will give reviewers an idea of the scale of potential solutions.

3. Elicit feedback in multiple different ways

Example PR FAQ

Here’s an example PR FAQ for a fictional product. It is a predictive email feature that tries to predict the next words when someone is writing an email, like you might have seen some companies release recently.