Working Backwards: Creating Effective PR/FAQ Documents
Translating Technical Work for Product Teams
Much of the content I’ve been publishing on Practical Engineering Management oscillates around the idea that the Product and Technology departments should work closely to make an organization successful.
Recently, I wrote a series of articles discussing the Role of Engineering in Product Model Transformation:
Changing the way things are built (part I of the series),
Changing the way problems are solved (part II of the series),
Changing the way decisions are made about which problems to solve (part III of the series).
Today, I will share with you a simple practice of translating technical work into Business/Product value. Because what’s more powerful than speaking the same language?
Working Backwards - Press Release FAQ Document
“Working Backwards” is Amazon’s famous approach to building its product portfolio. In practice, this is a few pages-long document called a PR/FAQ (Press Release + FAQ), which is the starting point for product work. When the document is ready, Amazon’s teams hold meetings with all stakeholders, including engineering, product, marketing, architects, and others.
PR/FAQ document describes the day in the future when the product will be launched. Rather than focusing on the features or requirements here and now, this storytelling technique helps align all stakeholders with the desired product vision and its outcomes. It also aims to build a common understanding across different teams—product, tech, marketing, and others.
Many product organizations in the industry are adopting PR/FAQ, and here I want you to look at this technique not only from a product manager's perspective. In my experience, this document is an excellent way of explaining technical work to non-tech people.
This approach has helped me multiple times with adding engineering tasks to product roadmaps and building an understanding of the actual outcomes of such work for customers and the company.
PR/FAQ for Engineering Leaders
I recommend doing a simple exercise. Whenever you have an engineering task that doesn’t seem to have a clear correlation with product work, write a PR/FAQ for it, focusing on:
Describing the outcomes of such an initiative,
Clearly explaining to non-tech stakeholders what we want to achieve.
Here are a few initiatives from my past experience where I wrote PR/FAQ documents:
Moving CI/CD solutions from local servers to the cloud
Migrating a web app to micro frontends architecture
Building an in-house Design System solution
Implementing the foundation for observability practices (SLI/SLO definition, monitoring, and alerting)
Migrating an app from one language to another
Introducing QA-Shift Left to the organization
The PR/FAQ document helped me justify these projects to management and, most importantly, helped me better understand what my team(s) and I wanted to achieve. In my case, it usually takes at least a few days to write such a document.
It can be counterintuitive, but at the beginning, you are the main beneficiary of such a summary. It’s funny because, before you start writing, you are 100% certain about what has to be done. Once you begin, the number of times you question your idea grows indefinitely:
“Why do I even need this?”
“Is it really critical now? Can’t it wait?”
“What is the true problem I want to solve?”
“Am I doing this only to please engineers? Is it really worth it?”
“What’s the value of my work for customers or the organization?”
“Long weeks of time investment and only a few percent increase in productivity?”
Giving yourself enough time to address all of these doubts is priceless. It’s like allowing the idea to mature slightly before you share it with a broader group. Having it written “on paper” in the form of a PR/FAQ will also structure your idea into something more tangible, that can later be translated into clear outcomes or high-level design.
PR/FAQ Template
The template of the PR/FAQ document is inspired by Amazon’s original ”Working Backward” materials.
Here you can get this template as:
The Template
Heading: A single-sentence name of the product that is understandable by customers/stakeholders.
Subheading: A single-sentence description of customers and the benefits they’ll get from this work.
Summary paragraph: Up to 5 sentences summarizing the product and benefits. This should extend the heading and subheading in a way that gives stakeholders a basic understanding of the product/change we’re planning to introduce.
Problem paragraph: Up to 5 sentences describing the problem that your solution solves. Should be written from the customer’s perspective.
Solution paragraph: Up to 5 sentences describing how your product/change solves the customer’s problem.
Getting started: Up to 5 sentences describing how customers/stakeholders can start using your product or feature. You can provide links to documentation, source code, or other materials where users can get more information.
Quotes: At least two quotes (one internal, from someone within the company; one external, from a customer) describing the benefits they are getting from your product.
PR/FAQ Example
Here’s one example of a PR/FAQ document I used in my work.