PR/FAQ

Proposals used to be written in the language of the company writing them. Conversion sits at 1.8 percent, so we'll rebuild the checkout screen. We'll add filters to the document list. Read from inside, sentences like that look fine. They carry a number and they name the work.

The trouble showed up at the end. Once the build was done and somebody had to write the announcement, the question "so what do we tell customers?" would land and the room would go quiet. "We added filters" is not news anybody receives, and trying to say what got better in one sentence turns out to be impossible. Six months of work, and the fact that it reads as nothing much from the customer's side only surfaces after it's finished.

Reversing the order moves that discovery to the front. Write the news the customer will get before building anything, and if the sentence won't come out, stop right there. A PR/FAQ — a press release paired with frequently asked questions — is that check turned into a document format.

The document comes in two halves. The front half is a press release written as though it ships today. The back half is the set of questions that news will provoke, with answers. Together they run two or three pages, longer than a one-pager and shorter than a product requirements document (PRD).

The press release borrows the shape of a real press release and has five parts.

1. Headline — the one sentence a customer would see. It names what changes for them, not what got built. Not "document filters now available" but "teams with 500 documents can find the one they want in three seconds."
2. Subhead — one line narrowing down who this is for. Not every team, but teams whose document count has passed some threshold.
3. Summary — one paragraph on what becomes possible. Lift this paragraph out on its own and it should still make sense to a customer.
4. Problem — what the customer deals with today, written as something a person experiences. "Search is imprecise" does less work than "mid-meeting, someone spends two minutes hunting for last quarter's notes and ends up asking the person next to them."
5. Solution and getting started — how the problem goes away, and where the customer clicks to begin using it.

The questions in the back half split into two groups.

1. External questions — what customers will ask. Does the price change, does this apply to documents I already have, does it work on the free plan. Drop the questions with uncomfortable answers and the document stops functioning as a check.
2. Internal questions — what the team building it will ask. How long it takes, who works on it, what counts as success, and what has to be undone if the bet is wrong. Options that were considered and rejected, plus why, belong here too.

Whoever is proposing writes it. Product managers write most of them, often working the headline over with a product marketing manager, the person who owns launch communication. It takes five or six drafts rather than one sitting, and most of that time goes into the headline and the summary paragraph.

Two audiences read it: the person who will approve or reject the proposal, and the team that would build it. Naming both at the top of the document settles the vocabulary and the length on its own. A document the CEO reads has to unpack technical terms; a document the engineering team reads owes them a line explaining how the pricing tiers work.

How it gets read is part of the format. Rather than sending it around beforehand, many companies spend the first ten minutes of the meeting reading it together. Send it ahead and half the room arrives without having read it, which puts the meeting right back at square one, explaining.

The document also has a fixed place in the sequence. It comes before the scope of a minimum viable product (MVP) gets set, and well before anything that specifies requirements and acceptance criteria. Clear it and the work goes onto the product backlog, the ranked list of what might get built next, while the judgment itself gets written down separately as a decision record, the note of what was decided and why.

"Write this up as a PR/FAQ and let's look at it again next week."

Check whether the proposal holds up from the customer's side first; nothing is being decided in this meeting.

"The headline still isn't there. That means it isn't ready to build."

Catching, before any work starts, that nobody can state the customer-facing news in one sentence.

"External questions look fine, but the internal ones have no rollback."

What breaks if this is wrong, and how it gets undone, is missing and needs filling in.

At Pagedeck, Mia used this format for a proposal about moving free-plan teams onto a paid plan. Eight rewrites of the headline later, the underlying idea had changed twice. Translated into the customer's words, a ten-day free extension turned out to be no news at all; what read as news was that a team passing ten people could keep working together for another month without paying. Grace read the document in the first ten minutes of the meeting, and her first question was one of the internal ones.

The most common mistake is reading it as a press release that actually goes out. The name says press release and the thing looks exactly like one, so the assumption is fair. But this document never leaves the company — it spells out unlaunched plans, which is precisely why it stays inside. The real press release gets written separately once the launch is confirmed. Blur the two and the effort drifts toward polishing sentences while the internal questions, the half that does the checking, stay thin.

Believing that writing one improves the thinking is the other one. Filling in a template feels like scrutiny in itself. But every section can be complete and the document still be nothing more than good marketing copy, because the questions with uncomfortable answers got left out. Somebody wants to answer "no, the price doesn't change," so the paid tier quietly disappears from the draft. A document that clears review in that shape gets the same question back from customers after launch instead. The format's job ends at forcing the awkward questions onto the page; answering them is a human decision.