Using the PRFAQ for Technical Projects
Leaders' Stories: Marcelo Calbucci on Translating Tech Work Into Product Value
The IT industry is evolving at a breakneck pace. With the rise of AI tools, coding skills alone aren’t enough anymore. There’s a growing push to boost productivity and optimize how engineers work. Today’s engineering managers are expected to be more hands-on and engineering teams must focus less on inputs (number of developed features) and more on the outcomes they deliver.
I’m excited about the shift toward product-minded engineering. Throughout my career, I’ve always been drawn to how customers use my code and their overall experience. For me, customer-centricity has always taken precedence over pure technical excellence, algorithms, or computer science theory (for good and bad).
Despite my focus on working closely with the product side, finding common ground among engineers, product managers, business stakeholders, and other non-technical collaborators was often challenging.
Working Backwards and PR-FAQ
Amazon’s “Working Backwards” approach, brought to life by a document called the PRFAQ (Press Release + FAQ), is a particularly powerful tool for translating technical work into business or product value.
By describing a future day when the product is launched, this storytelling technique aligns all stakeholders on a shared product vision and outcomes.
One of my biggest successes with PRFAQ was getting buy-in for a micro-frontends infrastructure. I covered that in: Working Backwards: Creating Effective PR/FAQ Documents. However, I must admit that I’ve only scratched the surface of this framework and haven’t explored all its nuances.
Fortunately, I crossed paths with Marcelo Calbucci, Amazon's Director of Product and Tech, multi-time CTO, and now Founder and Author of The PRFAQ Framework. I asked Marcelo to share his expertise with you, the readers of Practical Engineering Management.
I’m delighted to present his insights here.
Marcelo is also offering the first 20 readers of Practical Engineering Management a 20% discount on the PDF version of his book when you use the code PEM20 at checkout.
Enjoy the story below!
Guest post by Marcelo Calbucci:
Using the PRFAQ for Technical Projects
Over a decade ago, I divided the work that software engineers do into two buckets: user stories and system stories. User stories are the work that affects customers or other stakeholders (customer service, sales, accounts receivable, etc.). System stories are the work that software engineers do for “themselves” to improve the maintainability, extensibility, or operations of the software and its infrastructure. It's not a perfect definition or delineation, since an unreliable service will affect customers and work for “themselves” translates into future returns for the business. Inspired by how operating systems ensure that even low priority threads have CPU allocation to avoid “starvation,” I stipulated that, in each quarter, product managers allocate resources for system stories even when there is a large backlog of crucial customer features.
However, when the system stories were complex (multi-sprint), it was harder to justify the work and have clarity if we should or should not take it. These were: large technical debts, re-platforming (changing cloud providers, replacing frameworks, stacks, or vendors), re-architecting, revamping CI/CD pipeline, database stack migration, dev tooling, etc.
There is also an intuition element at play here. If we do this system story, it'll cost us X, but it'll save us Y over the next N years. The savings are financial (such as a reduction in cloud, vendors, or operational costs) or in software development efficiency.
The hard part was converting those statements based on “gut feelings” into facts (with data), and even harder getting buy-in from leaders, product managers, and other stakeholders. No one wants to hear the feature they want to announce next quarter won't be available because the engineering team believes there is an important system story to work on–that won't have any discernible impact over the next six to twelve months!
This is where tech leaders borrow a page from the product strategy book and use the Press Release and Frequently Asked Questions (PRFAQ) to discover, debate, and decide on a vision and a strategy for dealing with large system stories.
The Engineering <> Stakeholder Gap
It's not uncommon to hear leaders talking about the need to “translate engineering” so others understand it. Yes, you can do that, but as someone who's been an engineer, a CTO and a CPO for a long time, I'm convinced there is a better way.
Here is the issue: it's difficult to educate other functions in the intricacies of what a software engineer does. This is true for all functions. It's difficult for someone in the finance department to educate non-finance people on the rules of asset depreciation and tax exemptions. Educating someone on how software engineers work and what exactly they do is time consuming. It's more than time consuming, though. Others will know enough to believe they can make decisions on behalf of engineers, but they won't ever understand the nuances of the work. Over time, the engineering organization will feel unempowered and a loss of autonomy. I'm not advocating for hiding what a software engineer does from the rest of the organization. Being transparent and sharing information leads to trust and better collaboration. I'm saying that going into the details of the work to explain why something should be done is not optimum.
A better solution is not to talk about the “what” but to focus on the “why.” Instead of talking about the plan, the features, the architecture, the APIs, the tooling, or whatever other technical element, keep the conversation at the strategy level. So, how do you do that?
Using PRFAQ
I describe a PRFAQ as a system to discover, debate, and decide on a vision and a strategy for a product, program, service, or any type of innovation. In this context, innovation also means work on system stories, such as a re-architecture, replacing a framework, rebuilding a service, or anything in the “middle” of the product that will have no impact for the customers or stakeholders. Here is a PRFAQ Example (part of the book) for an internal tech project.
A PRFAQ is an excellent tool if the amount of work you are investing will take a couple of months or more. If less than that, you might still do a mini-PRFAQ, but the full framework is too much. That's because a PRFAQ takes a week or two to complete and the overhead will be too high for a short length project. The exception is a project where the risk and/or potential impact to the business is high, even though the effort is not. In that case, it's worth using the PRFAQ.
In a PRFAQ, you paint a vision of the future as a press release. For internal projects, you may replace the press release with an email or blog post. You write these as if the team has done the work, and the future is already here.
In a product or business PRFAQ, you have a “Customer FAQs” section that's unnecessary when using the framework for an internal software project. What you have is a robust Internal FAQs section. The internal FAQs section will focus on three aspects:
What problem are we solving? Why and why now?
What is the proposed solution, its budget, and risks?
How do we go from the existing state to the new state of things?
The difference between a PRFAQ and a technical requirement document, an architecture design, or any artifact the team uses to describe the work, is that a PRFAQ is a vision and a strategy. It does not include a plan, a list of work items, a roadmap, or even a diagram. That's left for other documents. What that does is to allow the stakeholders to read and contribute to this document, since they don't have to understand the low-level technical details.
The point is to get a green light for the project within the boundaries of the vision and strategy as described. The team must put a stake on the ground and set a budget (resources), a timeline, and a scope for the project. These will dictate the boundaries of the strategy, such as what matters and what doesn't matter in this project.
The Benefits of PRFAQ for System Stories
There are several benefits of using the PRFAQ Framework for system stories. Here are five that I consider the important:
#1–Improved clarity and alignment
By forcing tech teams to articulate a vision and a strategy, it helps them to think critically about what is the exact problem they are solving and why. They will need to answer the question: why is this problem worth solving it now? This will drive the team to understand the severity, impact, and urgency of the problem. You shouldn't be surprised if teams decide to postpone the PRFAQ because they can't find the clarity to explain it. That's the PRFAQ method at work! Once the team finds clarity, it aligns them with their understanding of the problem (and the solution). That will pay off later with fewer meetings, emails, and Slack messages to “clarify” and “re-align.”
#2—Focused decision-making
Writing the PRFAQ encourages the team to focus on what matters most. The format and length of the document constrains what's included. This process highlights where decisions need to be made and what we will leave out of the document, because from a strategic perspective is not relevant. It also helps avoid scope creep or never-ending projects (you are committing to a launch date).
#3—Built-in buy-in
Different from other systems, the PRFAQ is more than an artifact. It's a system that requires engagement with stakeholders, peers, and leaders. The person responsible for the PRFAQ is not going into a cave and coming out with a proposal they will “pitch” to everyone to get buy-in. They will write a draft, and conduct review sessions to refine the strategy, listen to feedback, reflect on it, and incorporate it into a better version of the document. Once a decision is ready to be made, everyone who needs to buy-in already contributed their share.
#4—Better business justification
Often, technical projects require a companion business justification document to convince people why this works matter. With a PRFAQ, you don't need any supplemental content. The PRFAQ has the vision and strategy, that includes the reason to do (and the reasons not to do) this project now, and what happens if the team doesn't do it (Cost of Delay).
#5—Focus on outcomes
This is the biggest benefit for engineering teams. They adopt a language of outcomes instead of outputs (activities) or inputs (efforts). Once the team shifts their mindset from what we do to why we do it (for the customers and stakeholders), decisions will improve, even the ones that don't use PRFAQ.
Getting Started
There are three pieces to use the PRFAQ effectively: 1) PRFAQ template, 2) Precise Writing, and 3) The PRFAQ method. You may download a template directly from the book's website. I didn't talk about Precise Writing here, but this is one area engineers will grasp and appreciate. It's a way of writing that removes ambiguity and calls out assumptions and hypotheses. The PRFAQ method defines how to write your PRFAQ draft, conduct review sessions (and effectively provide feedback), and use the PRFAQ to make decisions.
Mirek’s Note
I’m grateful to Marcelo for sharing his insights on the PRFAQ approach. Personally, I put this concept into practice when working on big blocks of tech projects (tech debt, re-architecting, or any other tech-stack-related pieces). For me, it’s one of the effective ways to ensure that important work will land in the company’s backlog with appropriate priority.
Share Your Story
I also invite you to share your story on Practical Engineering Management. While there’s no shortage of theories or “best practices,” nothing beats real-life experience in the demanding world of software engineering leadership.
If you’d like to reach thousands of engineering leaders worldwide, I’d love to hear from you. Drop me a note here on Substack or via mirek@practicalengineering.management.
I’m more than happy to help you polish your final piece so we can share it with our growing community of tech leaders.
 | A guest post by
|