PR FAQs for Product Documents

Photo by rawpixel.com from Pexels

A Press Release (PR) Frequently Asked Questions (FAQ) is a customer-centric document for designing new products. It is an idealized future “Press Release” (PR) and associated FAQs. The PR FAQ is the starting point for your other product documents.

This article is for anyone interested in the PR FAQ process. One strength of PR FAQs is that they can be understood by anyone in an organization. So this article is addressed to Product Managers who are considering adopting PR FAQ Product Documents, but it can be equally interesting to anyone involved in building technology products.

A PR FAQ follows a fairly strict format:

1. A Press Release (PR), written from the future point-of-view of when the new product is released.
2. 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.
3. An Internal FAQ, answering any questions from internal stakeholders that have come up during the product development process.

The PR FAQ format has been around a while, but it was popularized by Amazon (where I first learned it) and is now used by Product Managers widely. I use a slightly different product format and review process than Amazon, which I’ve refined since my time there. I talk more about the format below, and I discuss the review process in two other articles:

This article is part of a series, focusing on the PR FAQ document itself.

Basic PR FAQ Format

A press release is typically one to one and a half pages and follows a very templated format, that you’ll see below. At Amazon this was strictly enforced. A small feature like a new search bar is probably a one page PR, no shorter. Acquiring WholeFoods for $13.7B was probably a one and a half page PR, no longer.

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 should be the starting point for all of your other product documents:

• Your engineering team should be able to use your PR FAQ as the starting point for scoping; your design team should be able to use your PR FAQ as the starting point for design documents
• The sales team should be able to use your PR FAQ to design the sales playbook for the new product
• Marketing should be able to use the PR FAQ to create actual press releases
• Your executive sponsors should be able to use your PR FAQ to understand the resource allocation needed to build the product, etc.

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. If stakeholders are asking questions that you can’t answer in your FAQs, then you haven’t put enough thought into the product yet to start building it.

Template for a PR FAQ

Here is a template for a good PR FAQ. The plain text summarizes what each section does and the italicized text highlights what each section is trying to achieve and the assumptions it is testing.

Press Release

Heading: short name for the product that the target customers will understand

Subheading: One sentence saying who the market is and what the benefit is

Summary: 2–4 sentences that gives a summary of the product and the benefits. Should be self-contained so that a person could read only this paragraph and still understand the new product/feature.

Problem : 2–4 sentences describing the problem that a customer faces, which this product solves. Tests your assumptions about the pain-points that you are addressing.

Solution : 2–4 sentences, describing how the new product/feature addresses this problem. Tests your assumptions about how you are solving the pain-points.

Getting started: 1–3 sentences describing how someone can start using this product/feature (if it’s baked into the existing product, say this explicitly). Tests your assumptions about how easy the ramp-up is for your customers to take advantage of the new product/feature.

Internal quote: Someone within your company being quoted about what they like about the product/feature. Tests your assumptions about the value you are creating for your customers and how you position this product within your broader product offerings.

Customer Quote(s): a hypothetical customer saying what they like about the new product/feature. Tests your assumptions about how you want your customers to react to the new product/feature and your ideal customer profile. They should be doing something that they couldn’t do before, doing something much quicker and easier, saving time and effort, or in some other way making their life better. Whatever the benefit is, their delight in the benefit(s) should be exhibited in the quote. This should be multiple quotes from different customers if you have multiple profiles of ideal customers, example: mid-market and F50 customers.

Call to action: 1–2 sentences telling the reader where they can go next to start using the product/feature. Tests your assumptions about whether this is a feature that is automatically on, something they need to turn on, a beta-release, etc.

FAQs

A set of public frequently-asked questions and their answers. This should be a comprehensive list of everything that a customer might want to know about the product. It should include any reasonable question that comes up when discussing the new product/feature with customers and customer-facing teams during the development of the product/feature.

Internal FAQs

A set of private, internal frequently-asked questions and their answers in a format that can be understood by every other stakeholder. 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. This will allow all internal stakeholders to get clarity on the product/feature.

The PR/FAQ format works because it is:

