Tactics for Leading and Optimizing PR FAQ Reviews

A PR/FAQ is a Press Release (PR) & Frequently Asked Questions (FAQ) document is a living product asset that a Product Manager is continually updating and refining throughout the product development processes. It is a customer-centric document that is an idealized future “Press Release” for the proposed product and associated FAQs. It is also the starting point for your other product documents. If you aren’t familiar with the PR FAQ document format, I recommend starting with this article and then return to this one:

You should also consider this article as additional reading if you care about getting diverse feedback:

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 should be equally interesting to anyone who has to participate in PR FAQ review meetings. If you are invited to attend a PR/FAQ meeting and you are not in Product Management, then this article should give you insight into the broader process that you are taking part in.

The PR FAQ should be reviewed by every stakeholder up the management chain in your organization. This should occur up to the person or people who sign off on whether to go ahead and on the resources needed to build the feature.

You should know in advance exactly how far up the chain you need to go. I’ve seen organizations of 100,000's of employees where the CEO still needed to sign off on every product. I’ve been CTO of a 150 person company where I was only asked to sign off on major products or products the diverged from our roadmap. Both worked fine: work out the right level that fits your company culture.

Use your best judgment as a Product Manager for the right order of stakeholders to meet with, and which meetings should have multiple different stakeholders. This is probably no different to how you decide on who needs to attend product meetings today, but you might be able to engage people earlier because the PR/FAQ format can be understood by anyone in the organization, so you don’t need to wait until wireframes or a prototype us developed. You get the executive sign-off last because you want your PR/FAQ document as polished as possible when you are getting the go or no-go decision.

For each meeting with the stakeholders you run the meeting as follows:

There are different actions depending on how the meeting goes. If you’re in a very structured work environment then you might have a senior person that is the main host of the meeting as you are moving the PR FAQ up the chain. That person should know that it is their call as to whether they need the meeting repeated or if they are okay with process moving to the next step. Often, there won’t be one clear senior person who signs off on the next step, so it is the decision of the Product Manager running the meeting as to next steps.

Here are four possible outcomes:

Here are some tactical lessons I’ve learned about running PR/FAQ meetings that should help you if you are adopting this process for product development.

Even if everyone claims to have read it in advance, some people might not have read it but won’t admit that in a group setting. Or, people might not have read the most recent version. Or, it may not be fresh enough in people’s minds, including your own. By (re)reading, it helps keep the discussion within scope: you don’t want to waste everyone’s time answering questions that are already in your FAQ.

Despite building the world’s most successful eReader, Amazon uses printed documents for PR FAQ reviews. I have always suspected that this is to ensure that people are reading the PR FAQ and don’t have something else up on their screens. A printed document also gives more formality to the process and allows you to collect the documents afterwards to see the notes that people made on their documents. If you do use printed documents, please print on both sides and recycle to save the environment.

Always read the document yourself as the PM. If you are sitting there watching people while they read, they might feel the need to read quickly and either skim or skip sections. By reading the document yourself, you are giving people license to take the necessary time. More below on how to deal with habitual skimmers.

As a rule-of-thumb, I recommend spending at least as much time writing/updating a PR/FAQ as people will spend reading it. This is the respectful minimum amount of effort to prepare for people that are taking the time to provide feedback. For example, if you have 10 review meetings with 3 people in each meeting, then by the last meeting you should have spent at least 30 hours writing and updating the document. Expect to spend more time updating and rearranging the FAQs as you progress.

Don’t write your product documents in the middle of a busy office. Especially as a Product Manager, people will be regularly coming up to you with questions. As a PM you should be open to people approaching you, so you generally don’t want to look approachable as you work on your documents. Book a meeting room if you work in an open office so that you can concentrate for a couple hours on updating the document, or work from home if meeting rooms are at a premium in your office. Block off time as soon as possible after each meeting so that the feedback is fresh as you add it to the PR/FAQ.

If you have written a dissertation in the past, think of your product document as something that deserves equal attention. It is your role to think deeper about the product implications than anyone else in your company, so you need to be immersed in the writing process. Unlike your dissertation, people will actually read your document. Don’t be fooled by the shorter format: a good 1.5 page PR will take a lot longer to write than a 5 page brain-dump. For perspective, a PR/FAQ at AWS might have months of full-time work before it makes it to the review meeting with the CEO.

Not everyone will be comfortable asking questions in a group meeting, especially if there are more senior people present. For more on the potential biases that you could perpetuate, see the accompanying article: Driving Diverse Product Feedback at your Company.

If you think this might be the case, you can invite questions in advance that are not necessarily attributed to anyone and you should lead the discussion with these questions. It’s fine to have answer “TBD” in the document if the question came in shortly before the meeting started and you didn’t have time to address it. By acknowledging that a question came in and that you can’t yet answer it, sets the right tone for the meeting: it is to flesh out questions around the product and not necessarily to answer them all right away.

