Positioning & Messaging for a Developer ICP

Positioning is the context you set so a feature's value is obvious to the right person before they read a single adjective. Most weak marketing skips this step and jumps straight to claims, which is why it bounces off engineers.

The cleanest model for a PMM interview is April Dunford's. It treats positioning as deliberate, not as a tagline you brainstorm. You start from what the customer would do instead of you and you reason forward to the category you want to be judged in.

1. 1Competitive alternatives. What would the customer use if you didn't exist? For a developer that's often a free chatbot or the AI features already in their editor, not just the obvious paid rival.
2. 2Unique attributes. What can you do that the alternatives can't? Be specific and checkable: codebase-aware context across files, editor-native multi-file edits, Tab predictions that follow your edit flow.
3. 3Value. Translate each attribute into the outcome a developer feels: fewer context switches, less time re-explaining the repo, faster path from intent to a working diff.
4. 4Target customer who cares most. Find the segment for whom that value is acute - the engineer working in a large existing codebase feels context-awareness far more than someone scaffolding a toy app.
5. 5Market category. Choose the frame that makes your value the obvious win. “AI code editor” sets a different expectation than “autocomplete pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance.,” and the category does a lot of the selling.

Positioning and messaging are two jobs. Positioning decides the context and the category. Messaging is the articulated promise: the words, the proof and the reason it matters, written for one segment at a time.

Work it end to end: Cursor Agent vs. the real alternativesthe example to have ready

Interviewers want to see you run the framework live, not recite it. Position Cursor Agent against the two alternatives a developer actually weighs: “just use Copilot” and “just paste into ChatGPT.”

The honest positioning is not “Agent is smarter.” It is that Agent works against your real codebase with the editor's context, so the developer stops being the copy-paste middleman. The target who cares most is someone shipping changes in a large, established repo.

Company-level vs. feature-level positioning

“Developers” is not an ICP. A solo engineer trying Cursor on a side project and a VP of Engineering rolling it out to 800 people share a tool and almost nothing else about how they decide.

Cursor's motion runs bottom-up and then pushes into the enterprise, so the PMM serves two people in the same account: the IC who adopts because the product is good and the buyer who needs a reason the org should standardize and pay. Their proof requirements diverge sharply.

Across all three, one rule holds: developers buy on credibility and time saved, not on adjectives. Anchor every claim in a job-to-be-done and a workflow the reader recognizes from their own week.

Map the objection per segmentthe same product, different fears

The “I can already do this” objection is the one to respect most. The engineer is often right that their setup works. Winning means showing a concrete task where the friction is real, not arguing they're wrong.

This market moves weekly and engineers follow it closely. A PMM who can't name the field accurately loses credibility in the first minute of a competitive conversation.

Know the real set, including the unbranded one. “Just use the chatbot” is a genuine competitor for a lot of casual AI-coding work and pretending the field is only paid IDE rivals makes your positioning naive.

Differentiate on substance, not on a tagline. The defensible claims are editor-native multi-file workflows, codebase-aware context across files and the feel of speed in everyday edits. Those are things a developer can check in a session, which is exactly why they're worth claiming.

Keep positioning currenta claim true last quarter can be stale today

1. 1Re-check claims on a cadence. Treat competitive copy as perishable; set a recurring review so a feature gap you cited isn't quietly closed.
2. 2Watch the channels devs watch. Release notes, X, Hacker News and GitHub threads are where the field shifts before any analyst notices.
3. 3Test claims against the live products. Use the competitors enough to speak from experience, not from their landing pages.
4. 4Version your battlecards. Date them and note what changed, so sales never pitches a claim that went stale two releases ago.

The hardest line in this job description: simplify complex AI and developer workflows without dumbing them down. Simplifying and dumbing down are opposites - one removes noise, the other removes truth.

Dumbing down means hiding the mechanism behind a slogan. Simplifying means choosing the one workflow that carries the point and telling it concretely. Engineers will forgive complexity; they won't forgive vagueness.

The narrative order that works for engineersproblem → aha → mechanism → proof

1. 1Lead with the problem. Open on the developer's actual pain - re-explaining the repo, stitching multi-file changes by hand. They have to recognize themselves in the first line.
2. 2Land the aha. Show the moment it gets better: the diff appears across the files, already wired up. One vivid before/after beats a capability list.
3. 3Then the mechanism. Now explain how it works - context from the codebase, a concrete plan, a reviewable change. By now they want the detail.
4. 4Close with proof. A real metric, a recognizable workflow, a named customer. Specifics are the credibility, not the superlatives.

Notice the order. Most marketing leads with the mechanism or the brag; this leads with the reader's problem and earns the mechanism by the time it arrives.

Kill the words that trip the BS detector

• Unverifiable superlatives: “fastest,” “smartest,” “revolutionary,” “magical.” If you can't prove it in a demo, cut it.
• Abstract benefit-speak: “boosts productivity,” “empowers teams.” Replace with the specific task that got shorter.
• Buzzword stacking: “AI-powered next-gen developer platform.” Engineers translate this to “nothing concrete here.”

Specificity is the credibility currency. “Cuts a five-file refactor from a morning to a reviewable diff in minutes” outperforms any adjective because it's falsifiable and a developer respects a claim they could disprove.

A message house keeps every asset saying the same thing in the right register. Without one, the blog, the landing page and the sales deck drift until the product means three different things.

The structure is a hierarchy. One core narrative on top, a few pillars beneath it, proof points under each pillar and per-channel variations at the bottom where the words flex for X versus a docs page versus an enterprise one-pager.

Build it top-down but pressure-test it bottom-up. If a pillar has no real proof point, it's a wish, not a pillar and it comes out.

Validate with users, not the conference roomthe JD calls for regular user interviews

1. 1Draft the house from positioning. Core narrative and pillars first, grounded in the segment work, not in internal taste.
2. 2Test it on real developers. Run interviews and message tests; watch which line they repeat back unprompted and which they shrug at.
3. 3Listen for their words. The phrasing a developer uses to describe the value is usually better than yours - steal it.
4. 4Refine and re-ship. Update the house, then keep it living as the product and the market move; messaging is an asset you maintain, not a deck you finish.

Define what “the message works” means