1. Customer-centric
2. Forcing your assumptions to be explicit
3. Interpretable by any stakeholder
4. Increases the ownership of stakeholders
5. Simple enough to be created by any stakeholder

1. Customer-centric

The PR/FAQ strategy works because it is customer-centric and is often called “working backwards,” as you are starting from the release and backfilling the details to get there. It is always the PM’s job to hold the vision of the end product in mind, and nothing helps better than to have the end point as your first doc.

There are a couple of ways to make the customer impact even more prominent in a PR FAQ. This first way is using customer quotes. As it says in the PR FAQ template above, you can have multiple customer quotes to capture different markets that you are going into, and you might also want to have multiple customer quotes to capture the different ways in which your product will impact your customers. The second way to make the customer impact even more prominent is to be explicit in your FAQs. For example, I always include “What will our customers like most about the product?” as one of the first questions in the Internal FAQ. So, even your company-internal discussion is customer focused.

2. Makes your assumptions explicit

The PR FAQ helps you test assumptions about whether a customer-driven feature is really going to make a big difference. For example, if you write your first PR FAQ and the pain-point you are addressing is “an extra mouse-click” every day, then it tests your assumption about how important that feature is. Your customers might really hate the feeling of redundancy in that extra mouse-click and you can wow them with a new design that solves that problem, but you can probably solve bigger problems with the same resources.

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. Just make sure that separate your discussions about scoping a product from your discussions about that product’s priority on your roadmap: they are different discussions with different stakeholders and it can be too confusing to attempt to solve scope and priority at the same time.

3. Interpretable by any stakeholder

The PR/FAQ document works as a single consistent style that all stakeholders should be able to understand. 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. This really drilled home for me how effective the PR FAQ process was: everyone expected a product document in a format that they knew deeply and could immediately adapt to their task. It would not have been possible to adapt the document to 50 different stakeholders without there being differences in those 50 documents that misaligned expectations.

The FAQ component of the document, in particular, is extremely effective in capturing the assumptions and perspectives of different stakeholders in a consistent format that all other stakeholders can understand.

4. Increases the ownership of stakeholders

That fact that anyone can add to a PR FAQ is a strength for ensuring buy-in. Everyone can now feel committed to the product and its success. Any feedback that a person gives can be immediately added as a question to one of the FAQs. This is a great way to ensure that people have their voices heard: they can see their actual words in the product document right away. Everyone’s feedback is equal: a question from an intern looks the same as a question from an executive; and questions from your most technical stakeholders looks the same as a question from your least technical stakeholders.

By comparison, not all feedback on an abstract presentation or wireframes is equal. People more familiar with product management will better understand the conventions and be able to give more detailed feedback. Other stakeholders won’t see their feedback incorporated or understand how their feedback will be acted upon immediately compared to adding their question to one of the FAQs.

It’s your job as a Product Manager to ensure that everyone’s voice is heard, so you don’t want the format of product document documents to be a gating function. If someone does give feedback on wireframes or ‘slide-ware,’ it might not be clear to them later how their feedback was taken into account in the next iteration of the design. There is no such ambiguity when they see their questions as part of the FAQ as it is their own words, even if the answer to their FAQ question is not what they expected or wanted to hear.

5. Can be created by any stakeholder

Anyone in an organization should be able to write a PR FAQ, not just Product Managers. That’s one of the strengths of the format: you don’t need to be a PM or know any particular software to create the product document. 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. This person ultimately moved into a full-time position on the product team in order to see the process through of taking a new product to market. So if you are a product leader that likes to develop good PMs from other parts of your organization (and honestly, every good product leader should do this) then the PR FAQ is a great way for people to test out how much they like product management.

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. Product Managers might come up with genius new product ideas that no one has thought about before, but no more than someone in any other role in the company. If you can’t get someone else to independently come up with the same product idea from the same data as you, then maybe it wasn’t such a genius idea in the first place. A PR/FAQ therefore levels the playing field by giving everyone in an organization a framework for expressing their initial product ideas. It opens the funnel to more ideas and encourages the spirit that the best ideas win, no matter who it comes from.

Photo by rawpixel.com from Pexels

