Technical Advisory Board (TAB) Framework for Devtools

Created by Adam Frankl - https://www.amazon.com/Developer-Facing-Startup-market-developer-facing/dp/B0D4KGHQML

Overview

The Technical Advisory Board (TAB) Framework is Adam Frankl's method for founders of developer-facing startups to learn what problems their users actually have. A founder recruits developers and the other people who influence adoption, then holds a short one-on-one call with each of them every month for six months, asking the same questions of everyone and never pitching. In his post The #1 most important process, Frankl calls creating a technical advisory board "the single best action you can take as a dev startup founder." As a technical advisory board framework, it gives a small team a repeatable developer discovery framework that feeds both the product and the story told about it.

Frankl himself calls the name misleading. In a Scaling DevTools interview he says a TAB is not technical, does not give advice, and is not a board. Members are potential users and customers. Frankl separates them from the senior technical people a founder might ask for advice: those advisors are valuable and lend early credibility, he writes, "but they are not sufficient." A developer advisory board in his sense is a set of repeated interviews, and the members never meet as a group.

Frankl's written guidance is specific about the shape of the program. Joining a TAB means a thirty-minute call every month for six months, and his post says to compensate members "with stickers, mugs, or t-shirts" (Frankl). In a Scaling DevTools interview he adds that it is not a paid position: "appreciation not compensation." The board needs several members from each persona the product touches, which for developer tools can include developers, dev leaders, CTOs, VPs of engineering, and where relevant SREs, QA, and security. On size he writes: "I have never seen more than 50. But two is not enough." In the later interview he recommends aiming for 50 people when starting, because roughly half of the conversations will not produce anything useful (Scaling DevTools).

The calls follow a fixed script. Frankl suggests about seven questions, asked identically of everyone, and a hard stop at thirty minutes because in his experience the second half of hour-long calls never produced anything valuable (What goes on in a TAB call?). His favorite opener is the "magic wand" question, which he credits to Cindy Alvarez, author of Lean Customer Development. Two follow-ups come from Andy Raskin: how the change would affect the person's life, and what is different about the world now that makes it more valuable than before. Raskin's own writing explains why that last question matters: a story that opens with an undeniable shift in the world creates stakes and urgency without putting the listener on the defensive.

After the first round of calls comes analysis. Frankl uses Alexander Osterwalder's Value Proposition Design and lists pains, gains, and jobs to be done for each persona, drops outliers, and merges personas that turn out to share the same problems (After the first set of TAB calls). He writes that going from a theoretical 12 personas down to 3 is not unusual. The team then takes the top pains back to members to check them. In a 2026 follow-up interview, Frankl lays out the arc of the early calls: the first is discovery, the second prioritizes the problems people named, and the third tests how much of a problem the product would need to solve to be worth adopting (Scaling DevTools).

Frankl draws on his own career for the method. The author page for The Developer Facing Startup, published May 17, 2024, says he cofounded or was an early executive at 12 VC-backed developer-facing startups, including JFrog, Neo4j, and Sourcegraph, and chairs the developer-facing track at Alchemist Accelerator. In a Scaling DevTools episode he describes the TAB as pieces he put together over decades of trying to get useful feedback, and credits Steve Blank for the idea underneath it: a startup is an organization searching for a repeatable and scalable business model, so its founders have to go and find out what customers need. The framework is built for developer-facing products, but the discipline of repeated, structured, no-pitch interviews carries over to any technical buyer.

Core Principles

Talk About the Problem, Never the Product

A TAB call is an interview about the member's problems. Frankl's rule is blunt: "These are not sales calls. Avoid mentioning your product. Do not do demos" (What goes on in a TAB call?). If a member asks about the product, schedule a separate call for that. Frankl says in a Scaling DevTools interview that a product demo is read as a sales call, and that people in a sales situation stop sharing information. Teresa Torres draws the same line in her guide to customer interviews, where sales conversations do not count as interviews at all.

One Person at a Time

Every TAB call is one on one. Frankl's reason is practical: in a group, the quicker person answers and the other nods along, so half the ideas are lost (Frankl). In a Scaling DevTools clip he describes running a TAB as being in the idea harvesting business. Most ideas will be ordinary, and you only find the good ones by hearing all of them.

Ask Everyone the Same Questions

Frankl asks identical questions of every member, whatever their seniority. Asking the exact same questions of 50 people, he writes, makes you "a connoisseur of the answers," able to compare how different personas respond and spot outliers (What goes on in a TAB call?). Consistency is what turns a stack of conversations into data you can compare.

Cover Every Role That Can Block Adoption

In a Scaling DevTools clip, Frankl compares adoption inside a company to picking a lock: every cylinder has to be set, and one closed cylinder keeps the lock shut. A developer who loves the tool is one cylinder. The person with the budget, the security lead, and the platform owner are others, and each needs a value proposition built from their own problems. That is why the board needs several members from every persona rather than many from one.

A Relationship With a Fixed End

The ask is small and bounded: thirty minutes a month for six months, stated up front, after which the arrangement ends (Scaling DevTools). The fixed end makes it easy to say yes, and the repeated calls let members get past polite first answers. Frankl also treats willingness to give that time as a test. If nobody will spare thirty minutes a month to talk about the problem, the problem probably is not important to them.

Appreciation, Not Compensation

