All posts
GTM

Positioning Framework I Use for Clients

By Beatriz7 min read

[!note] Key takeaway: if a buyer cannot tell when you are the right choice, your positioning is still incomplete.

Pen and paper positioning framework

Most teams start positioning too late and too superficially.

They open a doc, write a positioning statement template, argue about adjectives, and call it done. Then the homepage sounds polished but vague, sales decks drift by segment, and no one can explain why the company wins except the founder.

The framework I use is built to prevent that. It forces one strategic answer: why this buyer should choose this product in this situation instead of the most likely alternative.

What inputs do I gather before I write a positioning statement?

I want five inputs first:

  • -->customer language from calls, interviews, or support threads
  • -->current competitor claims and category labels
  • -->product strengths the team can actually defend
  • -->objections that block deals
  • -->proof assets already available or missing

Positioning without evidence becomes aspiration. That is why so many positioning exercises collapse the second they meet a real sales call.

I also want clarity on the alternative. That does not always mean a named competitor. Sometimes the real alternative is:

  • -->doing nothing
  • -->hiring a consultant
  • -->using spreadsheets
  • -->stitching together internal workflows

If you do not identify the true alternative, you will position against the wrong enemy.

How do I structure the positioning itself?

I keep the working framework simple:

  1. -->buyer
  2. -->painful problem
  3. -->current alternative
  4. -->differentiated outcome
  5. -->proof

That is the strategic skeleton.

The polished statement can come later. First I want the team aligned on the underlying choices.

Example:

  • -->buyer: security leaders at cloud infrastructure startups
  • -->problem: too much manual investigation time on noisy alerts
  • -->alternative: current SIEM workflow plus analyst labor
  • -->differentiated outcome: faster triage with context preserved inside the existing workflow
  • -->proof: pilot data showing time-to-resolution improvement

That is already better than "AI-powered security for modern teams."

How do I find the real differentiator instead of writing generic claims?

The differentiator has to pass three tests:

  • -->true: can the product and team actually deliver it?
  • -->important: does the buyer care enough for it to affect choice?
  • -->specific: can someone outside the company understand what it means?

A lot of teams fail on the third test. They say things like:

  • -->"intuitive UX"
  • -->"better collaboration"
  • -->"AI-powered workflows"
  • -->"enterprise-ready"

Those are not differentiators. They are filler unless you can anchor them in a buyer decision.

I usually push teams toward one of these sharper forms:

  • -->faster outcome for a named workflow
  • -->lower risk in a constrained environment
  • -->better visibility in a problem area buyers already monitor
  • -->smoother adoption because the tool lives in an existing system of record

That last one matters more now than it did two years ago. If the product fits naturally into the workflow where the decision happens, the positioning becomes more credible. I unpack that pattern on the developer-tools side in The AI Winner Won't Be the Best Chatbot. It'll Be the Product Closest to the System of Record.

How do I pressure-test a positioning draft before rollout?

I use four checks:

  • -->Can sales repeat it without translation?
  • -->Can a prospect self-identify from the wording?
  • -->Can we support the claim with proof today?
  • -->Can a competitor say the exact same thing?

If the answer to the last question is yes, the work is not done.

This is also where I test constraint language. Strong positioning includes what the product is best for and, when useful, what it is not best for. Constraint builds trust because it helps buyers qualify faster.

How do I turn positioning into messaging teams can actually use?

Once the positioning is stable, I translate it into:

  • -->homepage message hierarchy
  • -->sales deck narrative
  • -->objection handling
  • -->launch or campaign copy
  • -->proof assets and case-study asks

Positioning is the decision logic. Messaging is the distribution layer.

If your messaging work feels stuck, it is often because the strategic layer is underdefined. That is why I separate this framework from the execution workflow in Messaging Strategy: From Research to Launch.

For products selling into technical buyers, docs and product pages also need to carry the same narrative. Otherwise the brand promise lives on the homepage and disappears everywhere else. Your Docs Are Your Sales Deck goes deeper on that problem.

What mistakes show up most often in client positioning work?

The patterns are predictable:

  • -->trying to serve multiple ICPs with one line
  • -->positioning around product features instead of buyer decisions
  • -->copying competitor language because it sounds familiar
  • -->skipping proof until late in the process
  • -->treating the category label as the strategy

The fix is usually simplification, not invention.

Positioning gets better when teams make harder choices about audience, use case, and proof.

Bottom line

The best positioning work does not make a company sound smarter. It makes the buyer's choice easier.

Identify the buyer. Name the painful problem. Compare against the real alternative. State the differentiated outcome. Support it with proof.

That is the framework I use because it survives contact with actual go-to-market work.