#218 - The PRFAQ Framework: Amazon's Secret to Successful Innovations - Marcelo Calbucci

The PRPQ stands for press release and frequently asked questions. Press release is not really a marketing tool. It is a tool to describe a vision. So you write a press release as if the future was already here. Work at Microsoft for seven years, and for 18 years I founded and work on many startups, and three years ago I joined Amazon. I really fell in love with this PRFAQ framework, so when I left Amazon I decided to write a book about it.

What are the some important stuffs the main sections of PRFAQ, the PR? FAQ is a written document. It's 6 pages long and it has three sections, the press release, the customer FAQs, and then you have internal FAQs. As long as you write using this formula, you're going to get a lot of results. And a lot of people feel uncomfortable saying I'm not a good writer so I can't write 1. And I understand that, but it's not true because most people can write APRFAQ. You don't need to be a good

writer to get started. You just need to get started to get started. What are some of the common mistakes or anti patterns that you see people whenever they adopting PRFAQ? The first one is really being #2 mistake is. It's kind of silly, but people think of PRFAQ as a. Hello everyone, welcome to a new podcast episode. So today I have with me Marcelo Calbucci. He's the author of the book titled The PR FAQ Framework. Maybe some of you have heard about that, maybe some of you don't.

But this framework is popularized or maybe more like come from Amazon, right? So not many people probably have heard about that because, yeah, it's something that is still kind of like picking up in terms of adoption. So Marcelo today will tell us what is PRFAQ, why it is so powerful inside Amazon, and maybe how can we use that to, you know, start in our work? So, Marcelo, welcome to the show. Thank you for having me, Henry.

Right, Marcelo, in the beginning, I always love to invite my guests to maybe share a little bit more from your career. Any turning points that you think we all can learn from you? Yeah, sure. I started early on when I was a teenager, writing software, first for myself, then for my family. Then it became a business and I went to university to study computer science. Shortly after graduating, Microsoft went to Brazil to recruit software engineers who come to the US work for the company.

So I end up here in Seattle and work at Microsoft for seven years. Most of the time there I work at Bing. So going to Microsoft was definitely a big shift to my career. I also leaving Microsoft was a big shift to my career because I became the founder and for 18 years I founded and work on many startups and startup studios both in the US and in the UK. And three years ago, I joined Amazon, which is the opposite of a startup, if you will, a company with more than 1.5

million employees. So it's massive. And as soon as I joined Amazon, I really fell in love with this PRFAQ framework that they invented to discuss strategy and vision. And I really felt that it was going to be, it is going to be useful for founders and product leaders and tech leaders everywhere. So when I left Amazon, I decided to write a book about it. Wrote a book and published just a couple months ago. And here am I talking to you about this. Wow. So I think it's very

interesting. You have been in some big tech companies, Microsoft and Amazon, right? And you have gone to, you know, entrepreneurship yourself, you know, founding companies over companies, 18 years, that's pretty long time. And I'm sure because of that experience, you understand the power of these kind of framework in such a big tech companies, right?

So PRFAQ framework maybe in a gist, tell us what is it all about or what it is actually? Is it like a product management tool? Is it a project management tool or maybe something else? The PRFAQ is an innovation tool and it stands for Press Release and Frequently Asked Questions. And the press release is not really a marketing tool. It is a tool to describe a vision. So you write a press release as if the future was already here.

So people reading this document can paint this vision and understand what they're trying to do. And it's a six page document that has a specific way to write. And there was a specific method on how you create and how you use it as well. So this combined makes up the PRFAQ system, if you will.

It was invented by Amazon 20 years ago and it's used for all kinds of innovations, not only product, but at Amazon it was used for new businesses, policies, process changes to add a new service, a program for customers or internal program from ITHR or finance, all kinds of innovations that can be, you know, explained the form of a vision and strategy.

So the way I like to say to simplify is that the PFAQ is a tool for you to discover, debate and decide on a vision and a strategy for any kind of innovation.

Well, very interesting, you know, description about PRFAQ, right? I think I remember the first time I saw it, I don't know how many years ago. It is kind of like different than, you know, typical artifacts we create for you know, I don't know like creating innovations, creating product or business process and things like that. One thing that you mentioned is about, you know, vision, right? That's a forward-looking as if

it already happens today. So why should we think in terms of future as if it is already happening today? So what's the power in this kind of explanation so? The PRPQ we start from the outcome, right like you want to describe what is the opportunity that you are pursuing in terms of the benefits for the customer and for your business.

So you paint a vision the future of we launched this product and customer are using and they are extracting this benefit and this value from the product and the business is generating this benefit and this value for itself. So we start from that point on and then you work backwards to define the strategy and what you need to make that a reality.

And part of the PRFEQ is also to describe very clearly and succinctly what are the problem that you're trying to solve, Who is the customer, What is the solution? How are customers dealing with that problem today? How are they going to find all those elements that are very important to discuss before you start building or doing anything

