Product Manager in the Middle - The Infinity-Pagers

For all of us who've ever opened a "One Pager" and ended up scrolling through War and Peace - this is your way out.

Inês Pinheiro-Kumar returns with another chapter of The Product Manager in the Middle, this time diving into the tangled world of product documentation.

If you’ve ever rolled your eyes at a “one-pager” that requires infinite scrolling, this one’s for you. Inês breaks down the true purpose of PRDs, Initiative Briefs, and RFCs, and shows you how to write the right doc for the right moment (with a little help from AI and a lot of honesty about font size crimes).

"Hey, can you review my one-pager for this initiative?"

Top 10 most frequent messages from my fellow PMs. And 99% of the time, I click the link only to find what I feared most... multiple pages.

So here we are. Join me on a noble mission: to bring the real, useful one-pagers back from extinction, to learn when long-form docs are actually the better play… and how to shortcut your way to it.

---

Call the Document by Its Name

Somewhere along the way, terms like one-pager, PRD, Initiative Brief, and RFC all got tossed into the same sad document soup. Depending on your organization, this mixing of terms might be a natural outcome of each team member’s past experiences from other companies. And honestly, there's nothing wrong with that until it evolves into bigger confusion and bigger documents.

The first step to untangling this evil web haunting our Google Drives is to call documents by their proper names and clearly define their purpose. Otherwise, we end up with a dozen poorly named Franken-docs doing too much or too little.

A PRD (Product Requirements Document) is the sacred scroll that PMs craft, hoping it guides the team to build the right thing. It's also frequently afflicted by the Franken-doc phenomenon. Ideally, it’s concise, structured, outlining the what, why, and how behind a feature or initiative. But reality often delivers a sprawling beast of specs, edge cases, and endless “just one more detail” additions.

• Good PRD: clear, concise, readable across functions. Bonus points if it fits on a single page.

• Bad PRD: 10 pages. Bloated, unreadable, and one sprint planning session away from becoming a horror story at a team event.

An Initiative Brief is your master doc, an ongoing, structured source of truth for a product initiative. It tracks everything from problem definition to discovery, trade-offs, delivery, and outcomes. Think of it as your product almanac or Wikipedia page (Just don’t turn it into War and Peace II).

The best Initiative Briefs are searchable, link-rich, and give any stakeholder the power to Ctrl+F their way to answers. They also stop you from answering “Wait, why are we doing this again?” fifty times.

If a PRD is a blueprint, an Initiative Brief is your field guide.

This one’s the engineering darling, and for good reason. The RFC (Request for Comments) is a structured proposal that says, "Hey team, here's an idea. Let’s poke holes in it before we commit." It’s not a final doc. It’s a feedback magnet.

A great RFC lays out context briefly, options and trade-offs in detail, and is filled with
comments and open questions on that right-side margin. It's the whiteboard of product docs meant to evolve with feedback, not sit quietly in a Drive folder.

If a PRD is a blueprint, an Initiative Brief a field guide, then an RFC is the brainstorming whiteboard.

So... What Even Is a One-Pager?

Short answer: a format, not a document type. A one-pager just means “this should be short.” That’s it. Not everything should be forced into a single page.

I’ve seen people cram entire multi-quarter initiatives into a single A4 sheet, abusing font size and line spacing in ways that should honestly be illegal. On the other side, if your doc is summarized to the point it reads like a CAPTCHA test, it’s not a one-pager. It’s a cry for help.

RFCs can occasionally fit into one page, if they’re lightweight. But honestly? Most good ones quickly spill over into multiple pages via the comments on the sidebar, and that’s exactly how it should be. Nothing is sadder than an RFC with zero comments. That’s not a document. That’s a ghost town.

Why, then, did “one-pager” become popular? We all ran short on time. Busy PMs,
stakeholders, and leaders demanded shorter summaries, prioritizing length over meaningful content. Ironically, the same leadership that demands you to be brief often falls prey to the same crime they judge. I’ve seen some of the best Product leaders give templates that were already 4 pages long without anything more than headlines and empty bullet points.

But fear not! Your favorite Product Manager has an ace up her sleeve.

Start from the End

Counterintuitive as it seems, start from the end. Just like how in school they taught us to write summaries after we read the whole story. So start by writing that lovely initiative brief that includes all the information you gathered and generated during discovery. It might seem like you are going the wrong way, but trust the process.

