The Slack message looks harmless: "Can you quickly turn this into a one-pager?" Sometimes it is exactly that. The buyer is decided, the message is agreed, the proof exists, and the team needs someone to package the thinking so sales can use it. When that is true, the request is real work, and the right answer is yes.
Usually it is not true. Most "quick" requests are undecided decisions dressed up as assets, and the job is to find out which kind you are holding before you open the template -- because a polished asset makes an unmade decision look finished, and the company then ships its ambiguity with confidence.
Two definitions carry the rest of this article. A request names an output: a one-pager, a deck, a battlecard, a launch email. A decision is the choice the output depends on: which buyer this is for, what that buyer should believe, what proof supports the claim. When the decision exists, the request is packaging. When it does not, the missing decision has dressed itself as a deliverable and joined your queue -- a clarity problem arriving in costume.
I see this queue from the inside. I am the only product marketer at my company, so every request in the building lands on one desk, and before this I ran GTM systems at Pidge, where the request volume of a fast-growing sales org taught me the taxonomy below. The five types are not theory. They are what actually arrives.
Why "capacity" is the wrong first diagnosis
When PMM drowns, the first diagnosis is always capacity: too many requests, too few people. Sometimes that is real. But run the chain one step further back. A strong product marketer can take messy inputs and make them readable -- turn half-decisions into a deck, smooth the rough edges, make a story presentable for tomorrow's meeting. The company learns this quickly, and unclear thinking starts routing itself to the one function that can disguise it. Underneath the sales deck request is a positioning disagreement. Underneath the product page request, a buyer-definition gap. Underneath the "simple one-pager", a strategy decision nobody wants to make out loud.
So the workload is a symptom. The condition is that PMM has become the place where the company converts unresolved decisions into finished-looking documents, and every successful conversion invites the next one. Hiring against that queue does not shrink it. It adds capacity for disguising.
The artifact is where the job shows up
None of this argues against making things. PMM produces artifacts -- messaging docs, launch briefs, decks, product pages, battlecards, talk tracks, win/loss themes -- and the standard descriptions of the job, Product Marketing Alliance's market intelligence, positioning, enablement, and launches and Pragmatic Institute's bringing products to market and communicating their value, are mostly lists of artifacts and the thinking behind them. Every one of those descriptions quietly assumes the decisions underneath the artifact exist. That assumption is the whole game. A one-pager is only useful if the buyer, message, proof, and sales moment are clear enough to fit on one page. A launch brief is only useful if the company has decided what is launching and who should care. If PMM is handed the packaging after everyone else has finished avoiding the decisions, the company is not using product marketing. It is using a cleanup crew that happens to know grammar.
The five request types
The practical move is to treat every request as a signal before treating it as work. In my queue, everything that arrives is one of five types, and each type has its own response.
1. The real asset request
The thinking is clear: audience known, message decided, proof in hand, use case specific. Take it. Package the message, check the proof, ship it, and do not overcomplicate it -- not every request is a disguised strategy crisis, and treating the good requests with suspicion burns the trust you will need for the hard ones.
2. The clarity request
It looks like an asset request until you ask basic questions. Who is it for? What should the buyer believe after reading it? What proof do we have? What sales moment does this support? If the team cannot answer, you are not looking at a one-pager problem; you are looking at a missing decision, and the fix is usually a thirty-minute working session, not a two-week project. The words that route it: "Happy to help. Before I build it, we need to answer three things: who it is for, what it needs to make them believe, and what proof we can use." Or, when the shape is already obvious: "This looks like a one-pager request, but the buyer and proof are not clear yet. I can help package it after we decide those."
3. The alignment request
Teams disagree and want PMM to make the disagreement sound settled. Product wants precision, sales wants urgency, leadership wants category ambition, and the artifact is where the tension surfaces, because writing forces the choices that meetings postponed. The instinct is to average the opinions, and averaging is the trap: each position loses its edge until the message offends nobody and selects nobody. Averaged opinions produce beige messaging. The move is to name the real decision out loud -- "We are not choosing between two headlines. We are choosing which buyer problem we are leading with." -- because a named decision can be made, and an unnamed one can only be softened.
4. The urgency request
This one became urgent because the thinking was delayed: the meeting is tomorrow, the launch is next week, the customer call is in two hours. Help, but keep the emergency from rewriting your operating model. Separate the immediate need from the system fix: "We can ship a quick version for tomorrow, but we should treat it as temporary. The real gap is that we do not have an approved sales narrative for this use case." Then record what broke -- late intake, no owner, missing proof. If the same urgency keeps repeating, it is not urgency. It is the operating system.
5. The strategy decision disguised as copy
The hardest type. The team asks for messaging, but the company has not decided what it believes: the product could serve several buyers, the market story is still moving, the proof is thin. A copy edit cannot resolve any of that. It can only make the uncertainty sound better, which holds for about a week. The move is to say, calmly: "This is not a writing problem yet." That sentence creates friction, which is why many PMMs avoid it and also why it works. And when a deadline forces output anyway: "I can make this look cleaner today. I cannot make it true, specific, or useful unless we decide the claim." That last line is the job.
Intake that finds the decision
Most intake forms ask for asset type, deadline, channel, owner, and links. That tells you what to make and nothing about whether the thinking is ready. Better intake starts one layer down, at the decision behind the asset. Nine questions do it:
- Who is the primary reader or buyer?
- What should they understand, believe, or do after this?
- What sales or GTM moment does this support?
- What proof can we use?
- What claim should we avoid making?
- What has already been decided?
- What is still unresolved?
- Who can make the unresolved decision?
- What happens if we do not ship this now?
When the decisions exist, these take five minutes and the request proceeds as a real asset request. When they do not, the questions expose it before the work starts, which is the test working as intended. The longer version of this discipline, including the questions that stop an asset entirely, lives in Before You Make the Asset.
Decisions need owners, or the artifact becomes the owner
Triage keeps sending you to the same follow-up question: whose decision is this? Some belong to product, some to sales, some to leadership, some to a working session across all three. Harvard Business Review's "Who Has the D?" made the general case years ago -- organisations move faster when it is explicit who is empowered to break each bottleneck. The PMM-specific version is sharper: when nobody owns a decision, the artifact quietly becomes the owner. The deck decides the positioning because nobody wanted the debate. The product page decides the buyer because the team waited until copy review. That is one way a company ends up with a deck that is beautiful and unusable. The asset should express a decision somebody made. It should never be the place where the decision secretly happens.
A rhythm beats a queue
If every request arrives as a surprise, PMM lives inside other people's urgency permanently. A light weekly rhythm removes most of the surprise: one intake review for new requests, one launch readiness check, one sales feedback review, one decision log update, one protected block of maker time for the actual asset work. The decision log earns its keep fastest. It records what was decided, by whom, on what proof, and where it shows up -- so the same message is not re-litigated every time someone asks for a deck. Leadership's side of the bargain is to stop measuring PMM by output volume and start asking whether PMM is in the room before decisions harden, because a team can produce more assets than ever and still leave the company less clear.
The yes the business actually needs
Run this triage for a quarter and a pattern appears: good triage usually makes requests smaller. The team asks for a deck, and what sales needs is three slides and a talk track. They ask for a battlecard, and sales needs one response to one buyer flinch. They ask for a campaign message, and the confusion is coming from the product page upstream. Smaller never looks impressive on a roadmap, and it is the difference between producing volume and producing clarity. If what is drowning you is not a queue of requests but an entire portfolio of products competing for one marketer, that is a different decision with its own method.
So before accepting the next quick request, sort it: real asset, clarity, alignment, urgency, or strategy in costume. Only the first type starts in the template. The others start with the missing decision, because an asset is only quick when the thinking behind it is already done. A polished asset over an unmade decision does not save the week; it hides where the week actually went. Ship the decision first. Then the asset is quick.