Creating a technical advisory board is the single best action that you can take as a DevTools founder.

A founder is not like an executive at a miniature corporation. Startups are not miniature corporations. Okay? Corporations exist to execute a proven business model. And you bring in executives who are expert at their functional area to execute.

Whereas what founders do is founders are searching for a new business model. This is not original to me. This is Steve Blank. It's not gonna happen naturally unless you make it happen. And so after decades of working at it, right, I finally put together the pieces and figured out, okay, how can I create a system that is gonna give me feedback in a way that's actually valuable to the people that I'm working with?

Yeah. And it's it's a lot of different pieces that all came together to form what I call a technical advisory board.

That's Adam Frankel. I spoke to him previously about his book, The Developer Facing Startup. He's been the VP of marketing or an early executive at three different DevTools unicorns, including Neo four j, Sourcegraph, and JFrog. Adam came up with the concept technical advisory board and talked about it in the episode we did. But in this episode, I wanted to just kind of really summarize those parts.

So just cut out all the facts, just talk about technical advisory board. And also, I've been doing it myself, so I wanna share a little bit about, like, the stuff that I've learned in case you're trying to do it and what you might hope to actually get out of it. And since I'm not actually affiliated with Adam, I think it's kind of a different vibe because I'm not trying to pitch this concept. I just think it's useful and these are my experiences doing it. Okay.

So what is the technical advisory board? I think Adam Adam says as well, the funny thing is it's not technical and it's not an advisory board. It's basically a group of potential customers, potential users, or maybe actually current customers, current users. And you don't ask them for technical advice. You talk to them and learn about their problems, their challenges, and you use that to shape your what you build as well as how you talk about what you've built.

And what does a technical advisory board actually involve? It involves meeting with this person one on one for six months, once a month for thirty minutes. So it's a total of like three hours of their time over six months. I'm gonna talk about what you actually talk about in each of those thirty minutes. But the important thing is you're not pitching them.

It's not a sales it it can have sales benefits, but it's not a sales process. It is a learning process. Before we start talking about how to recruit tab members or why they would wanna be involved anyway, I'm gonna go straight to the first interview that you do with them so that you can understand what a tab is kinda like. Okay. So what do we talk about in the first tab call?

This is what Adam has written. You can find this blog post in the notes. So Adam says, before starting your tab calls, you figure out your question list. Seven is about the right amount of questions. You'll not have time for more.

Personally, I've never got to anywhere near seven questions. And he says keep it very short. He's never heard something valuable in the second thirty minutes. So be very tight, you know, time conscious, press into it. Okay.

So these calls are all about finding the pain. Once you have identified the topic so when we say topic, it's like could be, you know, for for our site, what I'm working with is like building more voice AI. So that's kind of the topic problem area. And so we've identified that and then we say, if you could wave the first question, Adam's favorite question. I think this is definitely the best question.

If you could wave a magic wand and be able to do anything that you can't do today, what would it be? Don't worry about whether it's possible, just anything. And I usually say within the realms of voice AI, if you could wave a magic wand to anything, what would you wave at? That's how I phrase it. This kinda comes from someone called Cindy Alvarez, author of Lean Customer Development.

So this kind of question is extremely useful because I think the key part here is, and maybe this doesn't need to be said, but if you lead people, the stuff is not very valuable. And it's amazing how easily there will be led. After you've done a few of these, you see, if you as soon as you seed someone with it, they'll happily just agree with it. That's important. Or like, they'll stop.

They'll bypass the thinking process and just go, yeah, that that that's an important part. So you're not seeding them of anything. You're just saying, okay, within this problem space, if you wave the magic wand, what would you wave that out? And you can maybe even not say that, but you might get answers very far from what you're gonna solve. So that's the main question.

And if you just ask people that, you'll probably get like like most of the benefit, I think. Scaling DevTools is sponsored by WorkOS. At some point, you'll land a customer who needs enterprise features like audit trails, SSO, role based access control. You could spend ages tearing your hair out building these things yourself, or you could use WorkOS. Let's hear from Uppal from digger.dev.

I can speak for open source companies because I think that's where I have the most experience personally. If you're open source and you're doing enterprise first, the minute you think about monetization is when you should think about Work OS. How it's designed is that you can start as early as day zero. But for us, it wasn't day zero. It was closer to when we first started monetizing because we didn't have a sign up at all.

People could just anonymously use our tool. Be honest, if we do that again, I think we'd think about that on day zero, to be honest, because, like, should have done it on day zero ideally. Anonymous usage should be permitted, but you should know who's using your tool. It should be opt in, 100%. But it'd be great to have auth from day zero.

So, yeah, that's what I think.

Thanks, Work OS. Back to the episode. So the next question is, how do you imagine this would change your life? So if we were to able if you were able to have that change or, you know, for that to exist, how do it change your life? And this is kind of the answer of like what you're selling.

