Embracing Innovation: Introducing the PR FAQ Framework with Marcelo Calbucci
In this episode of How Many CTOs Does It Take?, hosts Brad Hefta-Gaub and Scott Porad sit down with Marcelo Calbucci, a seasoned CTO, startup founder, and author of The PRFAQ Framework: Adapting Amazon's Innovation Process to Work for You.
Marcello shares insights on the PR FAQ framework—an innovation decision-making tool used extensively at Amazon—and its applicability to startups, product managers, and even internal projects within larger organizations. The conversation covers the steps to creating a PR FAQ, common pitfalls, and tips on how to integrate this framework into established corporate cultures.
Marcello also discusses his transition from startups to Amazon, the importance of internal alignment, and the value of answering tough, strategic questions early in the project lifecycle.
00:00 Introduction and Guest Welcome
00:58 Marcello's Background and New Book
02:08 Experience at Amazon
03:46 Understanding PR FAQ
05:25 Importance of Customer Value
07:07 Team Alignment and Decision Making
08:54 PR FAQ in Practice
15:14 Using PR FAQ for Internal Projects
19:18 Adopting PR FAQ in Established Organizations
20:56 Overcoming OKR Failures
21:45 Implementing PR FAQ Format
22:55 Common Pitfalls of PR FAQ
26:03 Confidentiality and Sharing PR FAQ
28:53 Using PR FAQ for Personal and Team Clarity
31:21 Controversial Aspects of PR FAQ
34:45 Adopting PR FAQ in Startups
37:42 Writing a PR FAQ Book
39:33 Conclusion and Where to Find the Book
Guest
Marcelo: You have to think about what are the hard questions that you're going to be asked,
both internally and externally.
Brad: Another episode of How Many CTOs Does It Take podcast.
I'm Brad Hefta-Gaub, and my co-host is Scott Porad.
Marcelo: Hello.
Brad: And today we have a guest with us,
Marcelo Calbucci,
who's a longtime CTO,
startup founder.
Marcelo and I met years ago in the sales startup scene.
And he's got a new book out called the PR FAQ. Welcome to How Many CTOs.
Does it take podcast,
Marcelo?
Marcelo: Hey folks,
thanks for having me.
Scott: Thanks for coming on here. We appreciate it.
Brad: Why don't you give us a little rundown, Marcello? What have you been up to lately?
Marcelo: Yeah, so I just published a book a couple weeks ago.
It's called the PR FAQ Framework, Adapting Amazon's Innovation Framework to Work for You.
That came from the couple years that I spent working at Amazon and prior to that many years at startups and wondering like,
I'm like,
how come these two things haven't, you know, got together and had a baby yet until I created that baby right now, which is the book.
So primarily I'm focusing on, you know, evangelizing and talking about this framework with folks so they understand what is it for,
what's not for,
how to use it,
what's the value,
how to adapt to startups and product managers everywhere.
And very quickly about me, before that I spent a couple years at Amazon,
before that 18 years of startups in Seattle and London,
before that many years at Microsoft working at Bing,
before that hacking, you know, on my basement kind of thing.
Brad: Love it.
Scott: I have a question for you just to get out of the gate here,
Marcelo.
Marcelo: Go ahead,
Scott.
Scott: After all those years of doing early stage startups,
What did it feel like jumping into the ice bath of Amazon?
Was it a shock to your system or did it feel like actually a warm shower?
Marcelo: Yeah, it was a shock.
I'm not going to lie.
Among the big companies, Amazon is very interesting,
very entrepreneurial.
Just if you compare to like your Microsoft,
your Google,
your meta of the world,
it still is a big company. So everything is, you know, somewhat bureaucratic and a little bit slow.
Decisions need to be looked at from all different angles,
you know, from legal and compliance and engineering and like everything that you can imagine,
right? So sometimes you want to move fast and do certain things.
to the things and I'm not going to say that Amazon doesn't move fast.
It moves fast for a big company,
still is 10 times slower than a startup.
Brad: Yeah, yeah,
I imagine.
Scott: And had you worked with the PRFAQ? Was that a tool that you would use in your toolkit before Amazon or did you learn about it there?
Marcelo: I learned before I joined Amazon,
but like you don't know what it is until you practice it and you're using real life.
It's almost like, oh, I know about LLMs, but I never coded against an LLM API.
So like, yeah,
you know, but you don't know.
Right.
Scott: Mm hmm.
Marcelo: So that's how it was for an APR FAQ for me.
Scott: Did you just kind of fall in love with it when you were there or like it's clearly captured your imagination in some way because you wrote a book about it. So like what's that story?
Marcelo: Yeah.
So.
What happens is like Amazon uses the PR FAQ extensively,
right?
So every decision the company makes is usually starts with a PR FAQ. I shouldn't even say usually,
always starts with a PR FAQ, right?
Any meaningful decision,
sometimes a decision that's going to cost only $100,000.
There is a PRFAQ behind it, right?
And these decisions are about new business or a new product or a new feature or even a new program or a new policy within the company.
So IT might decide to change some policy about,
you know,
laptops.
It's going to write, someone in IT is going to write a PRFAQ and that PRFAQ is going to be used to...
who discover and debate the right strategy to do this like why are we doing like what is the impact uh how are customers going to think about and in the case of it the customers are the employees right so they incorporate that thinking uh and very quickly as like a participator many of these PRFAQ reviews early on not my own PRFAQs but someone else's in my organization
I realize,
wow,
this is really powerful.
It's a very interesting tool.
It's kind of odd in the beginning because the format is very strict.
The style of how you review it and how you look at it is very strict,
not strictly descriptive would be the right word, right?
So if you're like, oh, this is strange,
but as soon as you get into the rhythm of it,
it's really hard not to see this as a major asset for thinking strategically and making decisions.
Brad: One of the things that I think really resonated with me in the book was this notion of making sure that you've really captured the why.
behind the thing that you're trying to make the decision around,
whether that be building a product or to your point about like some new laptop provisioning policy or something like that.
And there was like one of the lines that was out of your book that I really resonated with me was this idea,
and I think it was how many software engineers or designers wake up on Monday morning and pick up the next item in the backlog and start working on it without understanding the customer value behind it.
And when I read that line,
I was like, yes, like that, that is so often,
I think, the challenge that engineers struggle with, like if they if they understand the customer value.
then they're going to do their job so much better than if they don't.
So I'm just kind of curious,
maybe that's just my little bias.
And so I that you know, my confirmation bias was like,
yes, that resonates with me.
But do you feel like
Is that kind of one of the key things that we should be taking out of the PRFAQ toolkit or how would you say like the most salient thing that engineering teams should take out of this toolkit would be?
Marcelo: Yeah, and I said designers and engineers,
Brad,
but it's also managers and directors and VPs that sometimes are just working on things without actually questioning,
what are we doing here?
Why are we doing this?
What is the value that we're creating for our customers and for our organization?
So the biggest value of the PRFQ is a team, and I'm using the word team very broadly here.
Not only the team working on it, but the team adjacent to the project as well that are aligned on strategy and vision.
like everyone discussed debated discover and decided on that vision is not a committee driven decision still you'll have a few people that were responsible for the decision making but everyone was involved in the process of coming up with that and they had an opportunity to question certain aspects of the project like oh i don't think the technology is possible or a product person say like i don't think we can build this or a ux person saying like well the design shouldn't be like
be like that or the legal team say like no no no no you can't you can't collect that kind of information so everyone had a little bit of their voice incorporating into a single document that integrates all this thinking
uh you know in a cohesive way so that anyone reading it be like oh i understand what's going on even if i don't agree with it like it makes sense from a to z like it's it's there so you know that's where amazon has the leadership principle of disagree and commit um like once you understand what is in there you might even disagree but like the team is aligned that that's the direction we're going to go and that's
Scott: it
Marcelo: That's the direction that we're going to go.
Scott: Well, I was just going to try to take a step back here.
And could you just give us a quick,
I know I'm like you were talking about with the guy who's never programmed against the LLM. Like I know this concept, I've used it informally throughout the years, but I've never worked at Amazon. So I really don't know the real deal.
I'm wondering if you could just outline for us just for a second, like tell us the real deal, what it's like to really how it really works.
Marcelo: Yeah, let me take a step back here and let me say APR FAQ stands for Press Release in Frequently Asked Questions.
So this was invented by Amazon circa 2003-2004 as a decision-making mechanism.
And it's often referred as the working backwards six-pager.
Amazon has other types of six-pagers.
The PR FAQ is one of them, right?
And what it is, is a press release that paints a picture of the future, right? So what you're really talking about is what if we launch this product today?
How would we announce it?
So you write that press release in the first page and then you have five pages of frequently asked questions.
And the questions can be, you know, from a customer perspective,
like,
oh, how much this is going to cost?
How do I get started?
Can I import my data?
So you're answering those questions as if customers were asking them.
And then you have another section that is called the internal FAQs that is for the team.
asking itself certain questions questions like who is the customer and what problem are we solving for them when do you think we can have this data set to integrate into the product or like how much this is going to cost to operate like that type of questions that are answered on the FAQ now the document is just an artifact
that is used at a catalyst for conversation.
Like, so the goal is not to create like the perfect document alone in a room.
The goal is to collaborate with all your team members to create this document so that when it's done,
everyone agrees on it,
right?
There is no big reveal of like,
ta-da,
here is the strategy,
like go execute on it.
That's not really how it works,
right? Like people work together on it, which is very different than some organizations that use.
like PRD or functional specs and like they just throw over the wall to the engineering team go build it right PR FAQs are not like that the intentions are like that and by the way PRDs should not be like that either like you want the engineers in the process of creating that PRD but most companies don't have that practice but PRFQ doesn't work if you don't do it like that right the point is like a collaborative discovery
Scott: It's almost like it's the recording of the conversations and the outcome of those,
not the input or direction for everybody,
but the kind of, as people talk and develop a shared understanding of whatever this thing is going to be,
this kind of memorializes that.
Good way to think about it.
Marcelo: That's exactly right.
You know, it's not uncommon for our to have things in the PRFAQ to say like,
what are we not doing?
You know, or like, why have we decided by option A versus option B?
Like it's on the PRFAQ because that conversation took place and halfway through the team decided to do it differently.
So you keep it there, right? It's part of one of the FAQs.
Brad: Yeah, you know, it's interesting,
Marcelo, I kind of was thinking about how one of the things that we I remember from the early days, for example, of real networks, we were really adamant about creating what we would call rude Q&As about,
you know, once we did a product release, like or as we prepared for product release.
And of course, that's the spirit behind the rude Q&A is.
You know, there's no questions, no questions are barred, right?
Like what is the most antagonistic question that the press could ask,
the competitor could ask, and we might ask ourselves about this product.
And I think that, I guess I'm sort of like digesting you talking about the way to create these PR FAQs. It does strike me that so often.
team members are well why are we doing it that way or why didn't we do it that way or what about this corner that we're not turning to look down like why aren't we considering this and it and it does strike me that if we there's this value in the rude q a the value in the the questions that are the hard questions and
I'm assuming that that's an important part about the FAQ is that you really are capturing the tough legal question from the privacy team,
right?
You're capturing it and you're answering it as part of your getting on the same page.
Marcelo: Yeah, that's right,
Brad.
You got it correctly.
I talk about rude Q&A in the book,
right?
You have to think about what are the hard questions that you're going to be asked,
both internally and externally,
right?
Like how are the customers going to feel about certain things?
How does this compare with that other product?
Or like, why would I share this data with you?
So you have to think about that and incorporate that into the.
into the document to create good conversations.
The one thing that is important to say, Brad,
as well is a PR FAQ is not a plan.
It's a strategy.
Right. So you keep it very high level.
Usually don't go to the which cloud provider are we going to use?
Which LLM vendor is the best one for us?
Sometimes you might incorporate some of that because there is a uniqueness to that tactic of the plan that has an impact on the strategy.
But most of the time, you don't want to go to that level of detail,
right?
a PR FAQ is basically the starting of a project it's like the kickoff let's spend actually pre-starting of a project let's spend you know two weeks on this PR FAQ to make sure that we understand the vision we understand the strategy we understand certain outcomes that we're trying to achieve and everyone is aligned on that once you arrive to a certain alignment then you go like all right
We are a goal for this project.
Let's start working a plan now.
Scott: Okay,
Marcelo: Yeah.
Scott: so you've given me, I want to explore an idea here with you, Marcelo.
Marcelo: Go ahead.
Scott: Something Brad and I have talked about a bunch is tech debt.
And I was just talking to one of the engineers on my team this week about kind of an area he wants to solve, address,
you know, where there's problems,
where there's a lot of tech debt.
And I'm trying to think, I was just thinking as you were talking,
I was thinking about.
How could he use this?
Like who would his audience be if he was writing that press release?
I can imagine what the FAQs would be like, but I'm trying to think about who the audience would be.
You ever seen it used like that?
Where an engineer sort of talked about
Marcelo: Yes, absolutely.
Not only I've seen use cases like that on the book, I include an example just like that.
about an engineering team replacing a piece of outdated technology.
So the audience for that is everyone who is going to be working on that project,
all the engineers or SREs or other people that are going to be working on that project,
their peers and everyone who is going to be impacted by it. So like other engineering teams and organizations,
potentially the product team.
If there is consequences like for the budget,
you might need to involve finance as well.
If there is legal consequence,
you need to involve the legal team as well.
And this person can write a PR FAQ.
And by the way, in the book, I explain like not necessarily needs to be a press release that you start with.
Press release is the best format,
but it could also be the email from the CTO to the entire company.
Scott: Mm
Marcelo: Hey,
Scott: -hmm.
Marcelo: today we are announcing that we are replacing this old project with this new project.
You know, this is what's going to happen. This is the benefits for us, the problems that we had before.
So that also works because what you're doing is painting a vision.
of the future right
Scott: Hmm
Marcelo: anyone people reading that is like
wow yeah let's do that right
Scott: Yeah.
Marcelo: i'm online i understand let's talk about the the strategy now so now you go to the q a section the faq section and like you have like some hard questions there like why are we doing like what are we saving like what is the consequence if we don't do it right what is the cost of delay you can include all that in the faq section very technical in that case is
Since it's an internal project,
you do not need the customer FAQ section,
Scott: Mm hmm.
Marcelo: just the internal FAQ section,
because your customer is internal,
you know, and the same team working on it is the same thing. So like, you don't need that section.
So in the book, I explain how to use it for that use case as well.
Brad: It's so interesting.
I'm like.
I have so many questions for you, Marcelo. One of the things, though, that your point about this internal project as well has struck me is, has this, I mean, it seems like we could use this technique also to just do any kind of organizational change management.
Right.
Scott: Mm
Brad: Like
Scott: -hmm.
Brad: we're, you know, we're going to try to change like, you know, how we recruit new new team members. Right.
And so we could use this same sort of start with the end in mind type approach of like, here's my press release,
the internal email to the whole team about our new approach for recruiting the best talent and and then use the same FAQ approach to really kind of.
interrogate that strategy.
Marcelo: Yeah, that's a very common use case, you know, like everything related to HR,
recruiting IT,
compliance,
all of that could start with a PRFAQ as well to have like this conversations,
right,
so people can discuss and think through and understand the impact that it might have for them.
That's not unusual at all.
Scott: Yeah, and I like this is at the beginning of the process.
It paints the vision of the future at the beginning of the process,
not like at the end of the process often where you're kind of telling some people about what's going to happen after kind of all the work has been done.
This is at the beginning.
I kind of like that.
Brad: How have you seen this like brought into organizations that maybe already have an established
culture around decision making right like it would be easy if the three of us are going to start a new startup together like we're we're malleable and we're like open-minded and we're like yes we're going to do this because it's you know it's worked for marcello in the past and it's we buy in but what about an organization that's already established and and maybe is rigid or calcified in their in their approach decision making
Marcelo: Yeah, it's it's not easy,
Brad.
I wish I would say like this is how you do it and it's going to be easy and everyone is going to be happy.
but you know this changing organization is really hard like change is slow there's a lot of resistance even when people say we do want to change we think this is going to be great uh but there is always pushback right and there is always a person that's going to point as soon as the first failure say see i told you this wouldn't work right uh in the reality is a lot of change require persistence you need to try like one two three times before you say like
It didn't work for us.
Right.
So my recommendation and it's the same way that I would recommend someone who is adopting a new framework like OKR or other frameworks like that.
Like don't start big.
Don't start all at once. Right.
Like pick one project that is manageable,
you know, with a few people and do it there and see how it fits the culture.
Right. And do some adjustments.
and to see how did it work in that setting,
right?
And even if it was a complete failure,
I would say try again in another project and try again in another project, right? Because you don't know if the failure was related to the project or to the framework.
And I've been in many meetings where OKR went terribly badly,
you know, both from the planning and the results of having OKRs.
But like once you persist and you start to learn and how to use it, you know, you start to reap the benefits.
Brad: Hey, Brad,
I can tell you, inspired by Marcella's book,
I kind of just got a little.
I lit a spark recently,
and I'll tell you how I did it.
Marcelo: Huh?
Brad: I didn't, and it got adopted better than I thought it was going to get adopted.
But we're still in process,
so we still see how well it works out.
A couple of weeks ago, we were starting another planning cycle.
And kind of the beginning of our planning cycles, people write these documents that sort of pitch their ideas with the ROI and all that kind of stuff,
right?
And someone suggested.
you know we should really have a common format for this and just because I had Marcella's book in my mind I just kind of said offhand I was like well why don't we use this PR FAQ format like Amazon uses it people really like it and
Scott: Love it.
Brad: there was kind of a general agreement for that and then there happened to be one person in the room who had previously worked at Amazon and she was like oh yeah that's great and it just kind of took off so we'll now we'll see how it goes people aren't done with them next week we start reviewing them but the real point I'm trying to make is
at the beginning of sort of a planning cycle when pitching people are pitching ideas yeah it's a great time to do it the notion that people wanted to come in format somebody else could have been in the room and suggested a different format I just happen I guess to be the first one to open my mouth and it was the only reason I opened my mouth is because it was just on my mind because I knew we were talking to Marcelo and so that seems to have worked
We'll see how good they come out,
Marcelo: That's
Brad: but we'll see
Marcelo: good.
Brad: how it works and see if I'm sure it'll take a few cranks around the wheel to get them dialed in.
I wanted to ask about pitfalls.
What are mistakes people make?
What should we avoid doing here?
Marcelo: Yeah, there are many pitfalls with PRFQ.
One of them I kind of mentioned,
which is people think a PRFQ is a plan,
a tactile plan,
right? And instead of like...
only talking about division and the strategy they're going to very high level of detail like we're going to build this services and we're going to use these APIs and we're going to create these databases and like do this all this detail and like this person is going to work on this project and this person is going to work on that other part like PRFQs are not for that do not try to stuff everything into a PRFQ you can extend a PRFQ by having things on the appendix
techniques, but I still I would recommend to keep it very high level, like very superficial.
What you don't want to do is create a PR FAQ that feels like a perfect plan, regardless if it's perfect or not,
and then people are not comfortable providing feedback.
Right. Because like, oh,
so much work has gone into that already.
Like I don't have the courage to question this thing here that might make the entire tower collapse.
Right. So.
Scott: You made that point about.
In the book, you make that point about like the build, learn,
build,
measure, learn and getting putting build in the wrong place. Like if your prototype is too advanced,
if your prototype is too robust,
it actually reduces the input,
the honest feedback you're going to get.
Marcelo: Yeah, that's my personal hack when I ask people to provide feedback on blog posts or articles that I'm writing.
I always say here's a draft,
even though I work my ass off to make this draft perfect,
you know, I always say here's a draft because when you say like that,
people are like, OK,
it's a draft like he's really asking for feedback.
So let me give him like what I really think versus me telling them like I work 10 hours on this article.
article like can you give me some feedback people are going to be very shy about pointing flaws on on my view and strategy is just like that right like if you say like oh we have the perfect strategy here review it for us who's going to have the courage to break your heart you know and say like this strategy sucks
Scott: So one pitfall is the don't put too much detail in it. That's a common pitfall.
Brad: Another common pitfall here is getting it too polished before you start to circulate it for feedback.
Marcelo: Yes, there is a right timing to do things like you want to you want to create a draft first so otherwise people don't have anything to hang on to.
But like the process of getting the feedback is the process of working the PRFAQ.
Brad: Working the PR FAQ,
Marcelo: Yeah.
Brad: that's a great way of phrasing it.
Marcelo: Yeah.
Another pitfall that is somewhat common is for people to write the PRFAQ at the end,
retrospectively.
Like you're about to launch a product and it's like,
wow,
let's create a PRFAQ now so we can be all aligned, but we should have been aligned in the beginning of the project,
not.
At the end. Right.
So that's not the purpose of a PR FAQ.
And the PR FAQ is really a confidential document.
Right.
Even though you have a press release that sounds like it's meant to be sent to the press,
it's not.
It's confidential. It's internal only.
So the team can feel confident that they can work on it without worrying that we're ever going to publish this.
to the press.
That's why you haven't seen many PR FAQs out there.
Even Amazon doesn't publish many.
I think they publish two PR FAQs as far as I know because there was a lot of confidential information on it. There was financial information,
there was legal questions,
there was root questions and it's uncomfortable to put out there.
Brad: Yeah, that makes sense. You want people to feel like they can talk openly about it.
Scott: Is that also then a pitfall is inadvertently having people inadvertently assume that it's not a draft or that it will be published?
How do you and how do you how do you set the tone for that?
Is that just sort of by fiat like we will we will treat this as truly a working document or is there other tips you have on helping people's mindset be framed that way?
Marcelo: Yeah, a PR FAQ is really a tool for the team that is working on the project and the stakeholders related to that project and the decision makers.
Usually you don't want to share outside of that group of people.
Right. So the lack of context can be problematic.
So even in large organizations,
you want to make sure that the PR figure is not like.
Everyone can read this because you might create conflict,
you might create politics,
and other types of problems.
Of course, people can request to read the PRFAQ and you have to evaluate.
Often what happens is,
and I mentioned this a few times in the book as well,
you can create slightly different versions of the PRFAQ.
So you have your master PRFQ that your team work on that has all the confidential information and then you're going to create a version that maybe redacts a few portions so that you can share more broadly within the organization,
never outside of the organization,
right?
Of course, the one case where you break this rule is when you're asking for an expert advice outside of your company or you're talking to investors about your...
your startup,
then it's outside of your organization.
I still recommend people to create a redacted version,
like remove things that you think are very confidential or you don't want to get out there,
particularly if it has detail about personal information.
or about customer information then you don't want to put it out there right because that would be a break of confidentiality and sometimes even a break of privacy yeah
Brad: Gosh, I can see even just using this for myself,
not even for sharing with other people, to just get clear on what I'm trying to do.
Scott: Totally.
Your own personal goals.
Marcelo: it's it's it's really hard to write a PR FAQ without clarity so the interesting thing about writing a PR FAQ
Thank you, Scott.
Just like you said, is as you're writing, you
Brad: Mm-hmm.
Marcelo: start questioning yourself,
right? And you're like, wait a second,
this doesn't make any sense.
This is not coherent.
I need a better story here. So like you revisit,
refine your idea,
you know, for whatever initiative or project you have into a better one.
So the process of writing is phenomenal,
really.
Brad: Yeah,
we were just discussing like a little org change today for a company. I mean like minor adjusting one or two teams.
And as we're talking here,
I'm thinking,
gosh,
we should write a PR FAQ for that.
Why are we doing this?
Scott: Totally.
Brad: What are the questions people have?
I mean, we're having that discussion.
We're doing all the discussion,
but no one's writing it down.
And nobody's sort of,
Scott: Yeah.
Brad: it's more informal getting on the same page.
Marcelo: Yeah. And you can think of a PRFAQ on a case like this or other cases as well as the straw man,
right?
Like you start from a straw man proposal.
So you put something on the paper and then people can poke at it and like give their feedback versus like a free form where like, you know, sometimes you go to these brainstorming meetings where it feels very chaotic.
Everyone is from an idea. No one is collecting.
There is no.
you know, convergence of thought.
So it feels very weird.
PRFAQ avoids that.
Brad: Now it fits also with something that I like to do way lower in the process in terms of technical design Which is get people to write their technical designs down because I always like to say fight with the document don't fight with each other
Like let's you know, let's not because you get in a tug-of-war when you're talking but when you're just reviewing a document It can be a much more civil
Marcelo: Yeah, I love that.
I should have used that tagline in my book.
Scott: don't fight with each other fight with the document oh
Marcelo: Actually, let me add something interesting,
Scott.
PR FAQs don't have the author name on them.
Scott: yeah i noticed that
Marcelo: Yeah,
Scott: Yeah.
Marcelo: because the idea is to discuss the merit of the project or the initiative,
not discuss, you know, the person
Scott: Yeah,
Marcelo: behind
Scott: exactly.
Marcelo: it.
Scott: Yeah,
Brad: Oh,
Scott: I'd like that
Brad: that's
Scott: point.
Brad: blowing
Scott: I
Brad: my mind
Scott: actually right had now. another question for you, Marcel,
if you don't mind.
You kind of gave us the pitfalls, but I was kind of curious, like, what are the most controversial things in the framework? And I'll admit,
like, has...
You know, you know, this is this is sort of like CTO's perspective and so therefore it kind of, you know, there's a piece of being the CTO where you're like representing the engineering team to the business and representing the business back to the engineering team.
And there's a few things in there that I was kind of like, oh,
I bet some engineers are going to bristle at this.
But what do you feel like the most controversial pieces of this framework are?
Marcelo: I don't think there is a controversial aspect of the framework itself,
but what I've seen is, you know, part of the PR FAQ is to get experts to critique the PR FAQ in what they know.
So when you are in a room full of engineers and you have a PRFAQ in front of them, you want them to critique the feasibility,
the technical feasibility of the project versus, for example.
like the privacy laws of GDPR,
Scott: Right.
Marcelo: right?
Scott: Their
Marcelo: Because that,
Scott: opinion on something they're not an expert on.
Marcelo: yeah,
that you're going to talk with the legal team and the compliance team,
right?
Or the council or someone else, right?
The same way that you don't want the legal team to read your PRFQ, ignore the legal aspects and start critiquing the UX aspect of the project, like or the use case or the pricing.
So that can be contentious because lots of people have opinion about product,
right?
And they love to talk about that, but like you need to catalyze people's energy into their domain expertise so
Scott: Yep.
Marcelo: that the PRFQ becomes the best that it can be.
Scott: Another thing I noticed in there,
and I thought you kind of called this out as potentially.
controversial is the idea that it it has like a a location and a date on it like you know a date and particularly like the the the imagined end point press release is released on a date you know Yeah. june 1st 2025 um what are your thoughts on that not being a hang-up for engineers who so often feel the pressure of the date
Marcelo: I think it's very important to have a date the same way it's important if you're doing like a piece of hardware to have a price on the PR FAQ. Like you want people to feel uncomfortable.
You want them to challenge like and say, wait a second,
like I can't do that by that date or I can't do that with that price or we can't launch that in that city,
you know, from a legal team perspective,
for example. So you're putting a few.
few stakes in the ground and like let people navigate that and come back to you and say like what is it actually possible to be done and what actually not possible to be done right and then you go and evolve the PR FAQ in that context to add more value to it right but I think like having everyone rally about a date helps everyone like your marketing team is gonna understand the engineering team is gonna understand the content team is gonna know what to do
Right. So we are all aligned on that commonality.
So we are not like thinking different things.
Scott: Totally.
Do you think that if you had this tool,
like if you could go back in time now that you have this tool,
is there a version of one of your startups or a team that you were the CTO on where you feel like, oh man, I wish I had had this tool then?
and how history might have been different had you had this tool.
Marcelo: Yeah, absolutely.
Actually, I know the startup I left higher.
Two and a half years ago to join Amazon,
now they have adopted PRPQ.
And what's interesting about the PRPQ is we're really big on OKRs.
But OKR always felt like something is missing here.
The story behind of this OKR is missing. The narrative,
like why are we doing like what we're trying to achieve, right,
like felt not there,
even though we were pretty good at writing our objectives in Kubernetes.
results you never felt that had like the the bigger thing behind it so I would definitely adopt have adopted PR FAQ had I know how to use it back then and definitely all the startups that I done in the past
Um,
I can't imagine myself doing a startup or a big project right now that I wouldn't write a PR FAQ.
And I did one just two weeks ago for a new project that I'm considering starting.
I'm not even starting.
I'm just like considering.
So I wrote a PR FAQ, shared with three people, you know, started to get feedback.
I'm going to throw that out, write a new one that is better than the previous one because I got a lot of feedback.
And that's great.
Right.
So you know where you're going that makes sense or it doesn't make sense, resonate doesn't resonate.
Scott: Yeah, I mean, there's a little bit of like kind of painted door strategy as well that kind of overlaps with PRFAQ, right?
Where it's like, I don't know, we got this idea,
let's let's put a door, you know, let's put a, you know, storefront up and see if anybody clicks on it as a way of kind of learning.
before building,
right?
So
Marcelo: Yeah.
Scott: it does seem like there's some overlap in that strategy.
Marcelo: Yeah.
So the interesting thing about PRFAQ is like as you write your PRFAQ,
as you're writing your frequently asked questions,
let's say one of the question is like, how much this is going to cost to make?
And you go like,
oh,
gosh,
I need to figure this out.
Right. So let me do some research on that topic.
So one of the questions might be like.
How many people are interested on this?
And they're like, well,
we don't know. So let's go measure.
Let's go figure out. You can leave assumptions and you can call it out.
We think there is like 10,000 people a month that need this product or you can go and measure.
Right.
And so like we we know for sure there is like 700.
people that search for it on Google every month, right?
That's a good start.
So it forces you to do this kind of research and go out there and like figure stuff out.
Scott: Love it.
Brad: So how's the book been received?
Marcelo: Very positively.
I'm learning a lot about book marketing.
I never done a book before.
It's so different.
It's so slow.
This is a whole different industry than what I'm used to with software.
It's also not a product that you can update very easily.
You know, you can't just like push updates to someone that got a hard copy of the book.
Scott: That's so interesting.
And did you write a PRFAQ before writing the PRFAQ book?
Marcelo: Yes, I did,
Brad.
I did write a PRFAQ about the PRFAQ book.
It was terrible,
not good, but it did help me think through certain aspects of this book, right?
So my original intention with the book was I'm going to write this book just for startup founders.
And then I realized,
you know what, the real beneficiaries of this are not startup founders,
it's anyone doing any innovation who want to tell an idea and want to think through an idea and want to articulate that idea to other people and potentially they want to inspire people to join them on this journey.
So you could be a product manager,
you could be a CTO,
you could be an executive at a company or the VP of HR.
That once you create a new like referral program for interns or whatever they are coming up with,
right?
So it's anyone that is adding,
removing or making changes to a program, a business,
a service policy.
Scott: I love it. I got to read the book.
And this conversation has inspired me to think, man, there's so many ways you could use this, like to Scott's point about personal goals or just change management. So it's super exciting stuff,
Marcel.
Brad: Yeah,
thank you for coming on today.
We appreciate your time and if people want to go get the book,
where do they go?
Marcelo: They can visit the book website. You can Google for PRFAQ book or go to www.theprfaq.com.
Brad: All right.
Thanks, Priscilla.
Marcelo: Thank you so much for having me, folks.
Scott: It was great talking to you again,
Marcel.
Marcelo: Yeah,
take care.
Scott: This episode of How Many CTOs Does It Take Podcast was edited by South.
Marcelo: Check them out.
Our theme song was AI-generated by Brad.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon.
Or at our website at HowManyCTOsPod.com.
And remember to rate, review,
and subscribe on the podcast platform of your choice.
Thanks for listening.