So here’s a guide to finally nail your documentation for the next quarters to come... with a sprinkle of how to use AI to make it easier.

We will share a structure Notion template with our subscribers containing guideline headers to point you on the right way, but you should feel free to adapt it to the specific scenario you are facing.

1st step - Write your Initiative Brief

This is your long-form, everything-in-one-place doc. Make it structured, linked up, and readable. It should walk someone through:

• The problem you’re solving (and why it matters)

• The impact (bonus points for breaking it down by user, ops, sales, etc.)

• The data backing it up in a story form (quantitative and qualitative, with source as a hyperlink)

• Explored solutions and why you chose the current one

• Risks (mention them, link full analyses elsewhere)

• The chosen solution: user stories, features, flows, constraints

• ...and after delivery, extra points if you add the learnings and success metric
  analysis.

Pro tip: write it with your designer and engineering manager. Not before them, not after them. With them.

Congratulations! You now have your initiative brief. It should be long, but not make
J.R.R. Tolkien quiver at the knees. Now to the fun part.

2nd step - Get all your documents out of one

Once you have the full Initiative Brief, you can carve out the parts you need for other docs:

• PRD? You’ve already written most of it. Just trim.

• RFC? Pull the proposed solution section.

• One-Pager? Take the top-level context and tailor it to the audience.

You can do it the old school way and use it as an encyclopedia of sorts to write the
following documents yourself. But in this day and age, you can simply drop your Brief into your AI sidekick of preference - ChatGPT, Gemini, Claude, Perplexity - and ask it to do its thing (I’m a ChatGPT girl myself; first-name basis).

Here are some prompts that will help you get started:

Prompt for a One-Page PRD

"Summarize this discovery document into a concise PRD that fits on one A4
page with font size 10. Include only the most critical context needed for
product, design, and engineering to align. Structure it with:

• Feature name & problem statement

• Goals & success metrics

• User personas / key user insights

• Scope (must-haves only)

• Assumptions / dependencies

• Key flows or UX principles (no screens, just logic)

• Open questions or risks

Be as compact as possible without losing clarity or intent."

Prompt for an RFC (Request for Comments) for Product + Design

"Turn this discovery document into an RFC for cross-functional feedback. Focus
only on solution X. The RFC should include:

• Context (brief)

• Problem statement

• Summary of user insights leading to this solution

• Proposed solution (how it works, pros & cons)

• Design principles or hypotheses

• Open questions for Product/Design feedback

• Risks or trade-offs

  Keep the tone exploratory, encouraging feedback. Bullet points are fine
  where helpful."
  

Prompt for a One-Page Leadership Summary

"Create a one-page executive summary for leadership from this 10-page
discovery document. Focus on strategic clarity. Include:

• The problem we're trying to solve

• Why it matters (impact potential or urgency)

• Key insights from discovery (keep it brief)

• Proposed direction(s) being explored

• Potential impact or opportunity size

• Any early risks or dependencies
  Use crisp, executive-level language with no fluff."
  

Prompt for a Memo to Support Teams (Marketing / Ops)

"Summarize the discovery findings into a clear memo for Marketing and
Operations. The memo should help them understand the feature and prepare for
enablement. Structure it like this when information is available. If not, skip the
command.

• What the feature is and why we’re building it

• Who it’s for and key user insights

• Timeline or status

• Expected impact

• Support needed (e.g. rollout, FAQs)
  Keep it jargon-free and easy to skim. Use plain language and bullet points."
  

The document is your oyster. Experiment with prompts and adjustments to the ones above to never again have to write repetitive documentation.

Why Change Your Ways?

You might be thinking, "I’ve been getting by just fine. Why bother?" Here’s why: this is the stuff that makes you senior.

Not writing more docs. Not writing longer docs. But writing the right doc, for the right people, at the right moment.

A PM who nails communication, who tailors message and medium, is a PM who gets trusted
with more. Because clarity is leverage.

AI can write your docs, sure. But only if you give it the right source to work from.
Otherwise? It's just going to hallucinate features and make up personas named Dave.

Anyway, who am I to advise you? I just wrote 2000 words on how to write documents.

---

Got doc horror stories? Pet peeves? One-pager crimes to confess? Drop them in the comments.
I’m all ears (and memes).

Pssst… If you are one of our subscribers, there’s a nice shiny Notion template for you.