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.