right? In a world of like, people that are hungry to make things happen, they just jump and start executing without answering some fundamental questions about like, what exactly are we trying to do here? Wow. So I think yes, so many techies including myself, sometimes we are so excited about the idea and we just jump into implementation building and share it later and think about, I don't know, all the different details and outcomes. So building sometimes it can be

a very painful mistakes, right? So I think the most important thing is to think about the outcome first.

So you mentioned something about working backwards. So I think it is also very popular methodology from Amazon. Is PRFAQ part of Working backwards framework or is there anything working in synergy with other methodologies in Amazon? Working backwards is a practice within Amazon, right? It's almost like a philosophy within Amazon. PRFEQ is a manifestation of that. It is very specific, right? There is a six page document.

There is very specific way that you format and style this document, specific ways that you write the content of the document and how you use it. So you can think of PRFEQ as the concrete version of working backwards. Working backwards as a philosophy really means understanding your customer and what you're trying to achieve, and working backwards from that. PRFAQ is one way of doing that.

So you mentioned you have seen the power of this framework and you fell in love with it. Why writing a book about it? So is there something that you want to teach to the people outside of the, you know, Amazon? I think the important thing is to imagine like what is the world without the PRFAQ? And one of the problems that we

have without the PRFAQ. So what you often have is either people that come up with a solution for something and start building immediately without questioning or like aligning people around them or forcing alignment in a way that is not natural. Or you have people that create like Google Slides and presentations, right? And try to tell the story of a vision and a strategy.

And that is always a weak way of presenting a vision strategy because you know, when you're doing a presentation, sometimes the charisma of the person or the enthusiasm of the person clouds people vision of like what this should really be, right? And challenge people in terms of authority or seniority that they don't feel comfortable challenging. So you have to be careful with those systems of creating new things, right?

The PRPQ avoids all this because first is a written document, and when you're writing, you really think very deeply about what you're writing. So it's not unusual for you to start writing something and pause and realize, oh, wait a second, I actually don't understand this well enough. Let me go do some more in understanding of the problem or the solution or the technology or the market or the customer or whatever I need to understand so that I can write a paragraph

about it, right? That is very useful. You don't need that when you do PowerPoint, you just put a statement on a PowerPoint and like hope for the best to writing is a form of thinking, if you will. The other aspect of that is as you write this, you become really good at articulating an idea because your brain like absorbs and recalled information much better.

Not only that, but the people reading it are able to provide much richer feedback on what you're doing right versus trying to interrupt you while you're giving a presentation using slides or whatever, right, or a diagram or anything else. So it helps both sides of the equation, the people coming up with the idea and the people and the people providing feedback on

that idea as well. There is one more element, which is often we create PRDS or many artifacts as a way to sell it or to get buy in from people into that. PRPQ is the opposite of that. You're pulling people into collaborating with Theo to create this document because you're not the expert on everything and you're going to need many different sides and many different angles to look at this document and help you fill the gaps on what you don't

really understand. Well, I think that's the first very visible distinction, right? So, so many people, I'm also trained in the industry, you know, seeing people presenting new ideas by using slides, you know, PowerPoint, Google Slides, whatever that is, right? And it depends on the presenter or maybe the, I don't know, the product owner or the owner of the initiative to actually explain what it is all about.

And yeah, I mean, we share the slides, but some people might have different interpretation, right? Because slides typically maybe full of visuals and short text, right? I think the first key distinction I can see is that the PRFAQ is a written document. You've mentioned 6 pages long. So that means it's kind of like full of narration, right? So people can follow the thought process or maybe there are certain aspects that we will cover shortly. So I think thanks for pointing

that. So one thing also, it seems like

not many people adopted like other, you know, big tech giants framework things like OK, R or maybe PRD or maybe, I don't know, MVP canvas and all that. So why is it not the case for PRFAQ? Yeah. So I love that you mentioned OK R, right. OK R is somewhat new. Like it's not that old. If you think about it, companies really started adopting OK Rs over the last 10 years or so, even less than that. But OK Rs have been around for more than 20 years. Like Intel invented OK Rs in the 90s, right.

And Google's to adopted OK Rs in 98 when it was formed. So we took into 2015 or so for people to really start adopting it, and that was because of some people putting YouTube videos, some people writing books about it, more people writing articles, people learning about it and like just adopting the

framework. I think PRFAQ has been behind because there hasn't been enough content out there or explanations out there of what it is, when to use it, how to use it, and what not to use it for, right? So this is just the beginning of the PRPQ journey. If you look for PRPQ content, most of the content has been published in the last 2-3 years and you know it's picking up steam, It's slow and it's going to take time.

But the other aspect of it is PRPQ is a written document and a lot of people feel uncomfortable saying I'm not a good writer so I can't write 1. And I understand that, but it's not true because most people can write APRFEQ. There is a formula to write a PRFEQ, right? As long as you write using this formula, you're going to get a level of result you can get better at. You can be really good at it, but you don't need to be a good writer to get started. You just need to get started to

