Adam Frankl returns to answer my TAB questions
Jack ran his own Technical Advisory Board using Adam Frankl's method — then came back to ask Adam everything that went wrong. The most useful fix: stop asking 'what's your biggest problem' and start asking what's actually taking the most time.
Adam Frankl has been the first marketing VP at three developer-facing unicorns and wrote The Developer Facing Startup, which introduced the Technical Advisory Board (TAB) framework. He first came on the show to explain the concept; this episode is Jack returning after actually running one at his own startup.
We get into what went right and wrong across Jack's three rounds of TAB interviews, how to reframe a stalling third call, why LinkedIn outreach is getting harder even as cold email stays hopeless, and Adam's live experiments in getting AI models to actually repeat your product's message back to people.
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.
As a refresher, what actually is a Technical Advisory Board?
The core idea is that if you're building a product for developers, you need to talk to developers — but most founders default to writing code, publishing it, watching people use it, and writing more code, with no structured point where they're actually talking to the people using it. A TAB, despite the name, is not technical, doesn't give advice, and isn't a board. It means reaching out to dozens of developers — some founders have done hundreds — and talking to them not as a single transactional sales call, but as a repeated, structured relationship, interviewed rather than just chatted with, in a way that lets you compare and contrast what different people say and build both your story and your product around it. Adam also stretches the definition of 'developer' to include anyone involved in the adoption decision — SREs, UX, backend, frontend, full-stack engineers, and the VPEs, CTOs, or CISOs who approve budget, since even non-coding executives remain part of developer culture, which behaves differently from typical business-executive culture.
How did running a TAB actually go at your own startup?
Overall it's been great — especially as an onboarding tool, since talking to people about their problems early gives a strong read on where their priorities actually sit. But it's genuinely hard to do well, and this was Jack's second attempt, having previously done Adam's course at a prior startup. The whole episode grew out of wanting to ask Adam directly about the specific places it got hard, rather than repeat the framework from scratch.
What questions actually worked well in the interviews?
The single most valuable question, borrowed from Adam and originally from marketing consultant Andy Raskin, is: if you could wave a magic wand and fix or improve one thing, what would you wave it at? Jack found almost all of the interview's value concentrated in that one question. The second, 'if you had this, how would it change your life,' felt almost too dramatic to ask out loud, but nearly everyone answered it seriously anyway. A third question Jack adapted — asking whether anything makes the problem more valuable to solve now than in some earlier time frame — tended to get the same answer from everyone in his space, since generative AI was the obvious universal answer, so it carried less differentiating value. Jack's approach was to ask the same core question repeatedly within a call, drilling down — if someone said they'd wave the wand at observability, he'd follow up asking specifically what they'd wave it at within observability.
What's the actual purpose of the third call in the process, and why did it feel hard?
Jack's struggle was that by the third call, he felt like he was re-clarifying the same ground and losing momentum, partly because he wanted to show progress solving the problems people had raised, but hadn't built enough yet — the team was very early and what people wanted didn't line up neatly with their current focus. Adam reframed the third call's actual purpose: it's about finding out how much of the problem you need to solve to create real value. Sometimes solving 10% of a huge problem is genuinely amazing — cutting someone's AWS bill by 10% is fantastic even though it's only 10%. Other times a 99% solution is worthless unless it's 100%. The first call is discovery; the second prioritizes which problems matter most; the third tests how far you actually need to go. Adam's method here is to describe a specific result an early user achieved and ask, 'if you could duplicate this result, would it be compelling, and why or why not?' If you don't have a real result yet, you can hypothetically ask whether achieving a specific result would be compelling, as long as you never claim you've already achieved something you haven't — developers will find you out. The real question buried in this is usually about time: how much time needs to be saved before it's actually noticeable, since shaving an hour off a three-month project does nothing, but shaving a month off a two-month project is something someone wants today.
You mentioned a question like 'what's your biggest problem building voice agents.' What was wrong with that framing?
Adam's correction: that question needs tightening, because 'quality' will always be the answer to a broad 'biggest problem' question, and it's a problem no startup can fix on its own — that's on OpenAI or Anthropic. The sharper question is what's actually taking the most time right now, since that surfaces something you might actually be able to solve. Everyone wishes quality were better, but the real, addressable problem is usually closer to: my CEO wants this shipped next week, and with what I know and the tools I have, it's realistically a three-month project — so what can close that gap between three months and one week? That's a solvable problem, and figuring out where people are spending time they shouldn't have to is the goal.
Has the definition of 'the constrained resource' shifted with AI-assisted coding?
Adam has been having this conversation constantly. For a generation, developer tools all assumed developer hours were the scarce resource. With agentic coding potentially generating as much code as you want, that assumption may no longer hold in the same way — but that doesn't mean developer time stops mattering, it means it shifts dimension. Someone still has to review the code an agent generates. How developers actually spend their day post-AI-adoption is changing rapidly enough that Adam doesn't think anyone confidently knows what it'll look like twelve months out, only that it'll be different from today, the way today is already very different from twelve months ago.
Can you give an example of a well-stated problem from your own work at Sourcegraph?
Sourcegraph's earlier product, before AMP, was code search — but the company didn't initially know that was its real value, and launched under a meaningless slogan, 'the new standard developer platform.' Among six different things the team tried was cross-platform code search: searching across code split between GitHub, GitLab, and other platforms. That's what actually got customers in the door, once framed as 'universal code search.' Uber was an early customer: as it expanded fast, each new country got its own dev team told to move as fast as possible, so each of its first twenty airports got built and coded independently. Once an executive noticed adding the hundredth airport was taking too long, they wanted an 'airport library' — but the code for airport handling was scattered everywhere across code that had been developed as fast as possible with every corner cut. Universal code search was exactly the tool for finding and consolidating that scattered code. The art of stating the problem well is boiling it down to two or three memorable words: 'search,' because everyone already knows what Google search is; 'universal,' because 'code search' by itself was already a built-in button inside GitHub and GitLab's own interfaces, and neither would ever search the other's repositories — that's the real gap 'universal' pointed at.
How do you keep TAB members engaged and honest with you when there's no formal payment involved?
There's an implicit promise behind every TAB relationship: you're not paying people or offering them equity, but you are asking for their time, their most valuable possession, and the implicit deal is that the time they spend with you will genuinely help solve their most important problems. If you stop believing you can deliver on that promise in the near term, the honest move is to tell them directly — say this is clearly an important problem, but you won't have anything for them in the short term, and ask to reconnect once you do. People are generally very generous with their time, but everyone quietly suspects vendors just want to sell them something, so being upfront about timelines is what preserves the relationship for when you do have something worth discussing again.
Should the TAB program sit with one dedicated person, or be spread across the team?
Adam favors one person owning it, since consistency matters and interviewing is a skill you only improve by doing repeatedly. That said, recordings and transcripts are genuinely valuable to share with the rest of the team so everyone stays aligned on what's actually being heard. Jack's team built an internal podcast-style feed, hosted through Cloudflare, where every TAB call gets uploaded so anyone can listen — a deliberate attempt to keep the whole team on the same page, since it's easy to come out of a single call convinced of an urgent priority and then struggle to generate the same enthusiasm across everyone who wasn't on the call. Adam's suggestion for scaling that further: clip highlights rather than expecting anyone to sit through a full thirty-minute call — short clips get watched, long raw video mostly doesn't.
Has cold outreach for finding TAB members gotten harder?
Noticeably. Jack's team had zero success with cold emails and better luck with warm introductions and non-cold scenarios, but even LinkedIn, historically the strongest channel, has degraded over the last twelve months — partly because more people are copying Adam's own techniques, and partly because of AI-generated outreach messages flooding the platform, making people skip LinkedIn messages entirely rather than read them. Adam's alternative isn't a different channel so much as a different mechanism: publish consistently on topics your target market cares about, then reach out immediately to anyone who engages with that content, since engagement is a live signal that someone's already interested and has a short window where a fifteen-minute call feels like a reasonable ask. That loop — publish, get engagement, convert engagement into calls, turn call content back into more publishable material — reinforces itself over time.
What's Adam working on right now?
Leveraging AI to speed up parts of the TAB process itself, and researching the best way to get technical information absorbed by AI models so that tools like ChatGPT actually repeat a company's own messaging back to people asking about it. His tentative, still-being-validated conclusion is that AI models seem to prefer long-form video, especially podcasts, over short-form content — the opposite of human preference, where short-form fits into moments like standing in a coffee line, while long-form suits focused attention. Podcasts in particular are word-dense and conversational, a format the models have been trained on heavily given how much the genre has grown, which may make going on, or starting, podcasts more valuable for a startup's visibility inside AI answers than traditional website design or SEO work — Adam suspects more developers are already asking ChatGPT directly about companies and products instead of navigating badly designed websites, echoing the collapse in Stack Overflow's traffic he'd just discussed with a former Stack Overflow executive on a recent TAB call.
Links & references
This episode is brought to you by WorkOS.