--- title: Positioning, narrative and voice canonical: https://thebeat.dev/guide/positioning/ updated: 2026-09-02 part: foundations order: 2 collection: guide site: https://thebeat.dev/ license: https://creativecommons.org/licenses/by/4.0/ --- # Positioning, narrative and voice > What you are, in the reader's words, in ten seconds — the three questions a skeptical engineer asks, why clarity beats adjectives, the narrative and voice that make a company recognisable, and the cheap tests to run before you ship a headline. 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](/guide/the-developer-and-the-buyer): 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](/guide/website) is about where it lands on the page, and [pricing](/guide/pricing-and-packaging) 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](/guide/pricing-and-packaging) 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](/guide/the-developer-and-the-buyer). ## 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](/guide/the-developer-and-the-buyer) 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. --- Part of [The Beat — developer marketing, on the record](https://thebeat.dev/). Content license: CC BY 4.0 — quote it, link the canonical page.