Devtools Positioning: The Six-Box Canvas That Works

Most positioning advice for devtools sounds great and produces nothing usable. The reason is that the templates were built for a different category. April Dunford's book is the best in the field. It's also pitched at buyers who get reached through analyst reports, conference keynotes, and CFO emails. For devtools, the buyer is the user, the user reads code, and the only thing the product is competing against is the engineer's existing chain of bash scripts and grumbling.

The standard positioning canvas asks you to articulate "competitive alternatives," "unique attributes," and "market category." Those words make sense in a SaaS boardroom. They don't make sense at 2am when an engineer is debugging production and considering whether to install your CLI. The right canvas asks different questions, in the engineer's language, and forces you to be specific enough that a senior IC could read your output and immediately decide whether to try the product.

This is that canvas. Six boxes. Each one has a prompt and a tight example. You fill it in with your team in a single 90-minute session, sticky notes on a whiteboard or a duplicated Notion page, and you'll know within an hour whether your positioning is sharp or mush.

The six boxes

1. The Pain

What does the engineer hate doing today? Use their words. Not "lack of observability." Not "developer productivity gap." Something a real engineer would say in Slack at 11pm.

"I'm tailing logs across three terminals trying to figure out why production is slow."

If you can't write the pain in a sentence a senior engineer would actually say, you don't understand the pain yet. Go interview five users. Record the calls. Pull out the verbatim quote that came up in three of them. That's your pain box.

2. The Status Quo

Name the tools they currently chain together. Specificity here equals sharpness. Don't say "existing monitoring solutions." Say "Datadog + a custom Python script + Notion runbooks + a Slack channel everyone mutes."

Devs respect when you name what they actually use. A vague description of "the current state" reads as a marketing team writing about a buyer they've never met. A precise one ("you're probably using New Relic for APM, Sentry for errors, and a homegrown dashboard for the rest") reads as someone who's been in their shoes.

3. Your Wedge

The ONE thing you do dramatically better than the status quo. Not three. One. The temptation to list three (because you have three, and they're all good) is exactly what produces mush positioning. Pick the one that makes someone say "huh, that's actually different" and lead with it.

"We replace the Python script with a one-line install that auto-correlates traces to logs."

Note the structure: verb + named alternative + specific outcome. Not "we offer a unified observability platform." Specific verb, specific replacement, specific result.

4. Anti-Positioning

Who is this explicitly NOT for? This is the box most founders skip, and it's the box that does the most work. When you tell someone they're not the buyer, the right buyer feels found.

"Not for teams under 5 engineers. Not for monoliths. Not for anyone who isn't already paying for observability."

Anti-positioning sounds counterintuitive — won't excluding people shrink your market? Yes. That's the point. You're not trying to be useful to everyone; you're trying to be obviously, unmistakably the right tool for a specific kind of team. The teams you exclude were never going to buy anyway. The teams you keep will recognize themselves and move faster through the funnel.

5. The "Holy Sh*t" Moment

What happens inside the product that makes a developer DM their teammate? Be concrete.

"When they paste a slow query and we show them the exact line of code generating it, with a fix."

The holy-sh*t moment isn't a feature; it's a feeling. It's the specific second when a dev moves from "this is interesting" to "I'm going to send this link to two people right now." Every great devtools product has one. If you can't name yours, you don't have it yet — or you have it and haven't isolated which thing it is. Either way, find it before you scale anything.

6. The One-Sentence Pitch

Read it aloud. Does it sound like a human?

"For [archetype] who [pain], we are the [category] that [wedge], unlike [status quo] which [failure]."

The structure is the structure. Fill in the brackets with what you wrote in boxes 1-4 and you have your pitch. The acid test: read it aloud to a friend who's a developer but doesn't know your product. If they say "oh, like X for Y," you've nailed it. If they say "wait, what does that do?" you have more work to do.

The three ICP archetypes

The six boxes only work if you've picked one buyer to aim at. The biggest positioning mistake I see is trying to serve all three developer archetypes simultaneously. The result is mush — content that's too technical for one and too shallow for another, pricing that's too expensive for one and too cheap for another, onboarding that confuses everyone.

Pick one. The other two will buy anyway if you're good. But you have to pick one to lead with.

The Builder (Senior IC)

Discovers tools via HN, technical blog posts, GitHub trending, friends, niche Slacks. Decides informally — formal authority is low but informal influence is high. Buys via side project → brings to team → team adopts. Needs from you: 5-minute quickstart, generous free tier, no sales call. If your product needs to be tried to be understood, lead with this archetype.

The Decider (Engineering Manager / Tech Lead)

Discovers via their senior ICs, conference talks, peer recommendations, LinkedIn. Decision power is medium-high, but heavily influenced by the engineers on their team. Buys via pilot → security review → procurement → rollout. Needs from you: case studies with real numbers, a security page, a champion's kit. If your product needs to be compared to be chosen, lead with this archetype.

The Architect (Staff+ / Head of Eng)

Discovers via vendor outreach, their network, analyst reports, podcasts. Formal decision power is high, budget owner. Buys via 3-month eval → ROI calc → multi-year commitment. Needs from you: deep technical content, reference architectures, a CEO or CTO to talk to. If your product needs to be committed to, you're already selling to this archetype — and you should know it.

Pick the one closest to where your current best customers live. Resist the urge to design for all three. You'll get there, but only by mastering one first.

What good positioning looks like in the wild

The clearest examples of devtools positioning, in 2026:

• Vercel. "Frontend cloud, optimized for Next.js." Specific verb-replacement-outcome. Named status quo (AWS, Netlify). Specific Builder archetype.
• Linear. "Issue tracking for engineering teams that move fast." Specific archetype. Implicit anti-positioning (not Jira, not for everyone).
• PlanetScale. "MySQL-compatible serverless database." Comparison to named status quo. Specific wedge (serverless + branches).
• Resend. "Email API for developers." Three words, total clarity. Implicit anti-positioning (not Mailchimp).

Note what these have in common: short, named comparisons, no "platform" or "solution" language, no buzzwords. They all pass the "could a senior backend engineer explain this product after 30 seconds on the homepage" test. That's the only test that matters.

Where most devtools founders get this wrong

Three patterns I see again and again:

Pattern 1: Category claim instead of job-to-be-done. "The modern caching platform" tells me nothing. "Cache invalidation that actually invalidates" tells me everything. Lead with the job, not the category.

Pattern 2: Three wedges instead of one. "Faster, cheaper, more reliable." Pick one. Lead with one. The other two become supporting points in chapter two of your story, not the headline.

Pattern 3: No anti-positioning. A homepage that says "for teams of any size" repels everyone. A homepage that says "for teams of 5-50 engineers shipping daily" finds its people.

Fix any one of these and your conversion rates move. Fix all three and you stop needing growth tactics.