get started. And the first few times that you do, it is probably not going to be great. So take your time to learn how to do it. The other resistance that I seen on people not adopting PRPQ is that they believe people are not going to want to read it. And that is true if you live in an environment of PowerPoint and people don't want to read anything.

But once they start seeing the value of reading or the pre reading of PRPQ before discussing a meeting, they start to realize oh this is very valuable actually because everyone is talking about the same thing. Versus you know three people in a meeting been discussing one topic with the 4th person not realize that they miss an important e-mail or a previous meeting and being completely lost. Right? The PRFAQ elevates everyone to the same context.

Yeah. So thanks for mentioning some of the common resistances that people might have in terms of PRFAQ. Sometimes I think, I don't know, I, I used to work in a startup world, you know, many people have this bias for action, right? They just want to execute, execute, execute. Maybe, I don't know, the leaders have a bright idea in their mind, right? And they just want to execute it and, you know, fill in the blanks, so to speak, for the

other people. So I think writing a document, first of all, some people might think, oh, I need to spend some more time to write it. Or for readers, they also need to spend more time to read about it. So what is your take about this, right? For people who are still thinking that maybe doing the action and speed of execution matters most, than you know, writing these kind of stuff list.

That's a great question. You know, what you have to look at is the total length of a project, not any single activity, right? And not only the total length of the project, the impact and the result of the project for the business. So who cares if you ship something really fast, but like your users didn't care, it didn't deliver any value to your business, maybe even created more risk for your business, right? That's not a good outcome at all.

So what I say about the PRFAQ is, yes, it takes a week or two for a normal size project to write and use the PRFAQ. What that going to do is, is going to reduce more than the amount invested, the total length of the project, because there was going to be fewer misalignment, fewer needs for coordination. People are going to be able to make decisions independently because they understand the vision and the strategy without having to sync all the time.

There's going to be fewer emails going around, so the project is going to move faster with a PRFEQ, even though in the beginning is going to feel like this is slow. Let's stop this. Let's just start building. But you've been there, like all of us have been to projects that were like nightmarish like that. No one agrees. Like what exactly are we doing? Why we're doing, why we're doing this way? So the PRTQ avoids a lot of that. It doesn't eliminate.

It's important to say that there is no guarantee that a project is going to be successful, but it reduces the chance of failure, at least on the most basic cases.

So I think we have built people's anticipation to learn about this PRFAQ. So let's dive deep into what is PRFAQ like you mentioned, right? It's not just like some, you know, 6 page long document that people can just write in any kind of a way. So I think there's a certain methodology, there's a certain constraints actually that is being put in as part of the framework. So maybe let's start, you know what are the some important stuffs the main sections of PRFAQ so that we can actually

understand it better. So let's start with the document artifact, right? Or the PRFQ template. That's how it's called by some people. It's 6 pages long, and it has three sections. The first section is the press release, which is the first page. The second section is the customer FAQs, which is the second page. And then you have 4 pages of internal FAQs, and the first two sections, the press release and the customer FAQs. You write as if the future is already here, right?

You're right in the present tense, as if the product or the program or the business already exists. So you're painting a picture of a future state that you wish it was true. And before internal FAQ pages, you write in the present tense with the knowledge that you have today, just like you would write any kind of business document, right? And you really describe several elements of the idea, which is the problem, the solution, the go to market, the risks, the mitigations, the feasibility

aspects of this innovation. Like do you need some data? Do you need some APIs? Do you need some technology to be tested? The viability, which is the financial aspect, the cost, the operational, the maintenance, it's all part of the viability. You also talk about the volume, which is very important, right? Like you want to create something that is of value for a customer and a value for your business. So you have to make sure that it is 2 things are coming together nicely.

It can be just something that is great for the customer, but they're for the business or great for the business and terrible for the customer. So that all gets included in the internal FAQ. You have also an optional appendix. In the appendix you might include a few elements like financial modeling, wireframes, or a diagram or some user research that you've done. But you have to be very careful because these things are magnets

for discussions, right? And what you really want people discussing is the first 6 pages, which represents the vision and the strategy, not the tactics or the plan.

So after you mentioned all of this, right, it seems like it covers a lot of ground, right? So in terms of, you know, the customer, the problem, right, the value, the feasibility, the financial aspect and things like that, right? Although there are main sections that are kind of like advocated, right, the PR, right, the press release and then the customer FAQ and then the internal FAQ with the optional appendix. So it seems like it covers a lot, 6 page.

How to fit all of them in? You know, such A to me, such a short document for covering a lot of grounds. Yeah, 6 pages is ideal because it takes a person usually 20 minutes to read 6 pages. And what happens is if you have a one hour meeting, you can ask everyone to read the six pages during the 1st 20 minutes, and then you have 40 minutes to debate and to discuss and to the site. And that's a very powerful formula.