Frankl does not pay TAB members or give them equity. He thanks them with swag, so they can tell peers they sit on a startup's technical advisory board, and he argues that cash makes the relationship feel like a bribe (Scaling DevTools). The implicit bargain is that the member's time will help solve their own problems. In the follow-up interview he warns that members stop giving time once they stop believing that, so honesty about progress is part of the deal.

Validate Before You Believe

Frankl treats founder assumptions as hypotheses that have to be tested with members before anyone acts on them. After the first round of calls he takes the synthesized top pains back to members and asks whether they agree, and expects the answers to force revisions (After the first set of TAB calls). Strategyzer makes the same point about the Value Proposition Canvas: fit is a claim until customers confirm it.

Steps

1. Name the problem and the personas Write down the problem area you want to learn about, stated at a breadth people can answer. Frankl says stating it too narrowly or too broadly both make the answers worthless, and that the best statements boil down to two or three words, like "universal code search" at Sourcegraph (Scaling DevTools). Then list every role you think influences adoption: users, their managers, the budget holder, and any security or operations gatekeeper. Treat both the problem statement and the persona list as hypotheses. The output is a one-page brief that the recruiting and the question list refer back to.

2. Recruit members one message at a time Find candidates through people you know and through LinkedIn, and send short, individual invitations that praise something specific the person wrote or did. Frankl's formula is "Thank, praise, and then beg," and he warns against batch-and-blast outreach (How to recruit TAB members). Expect most people to ignore you: he plans for 50 outreach messages per member recruited. Ask for thirty minutes a month for six months and offer swag and gratitude in return. The recruiting skill covers the targeting and message in detail.

3. Write one question list for everyone Before the first call, settle on about seven questions (Frankl). Open with the magic wand question within the problem area, follow with how the change would affect the person's life, and ask what is different now that makes it more valuable than before. Check each question for wording that suggests an answer; the Nielsen Norman Group's guide on leading questions is a good checklist. Keep the list fixed across members so answers can be compared.

4. Run the discovery calls Hold each call one on one, keep it to thirty minutes, and ask permission to record. Frankl says nearly everyone agrees, and recommends keeping transcripts confidential inside the company while sharing them among the founders (Scaling DevTools). Ask the questions, then listen; he writes that developers who are wary of strangers "will talk your ear off" about their own problems. Do not mention the product. If the member asks about it, book a separate conversation.

5. Synthesize pains, gains, and jobs by persona After the first set of calls, go through every transcript and mark pains, gains, and jobs to be done, plus the answers to the "what is different now" question. Group them by persona, throw out outliers, and merge personas that share the same problems (After the first set of TAB calls). Rank the top few pains for each persona that remains. Save the document; it is the agenda for the next call.

6. Take the synthesis back to members In the second call, show members the ranked pains and ask whether they match their experience. Frankl's suggested framing is that you have talked to a few dozen of their peers and these seem to be the top pains in their field, and he warns that the discussion will change your plans (Frankl). Record disagreements as carefully as agreement. Update the ranking after every few calls rather than waiting for the whole board.

7. Test how much of the problem must be solved In the third call, find out how large an improvement would change how the member works. Frankl's approach is to describe a result, either one an early user achieved or a clearly hypothetical one, and ask whether duplicating it would be compelling and why (Scaling DevTools). He is firm that you never claim results you have not achieved. The answers tell you the minimum a first release has to deliver and give you the raw material for the product story.

8. Keep recruiting and keep publishing When members finish their six months, thank them and let them go, and keep recruiting new ones so there are always calls on the calendar. Asked whether the TAB is a one-off six-month project, Frankl answered that in his experience the most successful startups are the ones that talk to the most users and potential users early on (Scaling DevTools). He also recommends publishing on the topics you learn about and reaching out to people who engage, which feeds the next round of recruiting. He says a surprising number of former members want to pick the conversation up again when you come back with something new.

How a TAB Differs from Related Practices

A TAB borrows from several customer discovery traditions. The table shows where it matches them and where it departs, using each practice's own sources.

Frankl's model differs from continuous interviewing on who does the talking. Torres prefers the product trio to interview together and warns against relying on one interviewer, while Frankl, in his follow-up interview, prefers one person running all the calls for consistency and treats the work as a founder-level responsibility. He has also seen co-founders split the calls successfully (Scaling DevTools).

When to Use

• You are founding or running an early developer-facing startup and cannot yet say, in the users' own words, what problem you solve. The TAB is designed for exactly this search, before the product or the positioning is fixed.
• Adoption stalls after good meetings with enthusiastic developers. Frankl's lock metaphor suggests another role, such as the budget holder or security lead, is blocking you, and a TAB with members from every persona will find it.
• You need a story for marketing and sales that developers find credible. The "what is different now" answers and the members' own language are the raw material for that story.
• You are entering a category where developers already have tools, and you need to find which pain those tools leave unsolved before choosing what to build.
• You have a few early users and want structure around talking to them, so that what you learn can be compared across people and does not stay in one founder's memory.

When Not to Use

• You need a statistically reliable answer to a narrow question, such as which of two onboarding flows converts better. A few dozen interviews will not give you that; run an experiment instead.
• Nobody on the team can commit to a monthly rhythm of calls and analysis. The value comes from repeated calls and from comparing answers, and a program that stops after a few calls leaves you with anecdotes.
• The buyers and users are not technical and do not share developer culture. The method will still work as structured interviewing, but Frankl's developer-specific advice on recruiting, swag, and skepticism toward vendors may not transfer.
• You want expert advice on how to build the product. That is the job of senior technical advisors, which Frankl keeps separate from the TAB.