Reviewing a PRFAQ
There is a method to writing a PRFAQ, and there is a methodto reading a PRFAQ. If you read a PRFAQ with no preparation, you will still geta good deal of value from it. However, there are techniques for you to get andprovide even more value. This section is like a “standalone” chapter for anyonereading a PRFAQ to use and reference. It’s available at www.theprfaq.com/resourcesas a PDF for you to download and share with your team for free. You can also goto www.theprfaq.com/learnand read the PRFAQ 101 article that summarizes the framework.
A PRFAQ is a framework and a method to think, articulate, and inspire. It’s a visionand strategic decision-making tool. The process requires collaborators toreview it to get as close as possible to a viable, feasible, valuable, andusable solution to a customer problem. Review sessions are a part of thisiterative process of discovery and improvement.
Whenever you learn about giving feedback, it’s likelyrelated to giving feedback on a person’s performance or behavior. As far as Iremember, I have never been to a training, watched a video, or read a book oran article that offered concrete advice on providing feedback on businessdocuments or presentations. Have you? We get bombarded with people telling usto be constructive, but what does that mean exactly?
Most people giving feedback fall into one of two buckets: nofeedback, or superficial positive feedback. Yes, there will be the detractors,the detail-oriented, the cheerleaders, and every other stereotype. Still, mostpeople abstain from giving feedback because they would rather not be perceivedas negative, naïve, ignorant, incompetent, or pedantic. Another aggravation iswhen a senior executive or a manager is present. People either self-censor orput up a façade to sound smart and knowledgeable.
There is so much to cover on this topic that the world needsan entire book about it. In lieu of that, this chapter will get you started.
Before we discuss the tactical aspects of reviewing a PRFAQ,let’s briefly talk about seven behaviors and attitudes while giving feedbackthat go a long way in how others perceive you and your ability to influence.
Empathy &understanding: You must consider the goals, needs, and wants of everyoneinvolved in the project and everyone in the room with you. The customer is thehero of the story, but being sensitive to the people working on the project canbe the difference between you having your point heard or people starting toavoid seeking your input. Putting yourself in their shoes will help you beattuned to their needs and the process the PRFAQ owner is putting in place.Don't put your needs ahead of the group's, much less ahead of the customer's.
Positive attitude:This is not to be confused with positive feedback. Provide candid feedbackwhile being caring and showing that you are contributing to the pool ofmeaning. Framing feedback as positive or negative is not the right mindset. Allfeedback is a contribution to developing the idea. You still can be positivewhile pointing out issues and concerns.
Open-mindedness:We come with preconceived notions and associations. Start your review journeyfrom a perspective that you don’t know the truth the team is looking for, eventhough you have strong opinions.Instead of seeing things in terms of right and wrong or black-or-white,understand the shades of gray. For everything you take as an unquestionabletruth, there is an “it depends” somewhere. Start from that middle point, anddon’t lock yourself into a box early on. Just because something didn’t work inthe past, it doesn’t automatically mean that it can’t work in the future orunder different conditions.
Balance: Beingbalanced goes together with open-mindedness. It’s easy to tip the scale andbecome blinded by our desire to see this project through or to see it shelvedbecause you think it’s a waste of time or a lower priority. People would rathernot hear only what you agree with. They would rather not hear only what youdisagree with. They want to gather insightful data points to improve it. Eachpiece of feedback also carries a weight with it. Be clear if you think thefeedback that you are providing is just a small observation, a key point, or ifyou believe it to be critical.
Respect: Tone andlanguage can make or break your feedback. You may feel too excited and eager,as a parent telling their kid they are the most special child in the world. Youmay feel disillusioned and too harsh, using unprofessional language, ad hominemattacks (directly against a person rather than the message), or showing how“superior” you are. Neither of these extremes is good. Be professional andrespectful.
Authenticity:They are asking for your feedback because they want your feedback, not the feedback you think someone else will give.One of the least useful attitudes is to impersonate someone else (typically, anexecutive or a senior leader) and provide feedback as if you were them. It’salso not useful to attribute your thoughts and feelings as if they belong tosomeone else. This is called projectionin psychology. Be you, not someone else.
Appreciation:Result matter more than effort in business. However, you can’t have resultswithout putting in the hours. Result without effort is luck. Whoever ispresenting you with a document to review spent hours working on it, regardlessof how good the current version is. They will put more hours reflecting,researching, and revising it after you give them feedback. Acknowledge it.
I want you to think of each piece of feedback you areproviding as a gift, not a request. You are offering valuable insights to makethe PRFAQ, and the project, better.
Now, let’s get tactical and talk about what exactly you willlook for in a PRFAQ.
The five PRFAQ principles are: (1) customer-centric, (2)aspirational, (3) clear, concise, and coherent, (4) truth-seeking, and (5) astrategic decision-making tool. You are evaluating the PRFAQ to makesure it sticks to those principles.
As you read the document, you want to feel you understandthe customer, their needs, pain points, and desires. That must come out clearlyin the PR and the FAQ. You want to pay attention to the consistency across thedocument, making sure the customer and the problem are not changing from oneparagraph to another.
The aspirational part refers to something that projects afuture that’s worth having. You aim to feel that you understand the “so what”question. A well-described problem for a customer is the starting point; afeasible and viable solution that addresses that problem is the second piece.Finally, this aspiration needs to be inspiring to motivate those involved.
The three Cs of a good narrative are essential, and I’llexpand on them below.
Is the document a truth-seeking narrative, or is it a salespitch? The more precise language the document has, and the more disclaimersabout hypotheses and assumptions, the more it seeks the truth. The opposite ofthat is when the document has absolutes (“this is the only way”) or hyperboliclanguage (“the best, fastest, and only solution for our customers”) throughout.
Finally, you want to make sure the document is aboutstrategy and vision, not details of how to execute a plan. It’s fine to have alimited number of tactics and details because it’s too challenging to talkabout strategy in the abstract. You want to provide feedback if a paragraphfeels too detailed or unimportant at this level. It’s not unusual fortechnology details to slip through because people got excited about theimplementation. In a few cases, showing technical details matters because thefeasibility of a solution is in question, but generally, theyshould be left out.
You will be a strong collaborator by providing detailedfeedback to the PRFAQ owner via “offline” comments in the document about how toelevate the text without changing its meaning and without being pedantic aboutpreferences. If you are an Oxford-comma person, like I am, there is no value inproviding it as feedback regardless of how strongly you feel about it—unlessit’s feedback about consistency.
Here’s a list of issues that you can help the PRFAQ ownerwith:
· Grammar and typos
· Passive-voice sentences
· Language style and tone inconsistency
· Hard-to-read sentences
· Use of imprecise language where data exist (orit’s needed)—e.g., “many,” “few,” “some,” etc.
· Unexplained acronyms, abbreviations, or business jargon
· Assumptions or hypotheses presented as fact
· Sentences (or words) that don’t move the storyforward and they can cut
· Formatting inconsistency
Because the PRFAQ owner will have read and reread thisdocument many times, they end up being blind to many issues. Coherence mightalso suffer during editing. It’s possible that in FAQ number three, theyintroduced a concept, and it’s referenced in FAQ number nine. After rounds ofrevision, they removed the explanation of the concept or moved it to later inthe document. Now, readers might not understand what it means. Let them know.
In the realm of coherence, the PRFAQ author will create astory in their head and commit it to paper. In this process, they might missexplaining certain steps or key elements that bring the story together. Theyassume people know a situation is bad or good without calling it out, but youdon't know. They assume people are familiar with certain concepts, products, orbusinesses, even though many people might not be. It’s your job to let theauthor know you are not getting it. This type of feedback is often served inthe form of a question, such as “How do you go from X to Y?” or “What does Zmean?”
The Gap Checklist is a technique I developed for myself toread any business document or watch a business presentation, and it has servedme well. As soon as I have context about the topic, I quickly note the five toten items I expect the document or presentation to cover. I do this in thefirst three minutes of a presentation or after I read the headline of thedocument, but before bias kicks in. I consider this to be my checklist.
Once I read the entire document or the person delivers thepresentation, I go back to my checklist and see if they missed any of thoseitems. This technique alone has been responsible for countless times I receiveda note of appreciation from the PRFAQ owner or presenter. Most people onlyfocus on what’s being said and ignore what's not there.
Often, the PRFAQ owner isn't missing a whole topic, but theyhaven’t considered alternative approaches to what they are describing. Theydon’t know how something can be done, and you can ask them if they consideredan alternative solution; if not, let them know what it is. Take it offline andemail them afterward to describe the solution, the best use cases, and the prosor cons. The review is not a knowledge test, and you are not trying to checkevery detail and how they arrived at each aspect being described. However, ifyou are a domain expert, a technical expert, or have key knowledge they couldbenefit from, ask them what options they have considered.
This also speaks to the considerations that went into thePRFAQ. You really need to wear your functional hat. If you are a UX designer,be the UX designer. If you are a software engineer, be the software engineer.If you are a finance manager, be the finance manager. They invited you to be ina PRFAQ review because they and the team want you to pay attention to thetopics that relate to your competencies.
If you impersonate another role (the opposite of the“authenticity” described above), you are causing two problems. First, you don'thave the qualifications to speak about that topic with the authority of someonewho's an expert. Your title might even carry authority (e.g., Principal,Partner, Director) that gets confused with domain expertise, thus leading toyou providing feedback that might feel harmless, but it's not. Second, if youdon’t cover your area of expertise, who will? If you are a finance manager andprovide feedback in the UX, who’s providing feedback and asking clarifyingquestions in the financial model?
Once upon a time, someone, somewhere, brought a terrible(false) adage upon all of us: Don’t bring me problems; bring me solutions!Maybe I’m exaggerating by calling it terrible, but it’s not far from it. Theintent behind the phrase is to help people think and act proactively. The issueI see with it is that the person who discovers the problem might not be theperson who knows how to solve it.
In a PRFAQ and other business settings, you will find issuesor have concerns that you have no clue how to solve. Will you keep it toyourself or bring it up to the PRFAQ owner? The only correct answer is for youto tell them—assuming it’s relevant to the discussion at hand. You are notasking them what the solution is; you are offering them your perspective thatthere is an issue. You are agnostic to their decision to keep it as is, solveit, or ask someone else to go figure it out.
When do you provide feedback during a meeting, and when doyou wait to send your comments later? This is a key question reviewers askthemselves all the time. This is not particular to a PRFAQ, but any meeting youtake part in.
In a group setting, the value of providing real-timefeedback is so that other people hear it as well. This is useful if you providefeedback that others can build on, open doors of valuable discussions andconversations (e.g., new relevant information), or realign or reanchor the teamif there is a breakdown in values, vision, mission, strategy, or goals.
The flip side is “dead end,” less relevant, orpreference-based feedback. These are better served asynchronously after themeeting. Dead end means feedback that no one else will learn anything new fromit or be able to use it to build feedback or knowledge on top. That includesfeedback about grammar, language, style, formatting, etc. The relevancy offeedback is not necessarily how important the feedback is, but how relevant itis to the discussion in this meeting. You might find the PRFAQ contains a mistakeabout the AWS region currently being used by a service; however, you realizethat mistake will make no difference in the strategic discussion. Provide thatfeedback offline.
Finally, preferences are how you feel something should bedone, but it won’t have a material impact on the potential outcome of thisproject. Most UX feedback falls into this category. Branding and namingconventions also fall into this bucket. All of these are better discussedoffline. They might be important or even critical, but they won’t enhance thein-meeting discussions, and they can easily lead to distracting detours.
Key Takeaways
In this chapter, we covered the seven behaviors andattitudes that make your feedback more effective: empathy & understanding,positive attitude, open-mindedness, balance, respect, authenticity, andappreciation. We also covered the surface area of the feedback, which includesabiding by the five PRFAQ principles, watching for the PRFAQ blind spots andgaps, assessing whether the best option was considered, bringing your domainexpertise, and highlighting problems even if you don’t know the solution.
