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.
Review with every stakeholder
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.
Running a PR FAQ Meeting
For each meeting with the stakeholders you run the meeting as follows:
- Explain the product using your one sentence summary from your PR, or your one paragraph summary at most. You don’t want to start discussing the product before everyone has read the document, so keep the intro short.
- Explain the PR FAQ meeting process: “we will read the document and then ask questions after everyone has read it.” Unless you’re in an organization that has been using PR FAQs for a long time, it is best to start with an explanation.
- Share the sign-off criteria for the meeting and (ideally) which participant(s) will decide the meeting outcome.
- Inform the meeting participants on which other stakeholders have already been through this process. This will help them understand where some of the FAQ questions have come from, or why some types of FAQ questions are missing. For example, if you haven’t met with any technical stakeholders yet, that would explain why there are not yet any FAQ questions that are technical.
- (Optional) Tell people if there are any specific types of feedback that you want. You generally want people to react to the product document as a whole and not try to guide them too much. But if you have people in the meeting who tend to pull discussions off track, then requesting specific types of feedback can help keep the discussion on point (see also my related article on Driving Diverse Product Feedback at your Company).
- Everyone silently reads the document for the first 10–30 minutes of the meeting. Yes, this silence feels really weird the first few times, but you get used to it.
- Open for questions: ask for clarification questions about the PR; and general questions about the product/feature that will end up in one of your FAQs. As the PM, you should record all of them and either answer them on the spot or simply acknowledge that you will add that to the FAQ and get that answered later.
- Decide on whether to move to the next stage. If it’s engineering focused, do engineering have enough information to start building technical specifications? If it’s sales focused, do your salespeople have enough information that they can explain this product/feature to customers? If it’s an executive review, are you okay to begin development of the product/feature?
Deciding on next steps following a PR FAQ review
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:
- A hard “yes”. Everyone understands the PR FAQ and liked the product idea and only had minor or clarifying questions. You should move to the next review meeting, updating the document to address any questions that came up.
- A soft “yes”. Maybe you couldn’t immediately answer some questions about important parts of the product and have to complete some extra research after the end of the meeting. After you later answer them, you will have to decide whether the answers to these questions are major enough to warrant further meetings with the same stakeholders or to move on.
- A soft “no”. The stakeholder might ask for questions to be answered before they are prepared to move on. Take the time to answer these questions thoroughly, and make sure you are separating questions about the product itself from questions about the product roadmap. The most common reason I’ve seen for a soft “no” is that someone thought this product should not be a priority. Defining a product is separate from deciding where it goes on the roadmap, so make sure you have this clear (see below for tactics on this).
- A hard “no”. Sadly, sometimes you can’t build a product that people are excited about or which simply isn’t possible due to technical barriers, regulatory restrictions, or other factors that you can’t control. If so, make sure that you let everyone know who has contributed so far, and be transparent about why, eg: “interesting idea but not a priority at this time.”
8 Tactics for optimizing the PR FAQ review process
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.
1. Don’t skip reading the document at the start of the meeting
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.
2. Take time to update the PR/FAQ after each meeting
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.
3. Give people the option to ask you questions in advance
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.
4. Give people the option to send questions after the meeting
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.
5. Ask people to comment on specific FAQ questions & answers
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.
6. Don’t let design elements become the focus of the conversation
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.
7. Call out people who have skimmed and not read the document
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.
8. Keep the scope clear with FAQs about versions and related products
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.
Conclusion: FAQs are your friend
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:
Acknowledgements:
Thank you to seasoned Product expert, Greg Chang, for detailed feedback on this article.