It's a good combo. So if you do it shorter, you're probably not going to be able to capture everything that you want. If you do it longer, then you become sloppy, right? You might decide to include too much information. The clicks page put a constraint on what you write so that you're really focusing on what matter for that conversation. What I say is the PRPQ is a tool for you to decide if you should do a project or not. So it's what you do before they one of the project, right?

And for that to be a good conversation, you should not be talking about the details. You should be talking about the big picture. The details is whence you start a project, when the project gets funding or green lighted to go ahead and start, right? And then you can do the full planning of the tactics and the dates and the road map and everything else. But the PRVQ really should be focused on the high level elements of vision and strategy and you focus on that. So you can fit that in six

pages. It's possible. I've done many times. I've seen many PRVQS that do that. Sometimes it's, it's hard. And then you have to decide what to cut, right. What is not important for us to be deciding right now that would not have an impact in our ability to decide or not to do this project? Right, thanks for clarifying the emphasis, right? It's actually to make decision, right? To do the, you know, decision

making. So it should cover just the high level thing, not the Super detail stuff, because otherwise 6 page won't fit. And I think there's another

powerful thing that I also learned when reading the book, right? This thing called the precise writing. So for you to actually, you know, write in a short, concise manner, definitely they are techniques, right? So I think in your book you mentioned this thing called precise writing, which I think is kind of like the adopted way of writing in Amazon. So tell us what is precise writing? Because I really think this is 1 powerful thing that anyone can do in terms of improving their writing.

Yes, I agree with you. It's it's very important. It's not only applicable to PRFQ. Even if you write emails or Slack messages or PRDS or any other kind of document, you should be using precise writing, full stop. It's that important. So let's define precisely in writing and what is not, right? So there is two other types of writing that you can imagine. 1 is that marketing, sales language, way of writing. We are the best, we're going to build the fastest.

And everything feels like very abstract, like not very specific. And when you read content like that, at the end, you feel like, I think I understand, but I'm not sure if I understand or not. And like, I'm not sure I believe it or not. So end up being in that world. The other extreme is technical writing, right?

So when you read those white papers and like explaining very details of the technology, but it misses the point of like the story of the user and how this is good for them and how they're going to interact with it and why this is going to be valuable for the business as well. So precise writing is what happens in between. So you use the right elements of data with the right elements of storytelling and you combine that in a way of writing that people can resonate with.

They can understand what they are talking about. South in the book, for example, I give an example of solar panels. You can talk about solar panels in a very scientific way, right? The how many watts per hour they can generate per square meter of surface area depending on the latitude of the house, yada, yada. That's very scientific, very specific and technical, right?

Or you can write like solar panels are great for the environment and they are wonderful and everyone wants to buy one and like, yeah, OK, like help me make business decisions here, right? The precise writing is in the middle is when you explain the impact of solar power in the livelihood of someone, right? How much money are they going to save on their house? How much is going to cost for them? How much energy they can create out of their monthly expend from solar powers?

Like that's, that's the middle point, right? And in the book I have a whole chapter dedicated to precise writing so people can grasp what it is. The other aspect of precise writing that is very important is to make things clear. So you avoid abbreviations, the jargons. You explain concepts in simple terms. You make it concise because very long sentences are very hard for people to read.

So you eliminate all the redundancy on the sentences to make it really really concise and clear for people to read. Yeah. So I think people should learn about this precise writing because just through the examples you mentioned in the book, right, you know, the paragraphs, the sentences, I can really see the power of if people try to adopt it in their writing, it will be more powerful. So things like, yeah, remove fluffy words, remove weak terms, those kind of stuff.

And also use something that is more specific, like what you mentioned, right? Not something like, OK, this thing is the coolest thing ever. Like how cool, How do you describe the cool thing, right. So I think those kind of things definitely is part of the precise writing that should be adopted in PRFAQ, right? And the other thing is, I think

because of all these so-called methodologies and maybe I don't know like the way that you write the PRFAQ, right, it has to be following a certain, if not to say strict guidelines. So why is such a strict way of writing the document right? Is it something for consistency standardization or is it something else? Yeah, like I said, it's for consistency, right, because you are helping the reader.

If your organization is going to adopt PRV kiln, people are going to feel more comfortable if from document to document, it follows the same pattern, right, in the same style of writing. And that helps you consume the information fast. So you can imagine like someone that has a artifact on their organization that has a template at the top that describe, I don't know, cost and timeline and everything.

And like every document that they use has that thing plate on the top that makes it easier for anyone in that organization to see one of those documents and find exactly what they're looking for. So part of the structure of the PRFEQ is to help you with that, right? Like how can I absorb the information correctly and fast so I can help provide feedback and make decisions?

Totally makes sense, right? So I think standardization, because I've read so many documents as well, and if different authors write differently in a different kind of structure, I think it's gonna be quite difficult to actually compare one against the other. That's the first thing. And second thing is we always have to switch the context in our mind how to interpret a document that you read.

