Technical Advisory Boards - the most important action DevTools founders can take?
Jack breaks down Adam Frankel's Technical Advisory Board framework after running one himself: the one magic-wand question that gets people talking, why every call has to be one-on-one, and why 50 cold outreach messages gets you one TAB member.
This one's a solo breakdown, not an interview. Jack explores Adam Frankel's concept of a Technical Advisory Board — a structured way for DevTools founders to learn directly from potential users — and shares what actually happened when he ran one himself: how to set up the calls, what to ask, how to analyze what you hear, and how to get the most out of the process.
Adam Frankel has been VP of marketing or an early executive at three DevTools companies, including Neo4j, Sourcegraph, and JFrog, and wrote about the TAB concept in his book The Developer-Facing Startup. This episode strips the framework down to what matters, plus Jack's own experience actually running one.
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.
What is a technical advisory board, actually?
The funny thing, as Adam says too, is that it's not technical and it's not an advisory board. It's basically a group of potential customers, potential users, or maybe current customers, and you don't ask them for technical advice — you talk to them and learn about their problems and challenges, then use that to shape both what you build and how you talk about it. It involves meeting with one person, one-on-one, once a month for thirty minutes, over six months — a total of about three hours of their time. Crucially, you're not pitching them. It can have sales benefits, but it's a learning process, not a sales process.
What actually happens on the first call?
Before you start, you work out your question list — Adam says seven is about the right amount, since you won't have time for more, though personally I've never gotten anywhere near seven. Keep it short: he's never heard something valuable in the second thirty minutes. Once you've identified the topic or problem area, you ask his favorite question: if you could wave a magic wand and do anything you can't do today, what would it be? Don't worry about whether it's possible. This traces back to Cindy Alvarez, author of Lean Customer Development, and it works because the moment you lead people or seed them with an idea, they'll happily just agree with it and stop really thinking — you're not trying to validate your own idea, you're trying to find theirs. If you just ask people that one question, you'll probably get most of the value from the whole process. From there you ask how this would actually change their life — which gets at what you'd effectively be selling — and then why now: what's different about the world today that makes this more valuable than it would have been a year or two ago, since talking to startups moves fast enough that five or ten years is usually too long a frame. Then you just listen sympathetically — even people who are reluctant with strangers will talk your ear off once they're on the topic of their own problems.
Any rules for how you actually run these calls?
Do not do group interviews — every TAB call should be one-on-one. If you interview two or more people together, the quicker person answers and the other just nods along or nods off, and you're wasting the second person's time instead of harvesting their ideas separately. And record every call — use Zoom or Google Meet, use something like Granola for transcription and notes, and make sure you log everything.
Why would anyone agree to do this for free?
You don't give them equity, you don't pay them — you give them swag and genuine appreciation and gratitude. The people you want are the ones who care enough about the problem, and enjoy talking about it enough, that the conversation itself is payment. Lead with swag and appreciation, not money.
How do you actually recruit people onto a TAB?
It's the stuff none of us like doing — cold emailing, messaging people on LinkedIn. The good news is it isn't the typical "want to try my product" pitch — you're resonating with a problem they clearly have and inviting them onto a board, which some people find genuinely good for their own career and profile. Adam's approach: find people who've written about the problem publicly, then find something specific to praise before you ask — a post, a tweet, two years at a company you admire, a shared alma mater. Don't batch these; if you don't have time to research each person individually, you don't deserve a reply. Most people will still ignore you, and that's fine — you're reaching out to roughly 50 people for every one who ends up on your board, so if you want 50 TAB members, that's 250 outreach messages. If you're already building in the space, though, you likely have connections you can ask first before going to cold outreach at all.
Once you have a few calls done, how do you make sense of what you heard?
Adam's favorite framework is Value Proposition Design, by Alex Osterwalder — for each persona, list out the pains, the gains (not just the negative of the pains, but aspirational things they want), and the jobs to be done. My honest take, which Adam would probably disagree with: just focus on one persona, because doing this properly for many personas is a huge amount of work, especially if you're also the one writing code and docs and building the product. Go through your interview notes, highlight pains, gains, jobs to be done, and the answers to the "why now" question, then group by persona and throw out the outliers — it's not unusual to go from ten or twelve theoretical personas down to three after doing the actual research. Pay particular attention to the pains — I think that's where the real value is, more than the gains or the environmental changes, at least at the stage most of us are at.
What happens in the second and third calls?
In the second call, you share back what you found — literally screen-share the document and ask whether it matches their top three pains, and people will absolutely tell you if you've got it wrong, or that their actual biggest problem is something else entirely. There's a lot of gut instinct in weighing these against each other — someone who was really passionate about one pain might deserve more weight than someone lukewarm about a pain they nominally ranked higher. By the third call, Adam says you start developing and sharing your story and getting feedback on it — always framed around the customer as the hero and the problem as the dragon, not around you as a company.
Links & references
- The first TAB call ↗
- How to recruit TAB members ↗
- After the first set of TAB calls ↗
- Adam Frankel's LinkedIn ↗
- Adam's book, The Developer-Facing Startup ↗
This episode is brought to you by WorkOS.