Write a Positioning Statement for a Feature (Not Just a Whole Product)

A feature positioning statement is a fill-in-the-blank claim — for [user], who [job], [feature] is a [category] that [outcome], unlike [alternative], it [proof] — that forces you to name the one job the feature wins, instead of listing what it does. Skip it and launch messaging defaults to a capability dump.

Quick Answer: Adapt the classic Geoffrey Moore positioning template to a single feature by replacing "product" with "feature," anchoring the "who/need" clauses in real customer-job language, and stating one outcome, not a list of capabilities.

Why Product-Level Positioning Templates Fail at the Feature Level

Most PMs reach for whole-product positioning frameworks and try to cram a feature into them, which produces a statement so broad it fits every feature you've ever shipped. A feature positioning statement needs a narrower unit of analysis: one job, one moment of use, one competing alternative.

The classic template — popularized by Geoffrey Moore in Crossing the Chasm and refined by April Dunford in Obviously Awesome — was built for whole products competing in a market category. A feature doesn't compete in a market. It competes for a slice of attention inside a product a customer already uses, against other features, other tabs, and the customer's own workaround.

That distinction matters because of where the failure actually shows up:

• Category collapse: teams write "a tool that helps you work faster," which describes every feature ever shipped.
• Audience blur: "for teams" instead of naming the specific role and trigger moment that make someone reach for this feature.
• Alternative confusion: comparing against a whole competitor product instead of the specific workaround the feature actually replaces (a spreadsheet, a Slack thread, a manual step).

The Job a Feature Positioning Statement Actually Does

A feature positioning statement's real job is to be the single sentence a support article, an in-app tooltip, a release note, and a sales deck all trace back to. Get it right once and every downstream artifact inherits its logic instead of reinventing it.

If you're staging this alongside a fuller launch — not just a single feature update — the sequencing questions (how big a splash, who signs off, what gates a go/no-go) are covered in the complete guide to GTM and launch; positioning is the input those decisions consume, not a replacement for them.

The Fill-in-the-Blank Feature Positioning Template

A feature positioning statement follows six clauses, each answering a question a feature-dump list never forces you to answer: who, when, what category, what outcome, versus what, and why believe it.

Quick Answer: For [target user], who [job/trigger moment], [feature name] is a [category/type of capability] that [key outcome/benefit]. Unlike [current alternative or workaround], it [differentiating proof point].

Walk each clause as its own decision, not a mad-lib to fill mechanically:

Why "Job" Beats "Feature Description" in the Second Clause

The clause that decides whether the whole statement is sharp or generic is the second one — the job and trigger moment — because it's the only clause that can't be copied from your own changelog. Everything else can be reverse-engineered from a spec; this one can't.

A job statement names what the customer is trying to get done, independent of your solution — the Jobs-to-be-Done lens Clayton Christensen and later Tony Ulwick and Bob Moesta formalized as "hire a product to make progress." A trigger moment names the situation that makes the job urgent right now, not just theoretically true.

Weak: "who needs to manage stakeholders" (a permanent trait, true of every PM every day). Sharp: "who is walking into a steering committee update and can't tell who's aligned versus quietly blocking" (a specific moment, with visible stakes).

Before/After: Turning a Feature Dump Into One Sharp Claim

A feature-dump description lists what was built; a positioning statement claims what changes for the user — the same underlying feature can produce either, and only one of them is usable in launch messaging.

Take a realistic example: a stakeholder-tracking feature added to a PM tool.

Before (feature dump):

"New Stakeholder Health feature: tracks sentiment scores, alignment status, last-contact date, meeting history, and relationship strength across your stakeholder list, with color-coded indicators and exportable reports."

That's accurate and exhaustive — and it's also unusable as a headline, a tooltip, or a one-line pitch, because it doesn't say what changes for the reader. It's an inventory, not a claim.

After (positioning statement):

For product managers, who walk into a steering committee update unsure which stakeholders have quietly gone cold, Stakeholder Health is a relationship-tracking view that surfaces who's misaligned before the meeting, not during it. Unlike a stakeholder spreadsheet updated from memory, it flags staleness automatically from actual contact history.

What Changed Between the Two Versions

The rewrite didn't add information — it subtracted four of five capabilities and kept the one that maps to the sharpest job. That's the actual skill: knowing what to leave out, not what to add.