So it's like for us it could be like if someone could wave a magic wand and have like perfect transcription for instance. Then it would mean like perfect transcription in low quality audio environments might be like something they say. And then their AI makes less mistakes because it has perfect audio or something. What whatever they say. This next question is about finding why now and, like, creating urgency.

But it's a harder question to ask, I think, and people sometimes get confused. What's different about the world now such that what you just described is more valuable than it would have been, say, five or ten years ago. And by the way, like, five or ten years ago, I think now for most things just doesn't make sense to say, like I I usually say, like, a year ago or six months ago because things are just changing so fast right now that I think five or ten years ago is just too long. But maybe it varies customer to customer, but talking to start ups is just very fast changing. So that helps you create urgency.

And okay. So Adam says, when you do when you get people talking on topic, you just need to listen sympathetically. Devs and others who are reluctant towards strangers will talk your ear off if you get them on the topic of their own problems. Yeah. Definitely true.

Okay. So that's like what a tab the first tab meeting involves. And the only thing I'd add in here is like I I tend to ask like, besides this, what other problems would you what else would you wave your magic wand? And just keep going like around that. And sometimes you kind of have to like dig in to like the problem of the problem and like it's it's definitely like an art.

And some sometimes like you just the rabbit hole is like something that you just know that you're not gonna ever solve and still very interesting to learn because you understand their perspective and it helps you with like just just having a better picture of the world. But like sometimes it definitely goes down rabbit holes that like you're just never ever gonna solve, but that's okay. And then one final thing is do not do group interviews. All your tab calls should be one on one. If you interview two plus people at the same time, the quicker person will answer your question or the other just nods or nods off.

You need to harvest all their ideas, so capture them one on one. It's a waste of time for the second person, basically. And one one more thing with the tab call. And this might go without saying, but you need to record it. So use Zoom, use Google Meet, record it, use Granola for transcription, call notes as well, stuff like that.

And, just make sure you you log everything. Let's quickly talk about why anyone would want to join your tab. It sounds like they're just giving you free like user research. Right? Are you paying them?

Are you giving them equity? What why would anyone wants to join? Okay. So the first thing is you don't give them equity, you don't pay them, you give them swag, and you give them appreciation and gratitude. The people that you want will care enough about this problem and like talking about it enough that they're happy just to talk to you about it and that's enough payment for them.

They don't need equity or anything like that. And so you should lead with swag and appreciation. Don't make it about money or anything like that. Okay. And then how do you recruit them?

So surprisingly simple stuff really. It's all the things that none of us like doing which is just like cold emailing people, messaging them on LinkedIn. And but the the good news is that this is not like the typical, know, hey, you wanna try out my solution? It's more like you have to just resonate with, talk about the problem that they have, talk about them. And you're inviting them to be on a technical advisory board and peep some people will find this, you know, something that's great for their career.

They can talk about it, put it on their LinkedIn, stuff like that. So you are providing value as well. It's not just the typical cold DN that you're sending. So you will get a better response rate. I'm gonna share an example that Adam has written.

So he talks about finding people that have like written about this problem on LinkedIn or like you just kinda know based on their start up that they've got this problem. Here's an example of one of the emails that he sent. Dear Anne, thank you for reading this email. Your post about problems, so might be like building with voice AI was very insightful. I founded a startup to attack the problem of building with voice AI.

It would be great I would be grateful if you would consider joining my technical advisory board. If you're interested, please reply and I will set up a time for a short chat to discuss what this involves. Thank, praise, and then beg. Find something unique to praise them for, A post, a tweet, two years at a company you admire, maybe a fellow college or company alumni. Don't batch them last.

If you don't have time to research each person, you don't deserve a reply. Devs are very busy, so most will ignore you. That's okay. You're gonna reach out to 50 people for everyone that ends up on a tab. You want 50 tab members, so that's 250 outreach messages.

It will take a while to start today and send 50 messages out every day. There is no better use of your time. That's a galvanizing call from Adam. And I think it's true. And, you know, if you're already building in this space, you probably already have a lot of like connections with people that are building.

And so you can just ask those first of all. And I think you can bootstrap your tab with that. So I don't think you have to go directly to cold DM ing unless you don't have any of those sort of people in your network, in which case that's a good use of time anyway because you should be talking to those people. So that's how to recruit for the tab. Okay.

So let's talk about the analysis after the first call. Okay. So let's say you've run, you know, eight, ten tab calls with the first call. And now it's time to do some analysis. Adam's favorite framework for doing analysis is value proposition design by Alexander Ostobolder.

So for each persona, list out the pains, gains, and jobs to be done. Gains are not just negative pains, but aspirational aspirational achievements. Adam, if you're listening, will hate me for saying this, but I kind of feel like just focus on one persona because this stuff is really a lot of work. And obviously it'd be better to do it for like lots of personas, but speaking for myself personally, I'm just doing it for like basically start up founders or very early stage. Engineers at very early stage developers who are building with voice AI.