So I think it's really powerful structure. So that's why I think I understand why it has these three main sections, the PR press release, the customer FAQ, and the Internet FAQ. Let's maybe dive into each of them. The press release, are you referring press release something like, you know, we see in all these TechCrunch blocks or maybe in the news whenever people, you know, release something, they want to do. This press release, is it actually the same?

It is the same, but it's not. So it is the same in the context that it should read like a press release that you would send to the press. However, on the PRFEQ, the press release has a very specific structure as well. It has seven paragraphs that you're writing in a very specific way. So it makes it easy for even someone who never wrote a PRFEQA press release to write a press release. And it tells the story started

from the problem. The solution includes some fictional quotes from the team and fictional quotes from the customer, includes an explanation of how to get started, includes an explanation or how it works, all very briefly, right? So what I say is the press release is to prime everyone reading the document on what's to come. So when you start reading the rest of the document, you are ready in a state of mind that you say like, oh, I know what we're talking about.

So you start evaluating each of the FAQ section in a better state. The other thing that I was going to say about the press release is that is not a marketing tool. And I mentioned that in the beginning of the podcast. You never going to send this to the press ever. It's a confidential product document or a business document. So you keep within the organization. So you're happy to write whatever you think it's

important to tell that story. Yeah, I think it's important not to leak this because otherwise people will think you are releasing something concrete, right? So what you mentioned about press release, right, as if like you're sending it to the press. I think every time I read this press release, that's the this definite structure that you just mentioned, right? So a company is releasing something, there's a problem, right? And there are quotes as well. Why do you think that this kind

of powerful structure, right? Like people are using it all the time to do press release? Why including all these aspects in a press release, actually? To write the book, I spent some time studying press releases and where it came from and why it

became so powerful. The interesting thing about press release is that it's a standard document or a standard format adopted by the press and by comms team, marketing communication team within organizations, so they can quickly share information with each other, right?

So if I want to tell a story of a crisis of a new product launch or a a new hire in my organization and I send a press release to a journalist, like I'm putting in a format, the journalists know how to consume really quickly because it's going to contain all the key informations that a journalist needs. So that's why Amazon adopted as well, why we invented something that already was very powerful in a way to capture stories about a new product or a new business or a change. Yeah.

So indeed, it's really powerful after I read it in your chapter, right? So I think why it all makes sense that adopting press release kind of structure way of writing. And I think one key aspect about this PR is as well the narration, right? So the storytelling aspect of it. So tell us why we have to adopt storytelling narration instead of other, you know, descriptive manner, I guess. The storytelling helps with many aspects. One that we talked about is like to think clearly.

Like it's really hard for us to tell a story if the story is not coherent. And if you're going to talk about a new product and you can't tell a coherent story about the new product is a strong signal there is something off here, right? More likely than not is not that you are not a good storyteller, is that this product doesn't

have a good story. So you should go back to the drawing board and think like, are we actually solving a real customer problem that we talk with customers and we really understand is our solution adequate to solve that problem? Because if you're writing a story in a format of a press release and it doesn't feel coherent, there is something off. So you need to look at it from that perspective. And as such is a powerful tool to help you think and identify the gaps on what you're trying

to do right. And that alone adds a lot of volume to the PRPQ, creates a lot of value by the PRFAQ. So I think, yeah, very powerful storytelling format. I think it's not just in writing PRFAQI think in your presentation in explaining something to the people so that they can get the coherent aspect that you mentioned right or what you're trying to convey. I think storytelling seems like everyone is adopting it, movies, writing documents, books, whatever that is. I think it's really powerful

concept. So I think in a press release we kind of like understand what should happen. I think the other aspect of press release that I find can be really useful is the, you know, building the vision, you know, trying to build the anticipation of, you know, releasing something, right? I think people can get excited just by reading press release. I think that's one aspect that I feel can be very useful as well. So the other aspect, the next

section is the customer FAQ. I think if I read press release, sometimes it is not followed by FAQs in the typical press release. Why do we create this customers FAQ which typically is mentioned in the website or somewhere, right? So why putting a customer FAQ as part of the document the customer? FAQ helps define the strategy that you're going after, right? So you can imagine a customer FAQ is how much is this going to cost? Can I import my data? I'm like, where do I get started?

And as you answer those questions, it's useful for the team that's going to be involved in building it to understand what exactly we are building because pricing, for example, can affect the viability or the feasibility of a project. If you say like this product is going to be free to our users, like everyone is going to think differently than it's going to

cost $3 a month. And even the fact that you say it's going to cost $2.00 a month, immediately you're going to get your engineering team and your UX team and your product team thinking about, all right, so you need to have billing, so you need to accept credit card or payment. So you need to build this whole thing. So it's helping inform people on elements of this strategy and how they need to think about this new project, this new

initiative. So when you paint this FAQ right, do you actually involve real potential customers or is it like the owner of the initiatives place the customers had? Is there a better way of coming up with these FAQs? You involve the customers in the sense that you should be talking to them. They're not going to be reading the document.

