Positioning is the answer to “what is this, who is it for, and why should I care” — delivered in the first ten seconds, in language the reader already uses. For developers, weak positioning isn’t just ineffective; it’s a trust penalty. Vague adjectives (“powerful”, “seamless”, “next-generation”) signal that you’re hiding something or don’t understand your own product.

It assumes you have already decided who you are selling to: the developer who evaluates and the person who pays are different readers, and a positioning that tries to address both at once addresses neither. This section is about the claim itself. The website is about where it lands on the page, and pricing about the one number the claim has to survive.

Start from the job, not the category buzzword

Developers evaluate tools by the job to be done: “send transactional email”, “add auth without building it”, “search across my data”. Name that job plainly. The fastest positioning test: can a developer read your homepage headline and correctly guess what the first API call does? If not, rewrite it.

Borrow the discipline of category design when a real new category exists — but most products slot into a job developers already understand. “Stripe for X” clarity beats “reimagining the future of Y” every time.

The three questions every technical buyer asks

  1. Does it actually work? Show it. A live code sample, an interactive playground, a real benchmark with methodology. Claims without evidence are noise.
  2. Will it lock me in or slow me down? Developers price in switching cost and operational risk. Be explicit about standards support, export, self-hosting, and how you fail. Openness is a positioning asset — and that includes the price: a legible number on the page is a trust signal, “contact sales” reads as something to hide. What the number should look like, and why the training-data policy now belongs beside it, is pricing’s subject.
  3. Who else uses it, and were they glad? Logos matter less than a credible engineer saying “we run this in production and here’s what happened.” Peer proof outranks vendor proof — and verifiable proof outranks both. A logo wall shows someone signed once; a live weekly-download count, a public star-history graph, or a deploy counter shows the thing is used, and a developer can go check the source. Prefer current, reproducible numbers to social proof they have to take on faith.

There is a fourth question, and the developer does not ask it: what does this replace, what does it cost at scale, who is accountable when it goes down. That is the buyer’s question, and arming the developer to answer it in a meeting you are not in is covered in the developer, the buyer and the job.

Write for the skeptic, not the champion

Your best distribution is a developer forwarding your page to their team with “this looks legit.” That happens when the copy respects them: concrete nouns, real numbers, honest scope. Name what you don’t do. Counter-intuitively, stating limitations up front increases trust and reduces the support and churn cost of mismatched expectations.

Narrative and voice

Positioning says what you are; narrative says why the world needs you to exist, and voice is how both sound out loud. Developers are not immune to either — they are immune to it being fake. A strategic narrative that names a real shift the reader has felt (“infrastructure moved to the edge and your database did not”) does work that a feature list cannot, because it tells them which side of a change they are on.

Voice is the cheaper and more neglected half. Pick a register your own engineers would use in a design doc and hold it everywhere — docs, error messages, release notes, the 404 page. Consistency is what makes a company recognisable without its logo, and inconsistency is what makes a well-positioned product feel like three companies wearing a trench coat. The reliable test: could a reader tell it was you with the name removed? If every sentence could have come from any of your competitors, you have a category description, not a voice.

Test it before you ship it

Positioning is testable in days, and most teams treat it as a quarterly offsite instead. The research that feeds it — reading how developers describe the problem in their own posts, asking your best users what they were doing before — is the audience section’s job. Once you have a candidate, two cheap tests settle most arguments:

  • The five-second test. Show the homepage to five developers outside the company for five seconds, then ask what it does and who it is for. Getting a consistent wrong answer is more useful than getting no answer.
  • Ship two versions. For anything with traffic, the headline is the cheapest thing on the page to test and the most consequential thing to get wrong.

None of this requires a research budget or a quarter. A week of it before a rewrite beats a year of arguing about adjectives internally.

Anti-patterns

  • Adjective soup. If deleting every adjective leaves the sentence just as informative, the adjectives were doing no work.
  • Marketing-speak the product team wouldn’t say. If your own engineers cringe at the homepage, developers will too.
  • Hiding the product. “Contact sales to see pricing/docs/the API” tells a developer you’re not for them. Let them read, try, and self-qualify.

Positioning is upstream of everything else in this guide. Get it wrong and even great docs and DevRel are pushing the wrong message efficiently.