One Product, Different Customer Groups: Change the Positioning or the Example?
One Product, Different Customer Groups: Change the Positioning or the Example?
A hypothetical product team, Fieldnote, builds a review tool. It shows two versions of a document side by side, highlights what changed, and collects comments in one place. Two customer groups want it.
A six-person training company uses Fieldnote to compare a client's draft e-learning module with the version that was approved last month. An internal learning department at a large firm wants the same comparison — and also a formal sign-off record that Fieldnote does not currently produce.
The instinct is to write a second pitch deck. The better first move is to compare what each group is actually trying to do, not what each group is called. Different customer labels are cheap. Different tasks, alternatives and constraints are the real question, and they decide whether you need new wording or a different product.
Everything about Fieldnote — the company, the two groups, the evidence conditions — is invented for this essay. No real segment performance, product-market fit or expansion has been established.
Compare actual work before comparing customer labels
Start with a row for each group and four columns: the task, the current alternative, the capability that decides the outcome, and the evidence you actually hold.
Group 1: Independent training teams
Task. Compare a revised module against the last approved version, find every content change, and send the client a short list of what moved.
Alternative. A PDF markup tool, two screens, and a spreadsheet of change notes.
Deciding capability. Version comparison that catches a changed quiz answer, not just changed paragraphs.
Evidence. Six interviews with training leads describing this exact task; three of them already run side-by-side comparisons manually. This is an invented evidence condition, stipulated for teaching — not collected or verified.
Group 2: Large internal learning departments
Task. Compare a revised compliance module against the approved version, then route the comparison to a named approver who signs off before the module goes live.
Alternative. Fieldnote would replace the manual comparison, but the sign-off still happens in email and a tracking system.
Deciding capability. A locked approval record that shows who signed, when, and against which version.
Evidence. Two conversations in which the approval requirement came up unprompted. Also invented and stipulated; two conversations are not evidence of demand at scale.
Now put the rows next to each other. The comparison tasks are close cousins: both groups look at two versions and care about substantive change. The approval requirements are not cousins at all. Group 1 treats the comparison as the end of the work — the output is a list a person sends. Group 2 treats the comparison as the middle of the work; the value only completes when an authorized person signs a locked record.
That difference is not a vocabulary difference. It changes what happens after the comparison is made, who else touches the product, and what "done" means.
One caution as you read the rows: keep a reported task separate from a proposed application or a stated willingness to pay. "Training leads told us they compare drafts manually" is a report of what interviews described, not a behavior we observed. "Training leads will pay for automated compliance tracking" is a proposal about future behavior — and no row above supports it, since Group 2's recorded item is only that an approval requirement came up unprompted in two conversations. In the invented evidence above, the manual comparisons are a reported task; that unprompted approval requirement is a proposal. The two carry different weight, and the Evidence column should say which is which.
Keep common positioning where the value mechanism is shared
The two groups share a comparison task but diverge on approval. That is a partial overlap, which is the hardest case. It is worth testing whether a single explanation survives.
April Dunford's practitioner guidance makes a related distinction: shared differentiated value can take tailored segment content, while divergent needs can raise product-strategy questions. That framing is not evidence of Fieldnote's fit or expansion.
Write the common mechanism first, without naming either group:
Fieldnote shows you what changed between two versions of a document and collects the comments in one place, so review doesn't depend on someone's memory of last month's draft.
That sentence is true for both groups. It names the intervention (side-by-side version comparison) and the relevant alternative (relying on memory or manual cross-checking). If the mechanism is shared, the opening stays shared.
Now tailor the evidence — not the mechanism:
- For training teams: "When you revise a client module, the quiz answer on slide 14 is the thing most likely to move without anyone noticing. Fieldnote catches it. Here's the comparison from a recent revision."
- For learning departments: "When a compliance module is revised, your reviewers need to see exactly which items changed before anyone routes it for sign-off. Fieldnote produces that comparison."
The capability described is identical. What changes is the demonstration and the vocabulary. One group hears "client module," the other hears "compliance module," and both hear the same promise: see the change, keep the comments.
Avoid multiplying propositions just because the examples look different. If you find yourself writing a new headline for every group, check whether the value mechanism actually changed or whether you have only changed the nouns. A new headline costs you a new page, a new proof point, and a new reason for the reader to wonder which version is true.
At the same time, do not force the shared story when it hides a materially different adoption requirement. That is exactly what Group 2's approval control is. If the group cannot finish its work with your product, a common explanation makes the product sound simpler than it is — and the reader discovers the gap later, in a trial or a procurement call.
The test is concrete: name the step being replaced and the mechanism that replaces it, and ask whether both groups are replacing the same thing with the same thing. If yes, shared positioning with tailored examples carries the common claim — with a divergent capability such as Group 2's approval record named as a product question beside it. If the second group is replacing a different process with a different output, you are past copy.
Recognize the product decision a new deck cannot solve
Look again at Group 2's row. The task does not end at "find the changes." It ends at "get a named approver to sign a locked record against a specific version." Fieldnote has comparison and comments. It has no approval control, no role permissions, no audit trail.
A better introduction cannot close that gap. Nor can a customer story in which someone says the comparison "made sign-off much easier" — if sign-off still happens in email, the story is about a different step. Rewriting the opening line changes how the product is described. It does not add a capability.
This is where positioning work tips into product-strategy work. Two defensible paths exist:
Path A: Extend the product. Treat the approval control as a development hypothesis: build a locked sign-off record, then test whether the large-department task actually requires it. Until that test produces evidence, describe the capability as planned, not present.
Path B: Keep the product as it is. Let Fieldnote complete the comparison and hand the output to whatever approval system the customer already uses. If that division of labor is acceptable to Group 2, the shared positioning survives and the approval control becomes an integration question rather than a missing feature.
What you must not do is present the strongest properties of both possible paths as though one existing product serves both groups equally. "Fieldnote compares versions and supports approval workflows" is true only if the workflow exists. A deck that implies it can carry you through a meeting and cost you the account in the next one.
Distinguish the two paths carefully. Path A is a product-development hypothesis — a bet that should be labeled as a bet. Path B is an already supported offer, if the customers accept the handoff. They are not the same claim and they do not belong in the same sentence without qualification.
Choose a scope that matches the uneven evidence
The evidence is not symmetric. Group 1's comparison task is supported by the invented interviews and the manual workarounds. Group 2's approval requirement is supported only by two conversations and a product gap.
That asymmetry should be visible in the pitch, not smoothed away.
Here is the focused version:
Headline: See what changed between two versions of your document, and keep the comments in one place. Primary audience: training and content teams who revise documents for clients or internal stakeholders. Proof: comparison demonstrations from revision work; a training lead describing the manual cross-check they used to run. The large-department need: "Teams with a formal sign-off requirement can export the comparison into their existing approval process. Deeper approval support is on our roadmap; talk to us if that's a blocker."
And the broader version:
Headline: See what changed between two versions, keep the comments in one place, and give reviewers a clear record of the changes that need attention. Primary audience: training teams and internal learning departments. Proof: the same comparison demonstrations, plus the two early conversations about approval routing — labeled as early conversations, not as outcomes. The approval gap: stated plainly, with the roadmap item named.
The focused version is more defensible. It makes one group's evidence carry the main claim and treats the other group as an explicit hypothesis for investigation. Its cost is breadth: it communicates less ambition and may look like the product serves only small teams.
The broader version preserves ambition, but it carries uncertainty and extra proof needs. Its risk is that a reader hears "clear record" and assumes a completed approval feature. The qualification must be load-bearing, not buried in a footnote.
Either way, keep each result attached to the group and conditions that produced it. A training lead's manual comparison says something about training teams. It says nothing about whether a large learning department will adopt Fieldnote, because the department's work does not end where the training lead's work ends. One testimonial does not validate the whole expansion. It validates one step for one group.
The choice between the two scopes is not a style choice. The focused version says: our evidence is where our pitch is. The broader version says: our pitch is where our ambition is, and we accept that part of it is unproven. Both are honest. Confusing them is not.
What to decide
The Fieldnote example is invented, and the evidence conditions are stipulated for teaching. But the decision structure transfers to real work.
Compare the tasks and the alternatives before comparing the customer labels. Keep the common explanation when both groups are replacing the same step with the same mechanism; tailor the demonstrations and the vocabulary instead. A divergent deciding capability or a divergent alternative is the signal to name a product question alongside the shared claim, not a reason to discard it. When a group needs a missing capability or a different reason to adopt, name that as a product question, not a copywriting question. And when the evidence is uneven, let the scope show it — a focused pitch on the evidenced group with another group held as a hypothesis, or a broader pitch that carries its uncertainty in plain sight.
The unresolved question is the useful one: does Group 2's approval requirement belong in Fieldnote, or does Fieldnote end at the comparison and hand off? That is not something a positioning exercise can answer. It is a product decision wearing a positioning question's clothes. The most valuable thing the comparison table can do is make that visible before anyone writes the second deck.
A wider audience claim should never borrow certainty from the narrow case. When the table shows that the shared mechanism is real but the evidence and capability are uneven, the honest move is to keep the shared explanation, state the gap, and let the product question stay open until someone answers it.
Frequently asked questions
When can one product use shared positioning across different customer groups?
When both groups are replacing the same step with the same mechanism. Fieldnote's comparison task is shared, so the opening can stay shared; the demonstrations and vocabulary can be tailored. If the second group is replacing a different process with a different output, the issue is past copy.
What signals that a new pitch deck cannot solve the problem?
A divergent deciding capability or alternative does. In the example, the large learning department needs a locked approval record showing who signed, when, and against which version, and Fieldnote does not produce approval control, role permissions, or an audit trail. Rewriting the opening changes how the product is described; it does not add a capability.
Why compare tasks before customer labels?
Labels are cheap. The real question is what each group does, what it uses now, which capability decides the outcome, and what evidence exists. The training teams treat comparison as the end of the work, while the learning department treats it as the middle of the work and needs sign-off before the module goes live.
How should uneven evidence affect the pitch scope?
Let the scope show it. A focused version can make one group's evidence carry the main claim and treat the other group as an explicit hypothesis; a broader version preserves ambition but carries uncertainty and extra proof needs. A wider audience claim should not borrow certainty from the narrow case.
Are the Fieldnote customer groups and evidence real?
No. Fieldnote, the two groups, and the evidence conditions are invented for the example. The manual comparisons are described as a reported task, while the unprompted approval requirement is a proposal; two conversations are not evidence of demand at scale, and no real segment performance, product-market fit, or expansion has been established.