The Developer Tools playbook, with Adam Frankl - VP of 4 DevTools unicorns
Adam Frankl recommends founders start a technical advisory board of 50 people, interviewed one-on-one, 30 minutes a month for six months — and pay them nothing. Appreciation, not compensation, is the whole point.
Adam Frankl was the first VP of marketing at three developer-facing unicorns — JFrog, Sourcegraph, and Neo4j — which he jokes has earned him the nickname 'Triceratops.' Before that he was a developer himself, writing code for the F-22 at Lockheed's Skunk Works, until a blunt comment he made as a 25-year-old about a devtool startup's inability to talk to developers turned into a job offer and three decades studying how developers actually adopt technology.
He's now written The Developer Facing Startup and runs a founders' course on the same material. Most of this conversation is a detailed walkthrough of how he runs a technical advisory board — the exact questions, cadence, and group size he recommends — plus the story structure he uses to turn what he learns into marketing, and why he thinks the standard B2B lead funnel actively misleads developer-facing startups.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why do developer-facing startups fail, in your experience?
The biggest reason is they're not listening to developers. That sounds obvious, but it's hard, because if you're a developer who founded a startup to solve a problem, your natural inclination is to write code, ship it, and write more code — nowhere in that loop are you actually talking to developers and having them talk back to you. It doesn't happen naturally; you have to make it happen. The other hard part is that you've spent years thinking about your solution — the trade-offs, the design decisions, the obstacles you overcame — and that's what you want to talk about. But that's not what developers want to talk about. They want to talk about the problem. Most developers are eager to talk about their problems, because no one else in their life cares — not their partner, not their boss. Get them on a call with someone who cares, and they won't shut up.
What questions do you actually ask in these interviews?
My favorite is what I call the magic wand question, which I got from Cindy Alvarez's book Lean Customer Development: if you could wave a magic wand and change anything about how you do this, don't worry about whether it's possible, what would it be? Then you shut up. That resets the frame — you're no longer talking about a product, you're talking about what they'd change if anything were possible. My second favorite follow-up is: if I could deliver that, how would that change your life? That's the actual thing you're selling — Henry Ford's customers would have said they wanted a faster horse, but what they actually wanted was to live in the country and work in the city, or get goods to market ten times faster. My third favorite is: what's changing in the world that makes this more valuable than it was five years ago? That's where real urgency comes from — not fake sales urgency, but a genuine trend making their problem worse every day.
How do you actually structure and run a technical advisory board?
Don't assemble people together — despite the name, every interview is one-on-one, never two people at once, because the faster talker dominates and you lose the other person's ideas. You're in the idea-harvesting business, and not every idea is great, but you have to hear them all to find the good ones. I recommend aiming for 50 people when you're starting out, because roughly half of any given conversation won't give you anything valuable, and you can't tell in advance who those will be. Structure it as a 30-minute call, once a month, for six months. If the problem is genuinely important to someone, they have 30 minutes a month for it — if nobody will take that meeting, that's a good, if painful, signal you're not attacking a problem that matters to anyone. Six months is enough time to build a trusted relationship without it becoming a vague, open-ended commitment.
How do you decide who to put on the board, across different roles?
Getting technology adopted by an organization is like picking a lock — every cylinder is a different role, and if even one stays closed, the whole thing stays blocked. You might get a great meeting with the person who loves your product, but if you're not also talking to whoever controls budget or security, they'll block it forever, and the symptom is good meeting after good meeting that never turns into anything. When you start, hypothesize every persona that could plausibly be involved — most companies land on around 12. Interview multiple people from each. If two personas give you fundamentally the same answers to your questions, you can collapse them into one. By about 30 days in, most people realize they actually only have three or four distinct personas, not 12. And in my view, if someone's ever written code for a living, they're a developer, culturally — that includes CTOs and VPs of engineering, because the skeptical, prove-it-to-me culture stays with them even once they've stopped writing code day to day.
Why not just pay people for their time on the board?
It's not a paid role — the principle is appreciation, not compensation. If you pay people cash, it feels like a bribe, and nobody likes that. Instead: stickers, socks, a hat, a coffee mug, a t-shirt. Not for showing off your own startup — so tab members can brag to their peers that they're on the technical advisory board of this startup, and later, once you've made it, brag that they got involved when you were still tiny.
How does this square with just being a great engineer who's felt the problem yourself?
Just because you have an idea doesn't make you an expert — it means you've experienced the problem. You become an expert by studying it, and in this business that means two things: having an original idea, and publishing it, which can be a blog post or a LinkedIn post, not a peer-reviewed paper. If you're just cranking out code and don't care about why people would adopt your product, you're not an entrepreneur, you're a hobbyist — nothing wrong with that, but don't confuse the two. An entrepreneur discovers a need and fills it; discovering it is half the job. That's also the real difference between founder mode and executive mode: an executive perfectly runs a proven business model, while a founder is constantly searching for the right one, and the only way to search is by talking to a wide variety of people and analyzing what you learn.
You use a story structure for turning what you learn into marketing. What is it?
Every story has a beginning, middle, and end. The beginning introduces the characters: the hero is your user, never the startup founder. The villain is the most important character — it needs to be easily identifiable and universally loathed, and you should spend real time deciding who it is. For Neo4j, the villain wasn't 'graph data,' it was the relational database: massive, everywhere, good for many things, but genuinely bad at connected data, slow, and hard to maintain. Then there's a wise advisor — Gandalf, Obi-Wan, or you — and a gift, which for most people listening is going to be a piece of software. The inciting event is whatever forces a reluctant hero to finally confront the villain. In the middle, the hero meets obstacle after obstacle and uses the gift and the advisor's guidance to get past each one. In the end, the hero defeats or drives off the villain, gains wisdom, and shares it with their community — which is exactly the case study you should be writing.
What makes a good customer quote for that kind of case study, versus a bad one?
'I love this company, it's great' is a terrible quote — it informs nobody of anything. 'I increased my video throughput 80 times' creates actual desire in that person's peers, because now they're incentivized to learn about the software to get the same result — I don't know exactly what an 80x throughput increase means for them, but it makes me want it. A generic glowing quote reads like it's from your brother-in-law. And you don't need to publish the whole story at once — post one piece of it at a time, the way stories used to run in installments before the novel existed as a format. A specific challenge someone overcame makes a great post on its own.
Why doesn't the standard B2B lead funnel work for developer tools?
Developers are not leads — I mean that literally, the awareness-interest-consideration-decision funnel was built to model how business executives adopt technology, and it works great for that, but not for developers. I call the developer version the DREAM sequence instead: discovery, research, evaluation, activation, membership. Discovery happens inside a developer's own technology discovery loop — the blogs, conferences, and meetups they already return to, partly driven by ambition and partly by the fear that their skills will become obsolete. Research happens on your website, where you get about thirty seconds to name the villain and the pain, because someone might not even realize they're in pain until you name it. Evaluation is not 'does this do what it claims' — it's 'my environment is a unique snowflake, what does bringing this in break' — and it has to happen fast, in a limited window with no support: a Fortune 500 architect might spend a weekend on a burner Gmail account trying to get your software working before Monday standup, specifically using a throwaway email so sales reps don't start calling them. If it's not working by Sunday afternoon, the evaluation is over and nobody says anything. Activation is about how fast someone goes from feeling like they suck at your tool to feeling like a badass at it — not how fast it installs. And membership is the endpoint: developers hate to buy, but they love to join a community of people solving the same problem, not just other customers of yours.
What's the risk of listening too closely to your existing customers?
Clayton Christensen wrote about this in The Innovator's Dilemma — you love your customers, you talk to them constantly, they're solving one set of problems, so you design your whole roadmap around that set of problems, and you miss an entirely different, possibly much bigger set of people your technology could serve. Digital Equipment Corporation owned the minicomputer market and never made a PC, because their customers were serious people who thought PCs were toys — I actually programmed PDP-11s back in the day. Floppy disk manufacturers kept making better floppy disks and missed solid-state storage entirely, which opened a market — early music players — ten times bigger than every floppy disk going into every PC combined. Brian Chesky avoided this by going to see, face to face, every one of the first ten people who rented out their apartment on Airbnb; one of them showed him a notebook tracking every renter, which is how Airbnb learned people don't rent apartments with only text descriptions, and started contracting professional photographers early on. There's also the story — maybe apocryphal, but the point stands — of Steve Jobs quietly hanging out in the corner of the Palo Alto Apple Store, out of uniform, forbidding staff from acknowledging him, just to watch how people actually used the products.