How to Position
a Developer Tool.
Positioning for developer tools follows the same discipline as positioning anything else — and then ignores half the SaaS playbook. A practitioner walkthrough of the four inputs, the worked example, the common mistakes, and how to know your statement is doing its job.
By Daria Dovzhikova · Updated May 2026
TL;DR
- Positioning is the answer to: who is this for, what is it instead of, and why does it matter. For developer tools, the "instead of" is usually an OSS library or a hand-rolled internal tool.
- Four inputs build the statement: competitive alternatives, unique attributes, value, target market. Skip the customer interviews and the rest is guesswork.
- Positioning is not the hero copy. It is the internal document the hero copy compresses. Write the document first.
What "positioning" means for developer tools
Positioning is the deliberate choice of how a product shows up in the minds of the people who could buy it. It answers three questions. Who is this for. What is it instead of. Why is it worth their time. Everything else (hero copy, decks, ads, demos) is a downstream artifact of those three answers.
For developer tools the questions get sharper. The buyer is the technical user, who evaluates hands-on in a free tier or local install before anyone signs a contract. The "instead of" is rarely a direct competitor; it is usually an OSS library, a hand-rolled internal tool, or the status quo of accepting the pain. The "why bother" has to survive a docs page being read at 11pm on a Tuesday by someone who has already tried two alternatives.
April Dunford's book Obviously Awesome is the canonical reference on positioning as a deliberate discipline. The mechanics in this guide follow her five-component model and adapt it to the developer-evaluator. If you want the source text, read the book; if you want the developer-tool specifics, keep reading.
The four inputs to a positioning statement
Skip any one of these and the statement collapses under sales pressure. Each input is a research output, not an opinion.
Competitive alternatives
Not just direct competitors. The OSS library someone could glue together over a weekend. The status quo of doing nothing. The internal tool the team already built. For developer tools, the alternative is often build-it-yourself; if your positioning does not address that, the sales call dies in the first five minutes.
Unique attributes
Capabilities your product has that no alternative does. Not features, capabilities. A specific protocol you implement. A latency floor. A language coverage matrix. A type of failure mode you prevent. These have to be technically true and verifiable in the docs.
Value (the so-what)
The downstream outcome the unique attributes enable. Developers do not buy capabilities, they buy outcomes the capabilities make possible: deploys that do not page you at 3am, debugging sessions that finish before lunch, an API integration that ships before the deadline. Stay specific. Generic value language is the fastest way to lose credibility.
Target market characteristics
The kind of team that gets the most value, fastest. Stack, scale, problem severity, team shape. Developer tools work for the audience whose problem your unique attributes happen to solve. Naming that audience explicitly is how you stop trying to sell to everyone with a keyboard.
The research method that fills these inputs is the same one every functioning PMM team uses: 8-12 interviews with users who bought (or actively chose not to buy), open-ended, recorded, transcribed, coded for patterns. The positioning framework walks through the interview script and the coding pass.
How positioning differs for dev tools vs SaaS
The discipline is the same. The artifacts diverge in three ways.
First, the evaluator. B2B SaaS positioning is consumed by an economic buyer reading a one-pager. Developer-tool positioning is consumed by an engineer reading the README at 9pm. The statement still gets written; the externalization is technical content, not a one-pager.
Second, the proof. SaaS positioning leans on logos, analyst slots, and ROI math. Developer-tool positioning leans on a quickstart that runs, a benchmark with a methodology, a sample app on GitHub, a docs page that explains the why behind the API surface. Logos help; they do not substitute.
Third, the channel where positioning gets tested. A SaaS positioning statement gets tested in a sales call. A developer-tool positioning statement gets tested in a Hacker News thread, a Reddit comment, a thread on the team's Slack. The audience is more verbal, more skeptical, and answers in public. That is good news (the feedback loop is faster) and bad news (positioning fluff gets called out within hours).
A worked example
Take a hypothetical observability product. The team is tempted to position it as "the modern observability platform". That language fails on all four inputs.
Competitive alternatives: not other observability vendors, but the homegrown Prometheus + Grafana stack the engineering team already runs. Unique attributes: out-of-the-box trace stitching across async boundaries, sub-second p99 query on a year of retention. Value: on-call engineers find the root cause in one query instead of seven. Target market: 30-200 person engineering teams running async microservices in production who have outgrown their hand-rolled stack but cannot justify a six-figure Datadog bill.
Compressed into a positioning statement: For mid-stage engineering teams who have outgrown their Prometheus + Grafana stack, [Product] is the observability platform that stitches async traces and answers a year of high-cardinality queries in under a second, so on-call engineers find root cause in one query instead of seven.
That is not the hero. The hero is the 8-word compression of that statement. But the statement is what every downstream artifact gets checked against. If a piece of content does not derive from a phrase in that statement, it does not ship.
Common positioning mistakes
- Writing the hero before the statement. The hero is the compression. Skipping the statement guarantees the team rewrites the hero every quarter.
- Comparing to direct competitors only. The honest alternative is usually OSS or a hand-rolled tool. Address it explicitly.
- Confusing features with unique attributes. "Real-time dashboards" is a feature. "Sub-second p99 query on a year of retention" is an attribute that can be verified.
- Value language a marketing intern could write. "Increase developer productivity" is empty. "Find root cause in one query instead of seven" is specific.
- Positioning for everyone. If the target market is "developers", the statement does no work. Pick a stack, scale, and problem shape.
- Treating positioning as a one-time exercise. Revisit it on market, product, or motion shifts. Otherwise leave it alone for 18 months.
How to test your positioning
Three tests, in order. None of them require a launch.
The five-minute test. Show the hero and the first 200 words of the docs landing to five developers who fit the target market but have never seen the product. Ask them what it is, who it is for, and what they would expect to do in the first five minutes. If three out of five answer correctly without you explaining, the compression is working.
The sales-call test. Hand the positioning statement to whoever is closing deals. After two weeks, ask what they kept and what they dropped. If they dropped the unique attributes and reverted to feature listing, the attributes are not believable yet — either the proof is missing or the statement is wishful.
The community test.Post the hero on the relevant subreddit, Hacker News, or the category's primary Slack. Read the responses. Vague positioning gets ignored. Wrong positioning gets corrected. Right positioning gets argued about. Argument is the goal.
Lenny Rachitsky has a useful interview with April Dunford covering the testing approach in more depth, including the workshops that turn a draft statement into operational copy.
FAQ
How is positioning a developer tool different from positioning B2B SaaS?
Developer-tool positioning is evaluated by the technical user inside a 5-minute hands-on trial, not by an economic buyer reading a one-pager. That changes the deliverables. The positioning statement still matters, but it has to translate into a 12-word hero, a quickstart that works, a docs IA that mirrors the narrative, and a pricing page that does not block self-service evaluation. Generic SaaS positioning workshops produce statements that never make it past the marketing team.
Who owns positioning at a developer-tools company?
Founders own it at the start. The PMM owns it once the team has one. Engineering and DevRel veto it if it is not technically honest. In practice it is a four-way conversation: founders set the intent, PMM does the customer interviews and writes the statement, engineering checks every technical claim, and DevRel pressure-tests the language against the audience. If any of those four is missing the positioning drifts.
How long does positioning work take?
Three to six weeks for the first credible draft if you are doing real customer interviews. A week if you skip the interviews, but the output will be guesswork dressed as strategy. The customer-interview phase is what makes the difference between positioning that holds up under sales pressure and positioning that gets quietly rewritten on the founder's laptop six weeks after launch.
Do developer tools need a positioning statement, or just a tagline?
Both, and they are not the same thing. The positioning statement is the internal document that aligns the team on category, alternatives, value, and proof. The tagline is the 6-12 word externalization of that statement on the hero of the marketing site. Teams that skip the statement and write taglines first end up with copy that sounds good in isolation but does not survive contact with the sales call.
When should we revisit positioning?
Three triggers. The market shifts (a category leader pivots, an OSS alternative goes mainstream, AI changes the evaluation surface). The product shifts (you ship a new primitive that reframes what the product is). The sales motion shifts (you move from self-serve to enterprise, or vice versa). Outside those triggers, leave the positioning alone for at least 18 months and let the team build conviction in it.
Related reading
- Positioning framework — the interview script and coding pass behind the four inputs.
- Developer-first PMM — what changes when the buyer is a developer evaluating hands-on.
- Positioning statement examples — annotated real-world statements and what makes them work.
Need help writing yours?
12 years of DevTools positioning, on retainer.
Written by Daria Dovzhikova — 12 years inside developer-first companies including JetBrains, Lightrun, and Odigos. Fractional PMM engagements start at $1,500 for a written GTM Diagnostic.
See servicesReady when you are.
Discovery calls are 20 minutes. First one's on me.