You might not even be telling them exactly what you're doing, but you need to learn from them about their problem, about how they are solving today, about how they found the solution today, what it would take for them to move from one solution to another solution. What is not satisfying them about how they are solving it today. There's many things there that I'm not going to elaborate everything here. The book includes a lot of that, so that is the extent that you talk with customers.

They should not be reading your PRFAQ the same way customers should not be reading your PRDS or any other confidential document within the organization.

Yeah. So typically in the product world, right, people use these persona or jobs to be done. In your book, you may actually mention that you prefer using jobs to be done framework instead of, you know, using personas. So maybe briefly tell us why is the case? Yeah, this is this is a longer conversation. We will need a whole podcast about this, right? But Personas was invented maybe 40 or 50 years ago, I don't know how long ago. And it was mostly a marketing tool, right?

So you could understand how to create campaigns that target certain traits of a person, right? Like a married man or like a child who lives in this neighborhood. And it's slowly Personas made it their way into product, right? Because we had no other tools of the way things. So it's not unusual for UX teams, for product managers to establish some personas for the product they're building and then from there trying to define the features they're going to build.

I think that's backwards, right? The best approach, and by the way, this is what Jobs to be Done has been discussed by Peyton Christensen and Tony Warwick and many people who wrote books about Jobs to be Done. There was excellent books out there, which is, it doesn't matter who your customer is, what matters is what they're

trying to do, right? If you're trying to hang A-frame to the wall, just to give a very typical example, like it doesn't matter any of the other elements of and attributes of your life, what we care is you're trying to hang A-frame to the wall. Can we solve the problem with a drill and hooks or with stick tapes or whatever? Right.

So if your product is about that, you're defining the job should be done, which is what the customer is trying to do and the solution that you're going to provide to that. And the framework is wonderful. I really think it's great. It's fantastic. It doesn't address everything. You know, there is some gaps there around desirability for some products. It's a little bit harder to be very clear on how you use jobs to be done.

But in general, I think it's a much better place for product teams that are considering creating something new to start from, or programs or services or businesses. Right. Thanks for clarifying that. So I think we can move to the next section, right. So again, just to recap, customer focused FAQ, right, Maybe it's like 6-8 FAQs that you include there. It's something that a hypothetical customer would ask if they read your press release, right?

So the first press release and customer FAQ, they kind of integrate it and both are kind of like future forward-looking,

right? The next section is internal FAQs and you mentioned this is not necessarily forward-looking. So tell us why? What is this internal only FAQ? I mean in the the main subject itself is kind of like weird right? Why you built an FAQ for internal teams? Yeah. So the internal FAQ is the most important part of the PRFAQ. And actually when you start writing APRFAQ, you start from the internal FAQ. You don't start from the press release and customer FAQ, you start from the internal FAQ

first. So it's kind of odd because you start from the internal FAQ first, then you write your customer FAQ, then last you write the the the press release. But of course you read it from top to bottom when you are providing feedback to someone else's PRFAQ. The internal FAQ is a way to explain strategy in terms of the feasibility, the viability, the usability, and the value that you are creating. So you're answering questions for the team as if the questions were being asked by the team.

That's why it's called internal FAQ. So you can imagine like maybe your manager comes to you and it's like, what problem are we trying to solve? Well, that's a great question to include on the internal FAQ. So, and actually it's my, my recommended first question that people should answer, like what problem are we trying to solve? And then you answer like this is the problem that we're trying to solve. You don't talk about the solution, you talk about the customer problem.

Like customers are trying to hang frames to the wall. That's the problem that we're trying to solve. So you focus on that and then you include several questions. It can be anywhere from 12 to 18 to 20 questions that help people understand all these elements, right? Like what are we trying to do, why we're trying to do, what is the problem? What is the solution? How customers going to find it? What have we done so far? How do we know this is true? Like all those kind of

questions. And in the book, I have more than 60 questions that people can pick and choose from. And of course, at the end of the day, you're going to have to adapt to your needs, right? There's going to be things that are very specific to your organization. So it could be that you're replacing an existing solution within your organization already. So you might need to have an internal FAQ to explain like how we're going to replace and migrate the data from X to Z,

right? You don't need to go into the details, but you need to say like the team has evaluated the solution and has tested the ability to do this, and we're going to use this tool or framework or technology to do that. That's enough for the strategy conversation. So that's what the internal FAQ includes. Right. Very interesting. You mentioned that we should start by writing the internal FAQ first followed by customer FAQ and the last is press release, right?

So I think I can understand why it is powerful to start with internal FAQ first. I think similar kind of question

like how do you come up with the questions, right? Do you involve the different various teams, maybe the leaders from those teams to actually come and maybe ask the questions itself upfront so that the owner of the initiative can come up with the answer? Or is there any other way of writing the internal FAQs? Yeah, the, the easiest way is probably to read the book and pick the questions from my my book, right. But independent of that, you're