There are three main ways that my PR FAQ documents differ from Amazon’s:

1. Allow some design elements
2. Allow more details about potential solutions
3. Elicit feedback in multiple different ways

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.

It is not necessary to be as text-focused as Amazon about how you run the PR FAQ process. I agree that the PR should be kept to text: it’s too easy to have unspoken assumptions from early graphical designs, and so requiring the PR to be text is a great forcing function to make assumptions explicit. But UX Designs can help early on. In my role today, we are building technologies for real-time interactions between humans and Machine Learning. The Human-Computer Interaction, and by extension the UI design, is very important for our products. So, my compromise is to allow some diagrams in Internal FAQs (not in the PR). This can be very simple and framed as a question:

Q. What do the wireframe look like for the MVP of this product?

I include 1 or 2 images, at most, and link to design documents for more details.

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. When drawing attention to design elements in the PR FAQ, I recommend asking people if the designs reflect their understanding of the PR FAQ itself. This keeps the focus on the PR FAQ as the source of truth for what goes into the product, rather than letting the visual elements become the source of truth, which would otherwise happen for more visually oriented people.

2. Allow more details about potential solutions

Your engineering team might immediately start thinking about solutions to the product: what are the code libraries, databases, caching solutions, etc.?

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. In a larger company this might not matter, but especially if you are at a startup with a limited budget, it is likely that your executives will want to get an idea of the resources required very early in the product design process. I recommend that all answers be suggestions: “We might …“, “It is possible …”, etc., so that there is no confusion that these are actual technical specifications or that anything is set in stone at this stage. You could accidentally mislead an engineer later into thinking that the technical solutions had been decided, when it was only early speculation to aid scoping.

After some potential solutions have been scoped and the resource investment mapped out, the high-level details should make it into the FAQs. However, they should link to the scoping documents and not confuse anyone into thinking that the PR/FAQ is the ground-truth for this level of engineering detail. This is important for organizational reasons: your Engineering team should feel like they own the scoping documents, just like your sales team should feel like they own the playbook materials about the product and your marketing team should own the actual PR, etc. No one wants to feel like Product Managers are micro-managing their work — a common (mic)perception — so having clearly demarcated ownership of your product documents is one important component for knowing who owns what.

3. Elicit feedback in multiple different ways.

The Amazon process for PR FAQ is just as structured as the documents themselves. I will cover the review process and ways to ensure a diversity of feedback in two upcoming articles:

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.

Remember that a PR FAQ is a living document that is continually edited — I’ve seen version numbers around 100 at large companies. Consider this example to be something around version 4 or 5: a PM has had a few passes and the first review with their immediate manager, and so the PR is ready for the first meetings with internal stakeholders.

Acme Releases Smart Email to its customers

Acme’s smart email tool uses predictive text to make writing emails 10 times faster

August 4th, 2019. Acme is excited to announce the addition of smart predictive text to our email products. The new capability, “Smart Email”, suggests the next few words in a sentence while a customer is typing that email. The customer can hit Enter or Tab to accept those words, rather than manually typing each one. Because many of the emails that we write tend have a lot of repeated text, this can make composing emails up to 10 times faster. With Acme Smart Email, you can focus on what is unique and important in your email, leaving the rote parts to the smart suggestions.

Writing emails is a repetitive task and throughout the day, many people type some phrases over and over again, like “please see the attached document”, or “let’s schedule a meeting next week”. Existing solutions with acronyms and templates have severe shortcomings. Acronyms can create confusion or make an email appear rushed and impolite. Many people use templates for emails, but templates can be inefficient to edit: by the time someone has clicked on the template in a few different places to change the text, it might have been quicker and easier to manually type the entire email from scratch.

Smart Email solves the problem of creating long-form emails efficiently by removing the redundancy in your typing. If you start typing a sentence like “please see…”, then Smart Email might suggest “… the attached documents” and you only need to hit a single key to add those words to your email. Smart Email will also learn your style. For example, if you sign off emails with “best” or “kind regards”, or if you spell it “color” or “colour”, Smart Email will start to learn your stylistic preferences and adapt to those styles.

