Turn Idea into a Product the PRFAQ way


What is a PRFAQ?

  • Press Release & Frequently Asked Questions
  • It's one of the most used approaches for Amazon product managers to present ideas and get buy-ins. 
  • Working backward from when your product has made it to the headline
  • Written document

Press Release

How will customers/stakeholders see your product?

Example: 

David, a customer of XYZ software, speaks about the new service" "I have been waiting for a solution like this! It's a true one-stop shop for all my needs!"

FAQs

What are the most important questions and answers from customers/stakeholders? 

Examples:

  • What problem are you trying to solve?
  • What are the existing solutions to this problem and how does your product solve it better?
  • Who is your target customer?

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 and follows a very templated format.

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.


Template for a PR FAQ

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 give a summary of the product and the benefits. It 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 is 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 customers if you have multiple profiles of ideal customers, for 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.


PR FAQ Review Process

Getting the PR/FAQ written is only half of the challenge. Next, you’ll have to take it through a bandwidth-heavy, internal review process with your stakeholders and leadership team.

This review process takes place in (what Amazonians refer to as) a ‘Narrative’ meeting, where a group of stakeholders is invited to a 60 minutes session to read the PR/FAQ, then provide the Product Development team with high-quality feedback.

Comments

Post a Comment

Popular posts from this blog

Software Architecture Techniques - Part 6

Question 1: What is the 20-minute rule, and when is it best to apply it? Answer: The "20-minute rule" for software architects is a time management technique that encourages dedicating short, focused bursts of time (around 20 minutes) regularly to learn new technologies, tools, or industry trends. The goal is to increase the architect's technology width, which refers to broadening their knowledge and understanding of different technologies and practices beyond their current expertise. Here's how the 20-minute rule can be applied: Consistent Learning : Set aside at least 20 minutes each day or several times a week to engage in learning activities. This could include reading articles, watching videos, attending webinars, or exploring documentation related to new technologies or architectural concepts. Focused Approach : Use the 20-minute sessions to maintain focus and avoid distractions. Eliminate interruptions during this time and fully immerse yourself in the learning ...
Read more

Software Architecture Techniques - Part 2

Question 1: What are the two dimensions of the risk assessment matrix? Answer: The risk assessment matrix typically consists of two dimensions: Likelihood : This dimension assesses the probability or likelihood that a risk event will occur. It is often represented on a scale from low to high or with numerical values (e.g., 1 to 5, where 1 is low likelihood and 5 is high likelihood). The likelihood helps in understanding the chances of the risk event happening. Impact : This dimension evaluates the potential consequences or impact of the risk event if it occurs. It is also represented on a scale from low to high or with numerical values (e.g., 1 to 5, where 1 is low impact and 5 is high impact). The impact helps in understanding the severity of the risk if it materializes. By combining the likelihood and impact assessments, organizations can categorize risks into different levels of criticality, such as low, medium, and high risk. This information is valuable in prioritizing risk respon...
Read more

Software Architecture Techniques - Part 3

Question 1: What is irrational artifact attachment, and why is it significant with respect to documenting and diagramming architecture? Answer:  Irrational artifact attachment is a cognitive bias that occurs when individuals become overly attached to certain artifacts, such as documentation and diagrams, without considering their actual usefulness or relevance to the architecture or project. It refers to the tendency to treat artifacts as inherently valuable or important, even when they may not provide substantial benefits or are outdated. This bias can be significant with respect to documenting and diagramming architecture for several reasons: Misleading Focus : When individuals are irrationally attached to specific artifacts, they may focus on maintaining and updating those artifacts rather than on the actual architectural decisions and their impact on the project. This can lead to a misallocation of time and effort. Loss of Agility : Outdated or unnecessary artifacts can impede ...
Read more