right. Like, as you review this document with some people, they're going to ask you new questions that are very strategically important. That you haven't included. Some are going to be tactical, right? They're going to ask you about like, hey, are we going to use this cloud provider or that cloud provider that is tactical. You don't need to include that

unless it is not tactical. It's strategic in the sense that that decision is going to have implications for the partnerships the organization has. So that is strategic, not tactical. So as people ask you certain questions, you have to make a judgement. Is this relevant for us to make a decision or can we talk about that later?

If it is like we can talk about that later after we make a decision, you don't include it. If it is important to make a decision, you include it. So that's how you come up with newer questions that you can add to the internal FAQ.

Right. The strategic aspect part I think is really interesting, right? Because if, for example, we are building, I don't know like a technical products, how much level of technical details should be included? Or if, let's say it's a project about, I don't know, migrating something, right? Again, how much level of the, you know, technical details and steps that we need to include, right? And maybe marketing strategies, how much, you know, details in

terms of campaign. So I think sometimes it can be really difficult to actually understand about those kind of projects without actually knowing the level of details. So how should you balance these details with the strategic and concise manner of the FAQs? So it depends on what you're using the PRFEQ for, right? PRFEQ is for any kind of innovation. So we could be for a new product, new feature, but also it could be for internal

services and tools. And that can mean both like IT and HR and Finance and legal who need to change a process or change a vendor or change a tool that they use or implement a new tool for themselves. But also like platform teams and core technology teams and other teams that are building like infrastructure tools for other engineering teams to use. So in that case, what an engineering team can do is to imagine the other team as their customer. So they write the PRFAQ in a funny way.

It reads funny. And by the way, it doesn't have to be a press release on that case, could be an e-mail or a blog post announcing the new infrastructure. So let's say you're moving from one database technology to another database technology until the announcement itself is now we are making available for the front end engineering teams to access the data from this new database that we're using. I even include an example like that on my book about how to use

for internal tech projects. And on that case, the customer FAQs are employees of the organization. So the customers are employees of the organization. So you don't need the customer FAQs. You can just like get rid of that section, right? Like everything is an internal FAQ because your customer is part of your team. So you can share that information directly with them. And on that case, how you define strategy is slightly different, right?

It's more about the interfaces and the contracts that are going to be exposing to other teams versus the customer product that you're building for an external customer.

Thanks for clarifying that. So I think we have covered the three sections. The last section is the optional one which is appendix. One thing that I find really interesting, you mentioned that we can put appendix is optional, but you should not expect people to read it or dig deeper into it. So maybe tell us any reason this kind of specificity about appendix? Depending on the size of the project that you are working on, it might involve a lot of functions in your organization.

So you might have marketing and sales and UX and product management and engineering and machine learning teams and everything else that you can imagine like every other function under the sun. So sometimes it's good to have some elements that is a little bit deeper so this functions can comment on it. So let's talk about finance. For example, you might be revealing your PRFEQ with the financing. They want to know like how much this is going to cost, what is the revenue, What kind of

modeling have you done? If you include that in the 1st 6 pages, it's going to be a lot and it's going to be really hard for the other people to extract the value that they need from it. So you might include a page on financial modeling on the appendix, right? And then when you are reviewing the PRFAQ with the financing, you say read the PRFAQ and read Appendix C that has a financial

model, right? And then they going to be able to read the entire strategy and vision, but go one level deeper on what matters to them. Same thing for engineering, for UX, for product, for other elements. So you might include diagrams of an architecture if that's really important to include to make a strategic decision.

Again, you might include some Marks and wireframes of what you consider to be building so that it helps the UX team understand what's going on, or even the UX the results of UX research that has been done so far. Right. I think we have the full picture now about PRFAQ. Thanks for painting it in such a detailed manner, right? So I think some people might be really interested in adopting this, right? So I think maybe we should

advise people how to get started, right? So is there a way that people can start? Maybe there are some examples that, you know, are publicly available that we can follow? Is there any more contents maybe from you that we can follow in terms of, you know, trying to learn and practice the PRFAQ? Absolutely, yes. Actually, if you go to my website and you can go to Google and search for PRFEQ book and you're going to find the book website. I actually put a few examples

there so people can read this. And that's where I recommend people get started, right? Read a few PRFEQ so you understand what The thing is about. And then on the website I have lots of resources including templates for people to download and try to practice the PRFEQ or even buy the book and read it. Right.

One aspect when we try to adopt best practices from other companies or big tech giants, right, is the importance of context. Do you think this PRFAQ will work outside of Amazon? And if So, what is the most important thing that actually affects the success of PRFAQ adoption? So my book is an adaptation of Amazon's PRFQ. The way Amazon does PRFQ is slightly different than what I described in the book because Amazon is a very resourceful organization.

