Product Positioning

Four minutes into Solveig's demo of Pebblecrane Review, the buyer unmutes. "So can it assign tasks to my team?" Solveig glances at the slide behind her.

Solveig and Pebblecrane Review are invented for this lesson. Her slide says "project management software," while the product helps small architecture practices collect drawing comments and keep a record of the version a client approved.

Start with the alternative already on the desk

Her cofounder wants the homepage to say "The future of creative collaboration." That line fits almost any product, including the one the buyer already owns. So the work starts with a plainer question: what would this practice use if Pebblecrane didn't exist?

For a small practice, the answer may be a shared folder and a chain of emails. The team and its clients already know both, and nobody has to approve a new subscription.

Calling that arrangement broken won't make Pebblecrane more convincing. Describe where it gets hard instead, like several clients commenting on different versions of the same drawing.

The article "Positioning and Competition" counts the status quo alongside the products on a buyer's shortlist. One example is paying an intern to do the job by hand. Ask whether your buyer is comparing software vendors or deciding whether to keep that manual process.

Ask recent buyers what they used before and what set off their search. Ask the people who said no what they kept using. Voice of customer research helps you recover that sequence without handing people a list of competitors to agree with.

Alternatives to check for Pebblecrane Review

An email thread and shared folder

• Already familiar to clients
• Comments can refer to different versions
• Someone must reconstruct the approval record

A general project management tool

• Connects reviews to other project work
• May require clients to learn the workspace
• Drawing-specific review depends on its actual features

Those columns are assumptions for the example, so swap them for workflows you've watched. If most of Solveig's prospects already own an approval tool, her page needs a different argument from one written for teams living in email.

Make the differences earn their place

Solveig lists what Pebblecrane does that the shared folder leaves someone to handle. Each difference needs a demonstration before it earns space in the brief.

Suppose a Pebblecrane reviewer can comment on one specific drawing version, and the practice can export the approval history. "Online comments" alone barely separates it from a general tool.

An exported, version-linked approval record gives a project lead something to open when a client asks what was approved. Put that task beside the capability in the brief. Claiming fewer disputes would need evidence about disputes, however good it looks in a headline.

Connect the difference to the buyer's task

1. Alternative: email comments across drawing versions
2. Capability: decisions attached to the reviewed version
3. Useful consequence: retrieve the decision with its drawing
4. Best-fit situation: a practice managing several client reviewers

"A Quickstart Guide to Positioning" links competitive alternatives, differentiated capabilities, customer value, best-fit customers and market category. Use those links to test your reasoning. Does the difference survive comparison, and does this buyer care enough for it to matter?

Keep the capability descriptions tied to something you can demonstrate. Open a drawing version and retrieve its decision record while someone from product checks the steps.

Which customer situation can you serve well?

"Small businesses" tells a writer almost nothing about why Pebblecrane deserves attention. Try "architecture practices that send several drawing revisions to outside client reviewers." That names a workflow and gives a version-linked record a reason to exist.

A solo architect with one decisive client may find email perfectly fine. A larger practice may need access controls Pebblecrane doesn't offer.

Solveig adds two questions to the brief: "Who comments on each revision?" and "How do you retrieve the client's decision?" The answers can help her decide whether to show the approval history or acknowledge a poor fit.

Strategyzer's Value Proposition Canvas matches the jobs a customer is trying to get done, with the pains and gains around them, to what you offer. Its page puts the limit plainly: a fit stays a claim until customers confirm it.

Pick a frame that creates accurate expectations

Salesforce chose its comparison in public. At its February 7, 2000 launch in San Francisco, it called the event "End of Software," setting its service against the installed software buyers already knew.

A market category hands the buyer a starter set of assumptions. "Drawing approval software" suggests a different job from "project management software," even if both have comments and file uploads. Someone expecting drawing approval will look for markup and an approval history.

Under each candidate category, write the features a buyer would expect. Cross out any frame that would make you spend five minutes of the demo explaining what you lack.

Record the expected feature beside the product evidence.

The category changes the questions buyers ask

A prospect evaluating project management software may ask about task dependencies and staff scheduling. Check whether you can demonstrate either before using that category.

"Drawing approval software for small architecture practices" works if Pebblecrane meets those expectations. Check what prospects mean by approval, because some may expect a legally binding signature. "A client review workspace for architectural drawings" may be clearer if approval is only one part of the job.

Before inventing a category, try a familiar name with a specific audience. For this example, Solveig chooses "drawing approval software" because tracking the client's decision is the central job. "Client review workspace" is a broader description she can use in supporting copy.

Solveig's brief, before and after the task question

Brief behind the first slide

Category: project management software. Audience: architecture practices. Difference: online comments on drawings.

Brief after "Can it assign tasks?"

Category: drawing approval software for small architecture practices. Difference: comments and the client's approval tied to one drawing version. Objection to answer early: Pebblecrane doesn't assign tasks, so the demo opens on the approval history.

Confirm with the product team that task assignment is out of scope before the brief reaches a sales deck.

A working position for Pebblecrane

audience

Small architecture practices coordinating external drawing reviewers

alternatives

Shared folders and email, plus general project workspaces actually considered

differentiator

Drawing comments and approval decisions tied to a specific version

value

Retrieve the approval record beside the drawing it concerns

proof

Demonstrate a review, a revision, an approval and an exported history

Translate the position into copy decisions

Use the brief to choose the product category and the evidence you'll show on the homepage. Keep the audience definition in the working record so the team can check it against prospects' actual situations.

Set the cofounder's line beside a concrete first screen: "Keep drawing approvals attached to the right version."

The supporting sentence can name the audience and the record: "A client review workspace for small architecture practices, with an exportable history for each drawing version." Each line now has a job the designer can support.

Pick the screenshot the same way. It should show a drawing version beside its approval record. A photo of a cheerful team around a table would leave the hardest part of the argument to the words.

Copy after choosing the frame

An undefined promise

The future of creative collaboration.

The draft leaves the product category, audience and specific value unresolved.

A specific product job

Keep drawing approvals attached to the right version. A client review workspace for small architecture practices.

The revised copy gives readers a job and a category they can assess, and it claims no measured business result.

The value proposition lesson develops the buyer-facing statement, and messaging hierarchy arranges its supporting claims.

If a reader understands the product and still sees no reason to switch, ask what their current setup already does well. Compare that answer with the improvement your brief claims.

Test the comparison, then record the choice

Show a candidate description to people in the buying situation. Ask what they think it does and what they'd compare it with. If someone still expects task assignment, find the word that put it there.

Understanding a message is a long way from wanting the product. A comprehension interview can expose confusion. Use purchase evaluations and win-loss conversations to check whether the difference affected a decision.

Save the chosen audience, alternatives, difference and category in one dated brief, with someone from product or sales who can confirm each claim. Revisit it when the product or the deals change, and leave it alone when a campaign just feels tired.

Once the competitive context is clear, market sophistication helps you ask whether familiar category claims still set the offer apart.

Test the category against the capability

Take the description you're using now and write next to it what a buyer would expect it to do. Mark what you can demonstrate, and carry any gap into your next call with a prospect. You can keep going through Positioning with that list open.

Solveig's next slide reads "Drawing approval software for small architecture practices." As she reaches the review screen, the buyer unmutes.

"Can you show me which version the client approved?" Solveig opens the drawing's history.