Pmm Content Writer

PMM Content Writer

This skill exists because "write a blog post" too often returns a 250-word outline with the headings filled in. That is not a blog post. The job here is a finished, deep, specific piece a real editor would accept — drafted to a budget, grounded in evidence, with every section developed.

If you are producing the content section of another deliverable (e.g. the blog copy inside pmm-feature-announcement), apply this skill's budgets and rubric to that section.

The bar (read this first)

You are writing the whole thing, not describing it. Concretely:

• Finished prose, not scaffolding. No ## Section headers left with a sentence under them. No "this section would cover…". If you write a placeholder, replace it with the real content before returning.
• Hit the budget. Every content type below has a word range and a structure floor. Under-writing is a failure, not concision.
• One idea per section, fully developed. Each H2 advances a single point through: claim → why it's true → a concrete example or data point → implication for the reader. A section that's only a claim is not done.
• Specific beats generic, every time. Name the tool, the number, the scenario, the role. "Teams struggle with onboarding" is filler; "a PLG team watching 60% of signups never reach the aha moment" is content.

Length & depth budgets

Pick the row that matches the request. These are floors, not targets to dodge.

No section in a long-form piece may be under ~120 words. If a point can't carry 120 words, fold it into a neighbor or cut it.

Workflow

1. Lock the one idea and the angle. What is the single thing the reader should believe or do after reading? Write it in one sentence. Everything serves it. If the request is broad, narrow it — a deep piece on one angle beats a shallow survey of five.
2. Name the reader and their stage. Role, what they're trying to get done (JTBD), and where they are (problem-aware vs solution-aware vs comparing). The depth and assumptions change with the stage.
3. Gather the evidence before drafting. Pull from product context, provided data, real examples, and credible sources. If specifics are missing, ask for them or use concretely plausible ones — never paper over a gap with vague phrasing. List the 4–8 evidence pieces you'll deploy.
4. Outline to the budget. Draft the H2s. Give each a one-line promise (what the reader gains) and note which evidence piece it carries. Confirm the count meets the budget's section floor.
5. Draft section by section, to the floor. Write each section in full using the section pattern below. Do not move on from a thin section.
6. Write the intro and CTA last. The intro earns the read (problem → stakes → specific promise). The CTA is one concrete next step, not "learn more."
7. Run the depth rubric. Expand anything that fails. Only then return.

Section pattern (use for every body H2)

• Claim — the point of this section, stated plainly.
• Why — the mechanism or reason it's true.
• Evidence — a concrete example, scenario, number, or quote. Always present.
• Implication — what it means for this reader, now.

Transitions carry a thread: end a section by setting up the next. The "so what?" test applies to every paragraph — if a paragraph survives without changing what the reader thinks or does, cut it.

Intro patterns

• Problem → stakes → promise: name the reader's real problem in their words, show what it costs, then promise the specific payoff of reading on.
• Contrarian: state the common belief, then the sharper truth.
• Lead question: a question the reader is already asking, answered by the piece.

Never open with "In today's fast-paced world", "We're excited", or a dictionary definition.

Depth rubric (self-check before returning)

Pass all of these. If any fail, expand — don't ship.

• Total word count is inside the budget range (not under).
• Section count meets the floor; no section under ~120 words.
• Every H2 develops one idea through claim → why → evidence → implication.
• Example and data-point floors are met, and they're specific (named).
• Intro earns the read; CTA is one concrete action.
• No filler phrases, no restated headings, no "this section covers".
• Voice and reading level are consistent throughout.
• A skeptical editor couldn't say "this is surface-level."

Worked example — shallow vs deep

Shallow (what to avoid):

Personalize onboarding

Personalizing onboarding helps users get value faster. Tailor the experience to each user's role and needs for better activation.

That's 28 words, one unsupported claim, zero specifics. Not done.

Deep (the bar):

Personalize onboarding to the job, not the persona

Generic onboarding optimizes for the average user, who doesn't exist. A 5-step "welcome tour" that's right for an admin is noise for an end user who just wants to send their first message — and noise is the fastest way to lose someone in the first session, where most activation is won or lost.

The move is to branch on the job-to-be-done, not the persona label. When a new user signs up, you usually know one high-signal thing: the action they took to get here, or the plan they chose. Use it. A user who connected an integration on signup should land in a flow about automating their first workflow; a user who invited a teammate should land in one about shared setup. Same product, two paths, each removing steps the other would have wasted.

Concretely: define 2–4 entry intents, map each to the single next action that reaches the aha moment fastest, and measure time-to-first-value per intent rather than a blended average. Teams that do this routinely see first-session activation move because they stopped asking everyone to walk the same hallway.

Same heading. ~190 words, a claim, a mechanism, a concrete scenario, a number, and a clear implication. That's the difference the budget enforces.

Anti-patterns

• Returning an outline and calling it a draft.
• Padding word count with filler instead of evidence.
• Five shallow sections instead of three deep ones.
• Generic claims with no named example, number, or scenario.
• A vague "learn more" CTA.
• Hedging every sentence until the piece says nothing.

Hand off to

PMM OS is a chain, not a menu — don't dead-end at advice. Pass the work on:

• osp-content-optimizer — tighten and optimize the draft
• pmm-aeo-geo — make it citeable by AI engines
• pmm-artifact-factory — publish and package it
• pmm-coach — review before anything customer- or exec-facing.

Frameworks & deep references

Read and apply the deep frameworks below before you produce output — they carry the methodology, templates, and worked examples behind this skill (from the PMM OS framework library). Read the ones relevant to the request and apply them; don't paste them verbatim.

• messaging/storytelling-frameworks.md — narrative frameworks for long-form
• messaging/04-message-architecture.md — anchor the piece to the message house