It has a lot of money, it has a lot of people, it has a lot of time to make like really big decisions that only going to have an impact 2 years from now. Most organizations don't have that kind of resource or that timeline or that mindset. So the reason I adopted the Amazon way is so that anyone could do a PRFQ in one or two weeks, which is a reasonable amount of time if you're going to invest three months, six months or 12 months in a project, right?

And I, I do think it's very useful for even if you're just a single person, right? Like you're a solo entrepreneur or solo founder, the PRPQ helps you give you clarity as you think about and as you're writing. And then they find the gaps on your knowledge and your critical thinking. The PRPQ is going to forces you to like get clarity on it and learn how to articulate it better. So people ask me like, hey, should I should founders use PRPQ to, to get investors.

And I say it doesn't matter. What matters is that you write your PRPQ. And by the act of writing the PRPQ, even if you use a presentation later, you're going to be much better at articulating your vision and your story in a way that's going to resonate with investors. So he works on that setting, but he also works in any big company. My only recommendation is that people don't start PRPQ with a very big project if it is the

first one that you're doing. You know, pick a small project with a reasonable number of people, maybe 5 or 10 people in the organization. Tell everyone this is an experiment, that you're going to give it a try. I pretty much guarantee that the first time you try is going to be wrong. So try again and try again. No one like gets it right the first time. It doesn't matter if it has PRFAQS or OK Rs or PRDS or any

other framework. Like it takes some time for you to learn it, so use it three to four times before you really understand what's going on and feel like comfortable using it. Yeah. And one aspect that is really important is the writing skills, right? So again, this is a written narrative document, right? So you should also improve in terms of writing skills and also the culture in the team organization should be, you know, valuing written artifacts rather than, you know, just the

presentation slides. So I think that's so important.

So you mentioned that people will make mistakes adopting this framework in the very beginning. What are some of the common mistakes or anti patterns that you see people you know start whenever they adopting PRFAQ? The first one is really being too tactical in our PRFQ and including a plan and road maps and detailed feature list and lots of wireframes. Like don't go there, right? Like PRP, QS are about strategy

and vision. Stay on the ground for as long as you can so everyone can be aligned on the desired outcome that the team is going after. That's number one. Number two mistake is people. It's kind of silly, but people think of PRPQ as a, what do you do at the end of a project, right? So you're going to be ready to announce. So you write the press release, you write the FAQ, and then you announce it like, no, it's not for that. It's for the decision.

It's for early on. So these are very two very common mistakes that I see happening. Yeah, I can really understand the last one, right. People think it's about announcing the product, right. But actually it should be used for decision making before you actually decide to embark on, you know, the thing that you are planning for in the PRFAQ. So we have covered a lot of

things. Is there anything that you think we should also cover today? But I haven't really asked. So is there anything from you, Marcelo? The one thing I would say is to use a PRFEQ effectively in your organization. The people reading the PRFEQ also need to learn how to provide good feedback. And I even have a free chapter that people can download from the website as well of how to provide feedback.

Because if you're not being effective in providing feedback, you are reducing the value of the PRFEQ. Because PRFEQ is a collaboration mechanism and you want everyone to understand their role as they provide feedback. Right. I think that's a very important right. If people read but know feedback given, right, I think they'll be less powerful aspect of this. And as you mentioned, it's the collaboration aspect, right?

So that's why we include things like the customer FAQ, the Internet FAQ that is actually to cover, you know, different perspectives so that your idea gets more powerful, right? And you can get the buy in from various different parts of the organization. So Marcelo, really love the conversation. Really appreciate the book that you write, the PRFAQ framework, right?

So as we reach the end of our conversation, I have one last question for you today, a question that I call the tree technical leadership system. So think of it just like advice that you want to give to us, the listeners here. Maybe if you can share your version of the wisdom. Yeah, I'll, I'll share. The first wisdom is fall in love with the problem, not the solution. There are multiple solutions to a problem.

And once you really understand the problem, you're going to be able to provide better solutions for it. And that applies to everything. My not only customer problems, but internal problems as well. The second one is remember that everything that we do is with and about people. Your customers are people, your team members are people, your

vendors are people. So if you understand behavior science and either communication or interpersonal skills, you can really advance, you know, your initiatives. The third one is really people need to learn how to articulate their thoughts more clearly. Because if you have a good idea or if you have good intentions but you don't know how to explain them well, it's really hard for other people to support you and to rally behind you. That's really powerful, right?

Because I, I really can vouch. So many bright people, right? Bright ideas, but not able to articulate their vision, you know, their ideas better to other people, right? Unless it's a solo project where you can do it maybe all by yourself. But I think most of the big impact projects you require other people to work with, right? So I think thanks for mentioning that. So Marcelo, the people would love to, you know, follow up with you, ask you questions or

maybe go to your resources. Maybe it's there a place where they can find you online? The easiest way is to go to Google, search for PRF, EQ book, find the book website. The outer page has all my contact information, including my e-mail address. Thanks so much. I'll put that in your notes. So thanks again for your time today, Marcelo. Thank you, Henry.