I'm not we are doing a couple of other personas like because we have them, but we're not like really focusing on that just because it is so much work just to do the individual persona. So you can disregard that and Adam will be probably cursing my name when he hears that, but that's my view on it for a startup. If it's you, plus you've also got to like write code, write docs, build the products, like it's a lot of work. I would say focus on one persona right now. And, you know, the most the the one that you see the most potential in.

So in your tab interview notes, go through and highlight pains, gains, and jobs to be done. I also highlight the answers to the changes in the environment question. Now group them by persona and throw out the outliers. If you have multiple personas with the same pains, gains, and jobs, collapse them down into a single persona. It is not unusual to go from theoretical ten, twelve personas down to free after doing the research.

So, you know, I think for this nuance, go straight to Adam's book. You're not gonna get the nuance in this episode or go ask Adam for advice. But, yeah, collapse down your personas. Now okay. And so so that's really it.

So essentially, you should have like an excel sheet or something and make a note of all and you you can use chattypathy as well for this to pull out all the points that they say. And then you mark them as like gains, pain pains gains. So pains being like transcription in low quality audio environments is bad. It's like a pain. It's not good enough pain.

And then like, again, it's like if we had good quality transcription in low quality audio environments, we would be able to do this other stuff or something. And then jobs to be done is like, I guess like transcribe. I I found that bit like harder, but tran transcribe transcribe audio in low quality environments. And the changes in the environment could be like with AI, there is more possibilities to do stuff with those transcriptions than there was six months ago, stuff like that. And then you wanna mark down the top three of those for each and pay particular attention to the pains and the gains and particularly the pains because I think this is where the money is.

That's that's the real value piece of this is these things are not equal. I don't think the changes right now is like anywhere near as valuable as the pains the pain. If you can identify the top three pains of your persona, that's like that's the gold I think. And may and maybe it's just because we're at that stage where that's just we don't have that. So we're not thinking too much about the changes as much until we have the paints really locked out.

Okay. So that's what you do. And then you go back to yours in your second tab call and you share. You literally can just share that document, screen share it, and just say, what do you think of these? Is this right?

Does this match your top three pains in building with voice AI? And they can be like, no. I I don't think this first one. Right? That's not a problem for us.

Or they'll say, you know, our biggest problem is actually just, evals. Right? Or just knowing knowing if a conversation was good. I'd be like, we don't care about we don't have a problem with transcription. Well, like, we don't use transcription because we use real time audio models and we don't even get involved in the transcription.

So it's not an issue for us. Well, we haven't shipped yet. So we don't have this problem. We just have a problem of like building fast. I don't know.

Like, it's very helpful to be honest because it kind of is you can almost, you know, obviously you should try and group the top three, but they're gonna tell you if it's wrong as well and everyone's gonna have different opinions on this. So yeah. I I I think like I don't have a good sense exactly on like theoretically how to do all this. How to then if someone says something and then someone else says a different thing, like how do you weigh those? I think there's a lot of gut in here, a lot of like instincts, I think a lot of just like taste if you just talk to a lot of these people and they talk about their problems.

You start to feel like, this one this person was like really passionate about this problem. So maybe gonna wait a bit more than hearing it multiple times, but like kind of lukewarm from someone else even though it was their number one. It's definitely an art, not a science. So in the third tab call, Adam says that you can start to develop your story and start to share that and just get feedback from them on your story. So Adam has a whole thing in his book about like how the customer should be the hero and there's this like dragon that's the problem and everything should be framed around that.

And it's he talks a lot about like, you're not talking about you as a company. You're talking about the problems. You're talking about the industry. You're talking about the space. So you continue.

Adam has some guidance in the book about like the third, fourth, fifth, sixth meetings. But it's a little bit less like clear on it. I'd love to actually get him back on and talk a bit more about what you do in those beyond that. But I think it's lots of just you start to share the product, you start to do demo things, you start to, like, get just get more feedback, starts to just continue talking to them about the problems, and you just learn a lot. But I think the first two or three meetings is where most of the value is, to be honest, from what I can see.

And, yeah. So that that's technical advisory board. And I think that if you're thinking about an MVP version of this, pick a persona, you know, solid founders building in this space, something like that. Try and line up 10 tab members from your network, reach out to a few other people as well. Make sure you do the first, second, third tab calls, maybe people will drop off.

Get them some swag. And I think you're gonna learn a lot. And you can also use like Chat Your Petites to do some of the analysis. So I think you can get quite far with like not tons and tons of work. But the more you put into it, the better it's gonna be, of course.

If you found this interesting, we can do another episode where we dig a bit further into the second half. And I'd love to have Adam back on to talk about tabs again now that I've gone through it myself. Thanks for listening.