Acme Email users can start using this feature today. When you start composing your emails within a browser or on our iOS and Android applications, you will now see suggestions for the next few words that you might want to type.

“We are excited to help our customers become much more efficient,’’ said Will Canis-La Trans, VP of Product at Acme Communication Technologies, “with Acme Smart Email, we are releasing the first of many Machine Learning-driven features to make a more delightful product experience.”

“Smart Email is saving us hundreds of hours of work every week!’’ said Via Velox, Director of Marketing at Geo Coccyx, “Smart Email became my team’s new favorite tool. After just a few days it learned my style and was suggesting content that sounded natural and was composed exactly right for our style-guides!”

Log on to your Acme Email account today to begin using this feature! You can use the feature for free for up to 1,000 emails per week while Acme Email is in beta mode.

FAQs

1. How can I start using Acme Smart Email?

If you log into your Acme Email account at [LINK] or open the Acme Email application on your phone, you should immediately see the smart suggestions when you start typing your emails.

2. Do I have to use the suggestions from Acme Smart Email?

The suggestions from Acme Smart Email are optional: you can ignore them and type whatever you like. You can also turn off Acme Smart Email entirely in Settings -> Smart Settings.

3. Do smart suggestions also work in Acme Docs and Acme Sheets?

No, today the smart suggestions are limited to Acme Email.

4. What languages does Acme Smart Email work in?

Today, Acme Smart Email works in English, Spanish, Hindi, Arabic, Chinese (simplified), Matsés, and German. We will add more languages in the future and welcome suggestions about what language to support next!

5. How does Acme Smart Email learn from my emails?

Smart Email uses state-of-the-art Machine Learning models to adapt to your style and learn how to write some of your sentences for you.

When you type the same sequence of words a few times, like “please see the attached document”, then Smart Email can learn that “please see the attached…” is often followed by “…document”. Smart Email starts with a lot of this kind of knowledge out-of-the-box and then also adapts to your style. If you often type “please see the attached presentation”, then Acme Smart Email will learn this pattern and start suggesting “…presentation” rather than “…document” to complete your sentence. So, it will get smarter the more that you use it!

6. Do you use my emails to help with suggestions for other customers?

No, your data security is our top priority. We don’t share the content of your emails with anyone else. The predictive-text capabilities that are customized for you are also only available to you: we don’t change other people’s suggestions based on what we learned from you.

7. How long will it take Acme Smart Email to learn my style?

It generally takes about 1,000 emails before you get the best benefits from Acme Smart Email. Our customers start seeing a 2x to 5x speed-up straight away, but it is not until 1,000 or so emails have been written that you might see the 10x speed-up that a lot of our customers enjoy.

There is no time constraint on this. If you typically send 1,000 emails in one day, then you should start seeing very large speed-ups within one day!

Internal FAQs

1. What will customers like most about Acme Smart Email?

Customers will like the increase in efficiency it gives them, coupled with the general delight in removing the most redundant parts of writing emails.

2. What will customers like least about Acme Smart Email?

Customers will be disappointed in the language coverage. In particular, we have many customers in Latin America who use both Spanish and Portuguese, but we only support Spanish in the first release. We will personally reach out to these customers in advance to acknowledge that Portuguese is missing and that it is a high priority for a future version of the product.

3. What are the privacy concerns with this product?

We assume that emails will contain personally identifying information (PII) and that this information can be contained in the Machine Learning models that are predicting someone’s text. Therefore, if someone deletes an email, we also delete the models for the customer that were trained on that email.

4. How do we compare to our competitors?

Our biggest competitor, GeezMail, already has predictive text for their email customers, so we are catching up. They offer more languages today. However, they don’t customize to each individual customer, so our predictive text quickly becomes much more accurate and customized to the “voice” of each of our customers in a way that theirs does not.

Try one yourself

Now that you’ve learned about the PR FAQ and seen a template and example, try one for the next product or feature that you are designing for your organization.

Acknowledgements:

Thank you to seasoned Product expert, Greg Chang, for detailed feedback on this article.

See also this article: Try an Internal Press Release before starting new Products, by André Faria Gomes.