As above, not everyone will be comfortable asking questions in a group meeting, and not everyone will have read the document in advance. So to ensure everyone is heard, invite questions following the meeting that can be sent to you directly.

This is less than ideal as you don’t get the chance for everyone to discuss questions that come in later by email, and it can drag things out. I personally avoid taking questions after meetings for this reason. So, if you do accept questions after the meeting, put a hard stop on when you will accept additional questions: end-of-day is probably is a good rule of thumb. If you feel someone has missed out, consider inviting them to a later meeting to give them another chance. Avoid discussion on email chains after meetings — they can get out of hand too easily.

If you have a messaging channel dedicated to the new product/feature, like a Slack channel, then that might be one venue where additional product discussions can take place in a forum that is transparent to all stakeholders. I keep a link to the current PR FAQ document as the “topic” of Slack Channels that are specific to products that are under design or in development. This seems successful, but it is a recent strategy that I have employed so it’s too soon for me to confidently talk about the pros and cons. One suggestion: only invite people to that Slack channel after their first PR FAQ review meeting, so you know that they have read the documents carefully and asked questions before they take part in Slack discussions.

This is more general advice for running good meetings: make sure to invite people to talk who would otherwise stay silent. Calling out a specific FAQ question that is someone’s domain of expertise is an effective way to get them talking on a subject that they are comfortable with, which can lead to their broader participation. You might want to seed the document with questions that you already know the answer to in someone’s domain of expertise, to allow you to ask that person what their thoughts are.

Take note if an expert in some area didn’t weight in, even after being prompted, and make sure to follow up with them individually and try to understand why they did not speak up.

It is easy for participants to map different product ideas onto an inherently under-specified wireframe or workflow diagram, instead of reading the actual product description. Design meetings are a separate set of meetings that can even be concurrent with PR FAQ review meetings. It is for this reason that Amazon tends not to have any visual designs in PR FAQ docs. As I recommend in Press Releases for Product Managers — Everything You Need to Know, limit any design elements to the FAQ, and make any design discussion about how the designs capture the PR FAQ itself. In other words, any design elements should provide context for the PR FAQ itself and not spur additional discussion. 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.

Surveys have shown that 40% of all technology managers will only skim a product document, no matter how long they have been given to read it.

The PR FAQ process isn’t going to save you from people skimming, but it has some nice built-in characteristics to stop these people from disrupting the process. Fortunately, a lot of skimmers will self-identify by impatiently saying that they have “finished” reading the PR FAQ faster than possible. The biggest problem is that this can pressure other people to start skimming or skipping sections to finish quickly. If you don’t want to call someone out directly about skimming or skipping parts of the document you can say something like “wow, you’re a faster reader, I’m still reading.” The “I am still reading” part is important, because it will prevent other people from starting to skim for fear that they are holding everyone up.

The FAQs are a great device for when people ask questions that you have already addressed. You can literally point them to that question already written in the FAQ. This is much easier than trying to explain how some wireframe already captures the question they were asking: it’s there in black and white. If their question is very different to any that you have so far, then it is probably a good one to add.

As with any kind of product development, you are going to be asked a question that more or less translates to “why isn’t this some other product?.” This is nothing particularly related to the PR FAQ processes: people will always use product meetings to champion some other product that they view as a higher priority or to get additional features into the current product.

The FAQs are a good place to address this in advance. You can have FAQs that asks “what will be in future versions of this product?” to help prevent scope-creep in this product. Your FAQ can also include the question “what are the related products?” with an answer that includes the related products and (if necessary) also answering that the roadmap is “TBD” to make it clear that this is not a Road Map meeting.

As you have probably gathered from this document, careful choice of FAQs are the solution to a lot of the troubles that you might encounter during the PR FAQ review process. The FAQ component of the document is extremely effective in capturing the assumptions of different stakeholders in a consistent format that all other stakeholders can understand.

As you develop more product documents, like UX Designs, API Specifications, user profiles, or any other document during the product development life-cycle, try to return to the PR FAQ to add any questions that arise during the process. A lot of important decisions will get buried in engineering tickets or chat interactions as your product progresses. Unless you have Product Management software that captures everything you need (please let me know if so) then it’s hard to think of a better format than Questions+Answers to encode all your decisions and assumptions. It is a non-confrontational style: like two friends asking questions and getting thoughtful answers.

Finally, you want your products shaped by as many people as possible. So for further reading, please check out:

Related posts:

It took me a while to find this one out, so I’m sharing this tip here with the hope that it might be useful for someone else as well. My problem was, how do I add some properties, like a validator or…

Michael Purcell is currently a SiS engineer in the internal sales department of Cisco Systems. He obtained his first CCIE qualification in Routing and Switching in September 1998, and then obtained…

A few weeks ago The Scale Factory released s3audit, a command line tool for auditing the settings of AWS S3 buckets. Since its release s3audit has garnered a modest amount of interest from the wider…