The most useful way to split a developer ICP is by who champions the tool and who signs the check. The engineer discovers you, tries you, falls for you, and then has to go convince someone who will never open your docs to approve the spend. Those two people need completely different things from you, and most devtools marketing writes for them as if they were one. You market to the person who uses it and sell to the person who pays for it. Confuse the two jobs and you end up with either a product engineers love that never gets budget, or a slick exec pitch that engineers quietly refuse to adopt.
I have run GTM inside more than thirty devtools companies with engineering ICPs, and the pattern holds every time. The champion and the signer are almost never the same human, and the handoff between them is where most deals quietly stall or go through.
Start with the account, then find the two people inside it
Your ICP is a company profile before it is a person. Define the account first: what they build, what stack they run, what stage they are at, what pain shows up at their scale. A schema-migration tool has an ICP of teams shipping database changes fast enough that a bad migration is a real risk, which usually means a certain team size and deploy frequency, not a certain headcount or funding round. Get the firmographic and technographic filter right and you stop wasting effort on companies that will never feel the pain you solve.
Then, inside that account, you find two people. The champion is the engineer who hits the problem, goes looking, finds you, and wants you in the stack by Friday. The economic buyer is whoever controls the budget line the purchase comes out of, and it scales with price. Under a few thousand dollars a year the champion might just expense it. Once you cross the threshold where a manager, a VP, or procurement gets involved, a second persona enters the deal, and that person evaluates you on things the champion never thinks about.
Both belong in your ICP work. The mistake is writing a single persona and hoping it stretches across both, when it usually ends up describing neither one well.
The champion and the buyer are solving different problems
The champion wants the problem gone. They are measured on shipping, and your tool either removes friction from their day or it does not. They care about whether it works on their actual codebase, how long setup takes, whether it breaks their existing pipeline, and whether the docs respect their time. They will try you before they talk to anyone, which is why everything you publish for engineers has to survive a skeptic reading it at 11pm. They trust something that runs on their machine. A promise does nothing for them.
The economic buyer wants the risk gone. They are measured on outcomes and on not making a purchase they have to defend later. They do not care about your API ergonomics. They care about what happens to the metric they own, what this replaces, what it costs fully loaded, whether it introduces security or compliance exposure, and whether the vendor will still exist in two years. Send this person your quickstart and they will feel talked past. Send the champion that buyer’s ROI one-pager and they will roll their eyes at it. Each one bounces off the other’s material.
Same deal, two problems. You need material aimed at each, and you need it to agree with itself, because the buyer is going to ask the champion “is this real” and the champion is going to ask you nothing because they already know.
What a persona that changes decisions actually contains
A persona that changes decisions describes a person in motion: what they are chasing, what set them off looking, where they spend their time, what wins them over. The demographic trading card, age and seniority band and favorite programming language, tells you nothing about whether they will buy, so I throw that part out. What I keep is whatever tells me what to build and where to show up.
- The job they are trying to get done. Not their title, the outcome they are chasing this quarter. “Cut the time between a schema change and knowing it is safe” is a job. “Backend engineer” is not.
- The trigger. The specific moment they go looking for a tool like yours. A migration took down staging. A new hire asked why deploys are so scary. The board asked about SOC 2. Triggers are when budget and attention appear, and if you know them you can meet the person at the exact moment they are ready to move.
- Where they actually hang out. Which subreddits, which Slack and Discord communities, whose newsletter, which conference hallway. Vague answers like “Twitter” are useless. Named places are a media plan.
- What makes them trust you. For the champion it is a runnable artifact and honest docs. For the buyer it is a customer they recognize, a security page that exists, and a reference call. Write down the specific proof each one needs to say yes.
- What makes them bounce. The objection, the dealbreaker, the smell that makes them close the tab. A gated download for an engineer. A missing pricing page for a buyer. Name it so you can remove it.
Fill that out for the champion and again for the buyer and you have something a whole team can act on. Contrast that with the trading card, the one with a stock photo named “DevOps Dan, 34, likes Kubernetes and craft beer.” Dan has never once told anyone what to write or where to spend. Delete Dan.
The champion sells for you when you are not in the room
Here is the part most teams miss. The champion does the internal selling you cannot do. You are not on the Slack thread where a platform engineer pitches your tool to a skeptical staff engineer, and you are definitely not in the budget meeting. Your positioning has to travel through the org in your champion’s own mouth, and it will lose shape at every handoff unless you gave them language that holds. This is why positioning a technical product is about being more specific, not more broad. Precise claims survive the retelling. “Modern developer experience” dissolves the second it leaves your homepage.
So arm the champion for a fight they are having without you. Give them the one-sentence version of what you do that they can drop in a thread without sounding like a brochure. Hand over the numbers that answer “what does this cost and what do we get” before the VP asks. Write the comparison against the real alternative, which is usually a pile of scripts and suffering, not the competitor you name in board decks. Point them to a security and compliance page they can forward instead of filing a ticket with you. Include a short customer story featuring a company their buyer will recognize.
Here is the test. Could your champion win the internal argument using only the things you handed them, with you nowhere in the conversation? If the answer is no, you have a product engineers like and a pipeline that stalls at the approval step, and you will spend the next quarter blaming sales for a marketing problem.
How the two personas change what you build and ship
Once you hold both personas, your whole funnel sorts itself. Self-serve, docs, tutorials, and the free tier are for the champion, because their evaluation is hands-on and happens before any conversation. This is doubly true when your buyer builds with LLMs and runs their own evals before they believe a word you say. The champion converts on proof they generate themselves.
The buyer-facing layer is different work: a pricing page that does not hide the number, a security and compliance story, case studies with named logos and real outcomes, and a sales motion that shows up only after the champion has already fallen for the product. You are not building two products here, just showing two layers of the same truth, one for the person who uses the tool and one for the person who signs off on it.
Write both personas down. Put the trigger, the watering holes, the proof, and the dealbreaker in plain language a designer, a writer, and a founder can all act on. Then build the champion a kit good enough to win the meeting you will never attend. That kit is what closes the gap between a devtool people love and a devtool people actually pay for.