1. Five attributes became one outcome. Sentiment, status, contact date, history, and strength all still exist in the product — the statement just picks the one that resolves the named moment (misalignment surfacing before the meeting).
2. "Tracks" became "surfaces before the meeting." The verb moved from a passive capability to an active, timed outcome.
3. A vague "spreadsheet" became "updated from memory." The alternative clause named the actual failure mode of the workaround, not just its category.
4. The trigger moment appeared at all. The before version had no "when" — the after version opens with one.

Once you have this one sentence, the rest of the launch kit derives from it: the headline restates the outcome clause, the tooltip restates the job clause, the release note can keep the fuller capability list — but only after the one-sentence claim, never instead of it.

How to Source Each Clause From Customer Jobs, Not Internal Specs

The template only produces a sharp statement if its inputs come from how customers describe their situation, not from your feature's technical implementation — swapping the source, not the template, is what separates generic positioning from specific positioning.

Specs describe what a feature does internally: fields, triggers, data sources, UI states. None of that is customer language, and none of it survives contact with a real user conversation. Jobs-to-be-Done language — what progress someone is trying to make, and what's stopping them — maps far more directly onto the "who/need" clauses.

Mapping JTBD Concepts to Positioning Clauses

The table below shows which JTBD concept feeds which clause, so you're not guessing at the translation each time you draft a statement.

The Forces of Progress model (Bob Moesta and Chris Spiek's extension of JTBD) adds a second layer worth mining directly for the "unlike" clause: it separates the push (frustration with the status quo), the pull (attraction to a new way), and the anxieties/habits holding someone back. A feature's differentiation clause is strongest when it directly answers the anxiety, not just the push.

A Quick Self-Check Before You Finalize the Statement

Run the finished statement past three questions before treating it as done — each one catches a different failure mode from the sections above.

• Could a competitor's feature honestly claim this same sentence? If yes, the outcome or alternative clause is too generic.
• Does the "who" clause name a moment, not a trait? If it's true of the user every day, it's not a trigger.
• Would a support agent be able to use this sentence verbatim in a help article? If the language is internal jargon, it hasn't been translated into customer terms yet.

Where Feature Positioning Fits Into the Rest of Launch Prep

A feature positioning statement is an input to launch planning, not the whole plan — it tells you what to say, while separate decisions determine how loudly and to whom you say it.

Once the statement is solid, two adjacent decisions typically follow. First, how big a launch this feature warrants — a minor capability doesn't need the same treatment as a flagship one, which is exactly what a launch tiers framework exists to sort out, and choosing the right launch tier walks through that call in more detail. Second, who owns turning the statement into channel-specific copy — the PM-to-PMM handoff is where a clean positioning statement either saves everyone time or, if it's vague, gets rewritten from scratch by whoever inherits it.

It's also worth checking the statement against where the trigger moment sits in the broader customer journey — a feature positioned around a moment that happens once a quarter needs different messaging cadence than one tied to a daily habit.

Sourcing Real Job Language With Prodinja's Customer Jobs Analysis

The studio walks you through defining functional job statements, running Ulwick-style opportunity scoring to see which jobs are both important and underserved, and mapping push/pull/anxiety forces per job. Because it's structured around the same clauses a positioning statement needs, the output — a job statement in the customer's own words, ranked by opportunity score — is something you can lift close to verbatim into the "for [who], who [need]" clauses, rather than translating loosely from a spec or a hunch about what users want.

Key Takeaways

• A feature positioning statement is a single sentence, not a capability list — for [who], who [job], [feature] is a [category] that [outcome], unlike [alternative], it [proof].
• The "who/job" clause is the hardest and most important one — it needs a specific trigger moment, not a permanent trait or role description.
• Source clauses from customer jobs, not specs — JTBD job statements and Forces of Progress translate directly into the who, need, and "unlike" clauses.
• The before/after skill is subtraction, not addition — a sharp statement keeps one outcome and cuts the rest, even though the other capabilities still exist in the product.
• The "unlike" clause should name the actual workaround a customer uses today, not a competitor's whole product.
• Positioning is an input, not the whole plan — launch tier, PMM handoff, and journey placement are separate decisions that consume the statement once it's written.