Skip to content
LearnField guide

Field guide · 6 min read

How to write a positioning statement

A practical guide to choosing your audience, alternative and value—then turning those choices into a draft you can test.

By Product Statement · Updated · Editorial method

The draft comes after the decisions.

A positioning statement is a compact record of who your product serves, the situation it helps with, and why someone would choose it over an alternative. It gives your team something concrete to discuss. Use it to spot disagreements and decide what to investigate next.

Keep three layers separate: positioning is the set of market choices; the statement records those choices; messaging expresses the relevant value to a customer in a particular context.

Before drafting, collect notes from recent customer conversations, examples of the current workflow, and what people tried before. For an unlaunched idea, mark assumptions as assumptions. You can make a draft with incomplete knowledge; you should be able to say which parts still need evidence.

Make the key decisions visible.

  1. Name the current alternative. If your product disappeared, what would this person do? A spreadsheet, an assistant, a competitor, or leaving the problem unsolved can all be valid answers. Start with observed behavior.
  2. Find a useful difference. Describe a capability you can demonstrate against that alternative. “Easy to use” needs an explanation of which task becomes easier and how.
  3. Connect it to an outcome. Ask what changes in the customer’s work. A dashboard is a feature; knowing which customers need a follow-up is a useful outcome. Avoid numerical promises you cannot support.
  4. Narrow the audience. Choose people for whom that difference matters. “Small software teams with support and engineering handing bugs back and forth” gives you a more useful starting point than “all businesses.” The user, buyer and approver may differ; record those roles alongside the draft.
  5. Choose a category people understand. The category sets expectations about what you do. “Issue tracking software” gives buyers a familiar starting point. “For support-to-engineering handoffs” explains the product’s particular role.

Compare that with “bug handoff workspace”: the narrower phrase names the task, but a buyer may have to ask what kind of software it is. A familiar category makes the offer easier to place; a descriptor helps set its boundaries. For Patchwork, we combine the two and explain that it works with an existing engineering tracker. Ask prospective users what capabilities they expect from the label you choose.

This sequence is informed by April Dunford’s positioning primer, which connects alternatives, capabilities, value, customers and category. Dunford also cautions that filling in a statement cannot make these decisions for you. Our worksheet records your decisions; it does not replace that work.

Choose the structure that helps you think.

Compare: make an alternative explicit

Use Compare when you can name what customers do today and explain a useful difference. Each labelled line records one decision. Write a phrase or a sentence in your own words; the structure keeps the audience, value and difference easy to review separately.

Product name: [Product name]
Audience: [Audience]
Audience need: [Audience need]
Category: [Category]
Value promise: [Value promise]
Alternative or competitor: [Alternative or competitor]
Key difference: [Key difference]

Customer focus: separate the pain from the outcome

Use Focus to document a specific customer struggle and the intended change. It is useful when the alternative still needs investigation. It leaves differentiation open, so return to that question before treating the draft as a full positioning decision.

Product name: [Product name]
Audience: [Audience]
Category: [Category]
Customer struggle: [Customer struggle]
Desired outcome: [Desired outcome]

Keep the value promise and difference distinct. “Support knows which customers to notify” describes the outcome. “Each report stays linked to its engineering ticket” describes the capability that makes it possible. The builder preserves your wording in a structured statement you can copy or export as a card.

Replace broad claims with specific work.

Fictional teaching example · Patchwork

Patchwork is a powerful solution for every team that wants to be more productive.

This draft gives a reader little to recognize: no particular workflow, current alternative, or reason to switch.

Product name: Patchwork Audience: small software teams managing customer-reported bugs Audience need: Give support a reliable answer on what has been fixed. Category: issue tracking software for support-to-engineering handoffs Value promise: Support knows which customers to notify when a bug is fixed. Alternative or competitor: a shared spreadsheet and chat threads Key difference: Each customer report stays linked to its engineering ticket and resolution.

The revision identifies a handoff between support and engineering. Its difference is the link between report and resolution. The next question is whether that link solves a costly handoff problem or merely duplicates an integration the team already uses.

Adapt the fictional draft

Use the draft to find what you don’t know.

Read it aloud with a colleague. Ask them to describe who it is for, what it does and what it replaces. If those answers differ from your intent, simplify the draft before designing a campaign around it.

Then speak with people in the proposed audience. Ask about the last time the problem occurred, how they handled it, who was involved and what it cost them in effort. Ask them to show the workflow if they can. “Would you use this?” can produce polite agreement without evidence of a real need.

  • Audience check: can you identify and reach people who face this situation?
  • Alternative check: does the named alternative match what they actually use?
  • Value check: does the outcome matter enough to change behavior?
  • Proof check: can you demonstrate the useful difference?
  • Language check: do customers understand the category without an explanation?

Keep a short evidence log: assumption, observation, source, date and next decision. If conversations reveal a different problem, revise the choices before revising adjectives.

References and a next exercise

April Dunford: A Quickstart Guide to Positioning supplies the strategic context above. The exercises and fictional product are original teaching material. Source checked 1 October 2026.

Next, compare a statement, a value proposition and a tagline, or follow the full software-product walkthrough.

Put the decisions into words.

Use your own inputs to make a working draft. Then test its assumptions with prospective customers.

Open the free builder

Explore the learning collection →