PMM is the function that everyone wants a piece of and nobody wants to plan around.
Product needs a launch brief for the release that just hit engineering. Sales needs a competitive battlecard for a deal they are pitching on Thursday. Leadership wants a new company narrative in time for the investor event next month. And somewhere in the queue, there is a request to "update the website" that has been sitting there for six weeks.
Without a structured intake process, PMM teams handle requests on a first-come, first-served basis — or on a loudest-requester basis, which is even worse. The result: high-urgency low-impact work crowds out low-urgency high-impact work, and the PMM team is always reactive.
An intake form creates a gate. Every request has to pass through a standard set of questions before it gets resourced. That changes the conversation from "can you do this?" to "here is the information I need to prioritise this against everything else we have."
What an Intake Form Captures
The intake form serves two purposes: it collects the information PMM needs to scope and prioritise the request, and it makes the requester do the thinking that they would otherwise offload to PMM.
A requester who cannot answer "what is the business objective this is connected to?" has probably not thought through whether they need the asset they are requesting. The intake form does not just prioritise for PMM — it filters out requests that were not well-considered in the first place.
The PMM Intake Form Template
PMM Request Intake Form
1. Request title:
[Short description of what you are requesting — e.g., "Competitive battlecard for Competitor X," "One-pager for enterprise segment," "Updated pitch deck for Q2 campaign"]
2. Requester name and team:
[Your name and function — Sales, Product, CS, Demand Gen, Leadership]
3. Business objective:
[What business outcome is this request connected to? Examples: "Improve win rate in deals that involve Competitor X." "Support the enterprise campaign launching in Week 8." "Enable the new EMEA AE team who joined in March." Do not write "to communicate our messaging." Write the outcome it should drive.]
4. Target audience for this asset:
[Who will use or receive it? "AE team during discovery calls." "VP of Finance evaluating our product." "All existing customers in EMEA." Be specific. One wrong audience assumption derails the whole brief.]
5. What does done look like?
[Describe the output. Format, length, required sections, any non-negotiables. Examples: "A two-page PDF one-pager, similar in format to the existing sales enablement library." "A slide deck of eight to ten slides, following our current template." Vague requests produce vague outputs.]
6. Key messages to include (if known):
[Any specific points that must be included. If you do not know, write "PMM to determine based on positioning." Do not write a paragraph of features — write the outcomes or themes.]
7. Inputs available:
[What do you have that PMM can use? Customer quotes, deal notes, product documentation, previous assets as a starting point, analyst reports, win/loss data. List everything. A request with good inputs gets completed faster and better than one with none.]
8. Hard deadline and reason:
[If there is a fixed deadline, state it and why. "Must be ready by 15 April — that is the day the new AEs start training." If there is no fixed deadline, write "flexible." Fake deadlines erode credibility and waste PMM planning time.]
9. Complexity estimate (your view):
[Your best guess at the effort involved: small (a few hours — a quick one-page update), medium (a day or two — a new asset from scratch), large (a week or more — a programme or significant messaging work). You may be wrong. PMM will validate this.]
10. Priority rationale:
[Why should this be prioritised now versus other requests in the queue? Connect it to a current OKR, an active campaign, an upcoming event, or a specific risk. "We are losing deals to Competitor X every week without this battlecard" is a priority rationale. "It would be nice to have" is not.]
How PMM Uses the Intake Form
The intake form does not auto-approve anything. It gives PMM the information needed to make a prioritisation decision within 48 hours of submission.
The PMM review process should be lightweight: one person reviews submissions twice a week, categorises them by priority and complexity, and responds to the requester with one of four outcomes.
Outcome 1: Approved and resourced. The request is connected to a current priority, has good inputs, and fits within current capacity. PMM confirms the timeline and output format, and adds it to the sprint.
Outcome 2: Approved but queued. The request is valid but PMM capacity is full. Requester gets a realistic completion date. If the requester believes the request cannot wait, they escalate for a formal reprioritisation conversation with the PMM lead — which requires dropping something else.
Outcome 3: Sent back for more information. The business objective is unclear, the target audience is undefined, or the output format is not specified. PMM cannot scope the work without better inputs. Requester is sent back to complete the form properly. This happens more than it should, and it is always productive: requesters who have to specify the business objective often realise they were asking for the wrong thing.
Outcome 4: Declined. The request is not connected to a current strategic priority, is duplicative of existing materials, or is outside PMM scope. PMM explains why and, where possible, redirects to existing resources.
Concrete Scenario: The Intake Form in Practice
A SaaS company with a four-person PMM team introduces the intake form after a quarter where two launches were under-resourced because the team was filling ad hoc requests from Sales. The first month generates 23 intake submissions.
Outcome breakdown: eight were approved and resourced. Seven were queued. Four were sent back for more information. Four were declined (three because the requester asked for something that already existed in the asset library, one because the request was a content piece that fell to the Demand Gen team).
The four sent-back requests: all four requesters completed the revised form. Two of those revised requests were then declined because completing the form revealed the underlying objective was already being addressed by a different project. The other two were resourced and produced assets that were subsequently used in 15+ deals each.
Total time saved by filtering four requests that did not need to be built: estimated at six working days. Total value created by the two high-quality assets built instead: two of the deals they supported closed, one at £45k ARR, one at £78k ARR.
How to Handle the "This Is Urgent" Override
Every intake process gets bypassed by people who believe their request is genuinely urgent. Some are right. Most are not.
Build an explicit escalation path for legitimate urgency. The path: the requester messages the PMM lead directly, explains the urgency and business risk, and asks for an expedited review. The PMM lead evaluates whether to reprioritise and, if yes, identifies what gets moved out of the current sprint to make room.
The key principle: urgent requests do not get added on top of existing work. They replace something. Making this explicit forces requesters to think about what is worth trading off. Most "urgent" requests become "not that urgent" when they require the requester to identify what they are willing to deprioritise.
Keep a log of expedited requests. If the same requester is bypassing the intake form regularly, that is a conversation with their manager, not a PMM process failure.
The Decision Trade-Off: Formal vs. Lightweight Intake
Formal intake (the full ten-question form): Right for teams of three or more PMMs who are regularly overloaded with requests. Right when leadership is generating ad hoc requests that displace strategic work. Right when PMM is building towards a function with clear capacity management and sprint planning. Requires PMM lead commitment to reviewing and responding within 48 hours — a slow intake response defeats the purpose.
Lightweight intake (four or five core questions): Right for a single PMM or small team. Right when the main problem is not capacity overload but lack of clear brief quality. A five-question version that captures business objective, target audience, output format, deadline, and priority rationale will catch 80% of the problems the full form catches at lower friction.
Start lightweight. Add questions only when you identify a recurring problem the form is not catching. A ten-question form that requesters resent and work around is worse than a five-question form that gets completed consistently.
PMM Intake Checklist
- Intake form accessible to all requesters (shared in Notion, Confluence, or submitted via Google Form)
- 48-hour response SLA defined and communicated
- Review cadence agreed (twice weekly recommended)
- Four outcomes defined: approve, queue, return for more info, decline
- Escalation path for urgent requests defined and communicated to stakeholders
- Monthly review of intake patterns: what types of requests dominate? What does that tell you about GTM gaps?
- Asset library maintained and linked from decline responses where relevant
Frequently Asked Questions
Won't the intake form create friction and make PMM seem unhelpful?
It will create some friction for requesters who are used to DMing their PMM at 9pm for a deck by 8am. That friction is intentional. PMM value comes from doing fewer things better, not doing everything adequately. The teams who are most satisfied with their PMM function are almost always the ones with the most structured intake processes — because they consistently get higher-quality output on the work that matters.
How do we get leadership buy-in to use the form?
Show the impact. Track what was requested, what was built, and what business outcome resulted. After one quarter of data, you have a picture: these twelve assets were built in response to intake requests, these three assets directly influenced closed deals worth X. That is a compelling case for keeping the process in place and getting leadership to channel requests through it.
What if Product wants to bypass the process for every launch?
Work with Product leadership to integrate the intake directly into your product development process. Every feature that moves to engineering should have a "launch tier" and "PMM needs" field completed at that point — which is effectively an intake form completed upstream in the roadmap process. This eliminates the last-minute launch brief problem because PMM has visibility weeks earlier.