The Developer Tools playbook, with Adam Frankl - VP of 4 DevTools unicorns

If you're just a technologist and you're cranking out code, you're not an entrepreneur, you're a hobbyist. Yes. This okay. This is so important. This is what founders do.

I was thinking, one of the things I really wanna talk about was the, the developer, board.

Technical advisory board. Technical advisory board.

The tab. The technical advisory board. I feel like that's one of the huge topics.

Absolutely it is. I feel like I I think that's probably the most important concept in the book and the one I get the most questions about.

Yeah. Because I feel like most people aren't doing this and

And they should. They should be. In fact, not most. Everyone should execute a technical advisory board. Yeah. There's no reason not to.

Yeah. Do you think this is, like, the one of the biggest reasons that startups fail?

Absolutely. No. Let let's say the biggest reason is this part of the interview?

Well, I was actually thinking it could be. Yeah. Like, it was like Sure. I feel like that would actually be on sound bite. I'm like, the biggest reason.

The biggest reason developer facing startups fail is they're not listening to developers. That sounds kinda obvious. Yeah. Right? Okay. But what's actually hard about it is that if you're a developer and you found a startup to solve an important developer problem, your natural inclination is to write code. Yes. That's what developers do. Yeah. Okay?

all day.

Okay? Is that number 1, they're not technical. Number 2, they don't give advice. And number 3, they're not a bork. Okay? It's just the technical advisory board is what it's called.

Yeah.

Okay? So number 1, because lots of people have tabs. Right? They think, okay. I know some smart technical people that can give me advice, and my last boss thought I was amazing, and I'm gonna I wanna get technical advice from them. And my dissertation adviser, I'm gonna call them up, and and they should give me technical advice. So this is what they think goes into

a

a technical, an advisory board that is technical. But that's not what a technical advisory board is about. Okay? You start with the problem first. I can look at the camera. I can look at you. Yes. Start with the problem first. Okay? And then you want to talk about the problem with as many developers as possible.

Yeah. That so okay. So playing that back, it's like developers actually do wanna talk to you about a problem. Yes. And that's what you need to spend a significant amount of time.

The developers aren't gonna be reaching out to you, though. Right? That's not their job. Their job is to solve the problem. Right? It's your job to find these developers and ask them about the problem and then listen to them when they start talking about the problem.

So how do we assemble this team this, these developers that we talk to? Do we talk about talk to them on an ad hoc basis? Like, what do you advise?

Thank you for that puffball question. Okay. The question is is how do you assemble them? Right? And the the first rule I'm gonna tell you is don't assemble them. Okay? Even though I call it a board, you actually wanna have lots of conversations 1 on 1. Okay? You never wanna interview 2 people at the same time because all that happens is the faster person will talk and the other person will just nod their head or nod off or lose focus. Right?

is great. Yeah.

Right? Everyone you ever wanna meet is there, and their resume is on LinkedIn. Right? So you need to come up with some hypotheses. When I say you, I'm I'm assuming you're a founder of a developer facing startup. Right? So you just come up with some hypotheses about who's influencing the adoption of your technology. Right? A wide range of of job titles. And then and companies and types of companies and countries, and then go look for them. Right? LinkedIn is great for this.

And when you say influence, I guess you're saying that specifically because it's not just

it's not just developers. Yeah. That's that's another tricky part. Okay? So the metaphor that I like to think about is that if you're gonna get your technology adopted by an organization, right, it's like picking a lock. Every cylinder is at a different setting. And you need to find the correct setting to open each cylinder. And if all of them are open, then the lock will open. If you miss 1, the lock stays closed. Okay?

Yeah. So I'm not early adopters.

You well, yeah. Exactly. So you need to have a value proposition for everyone involved in bringing your technology into an organization, and you need to be talking to them. Right? And the only way to construct a value proposition is to understand what the problems of that unique role are. Yeah. And the only way to understand what those problems are is to talk to people in that role.

Yeah. One of the questions I have on this, is that I've tried to do a lot of user research from before. Like, well, I have, like, a hypothesis and I'll line up, you know, say 10 interviews. And the the maybe the first what I often find is that you get, like, a mixed you get very mixed, like, reactions to the problem and stuff like that. It's, like, how do you like, do you try to find, you know, like, say someone's like, yeah.

That's it. Everyone has problems. And absolutely, if you have if you have a product that solves a problem for half the people necessary to bring it into our organization but does nothing for the other half, it's going nowhere. Yeah. Okay? You need to work with, quote, the other half, whoever they may be, understand what their problems are, and come up with a value proposition for them as well.

But what if it's like let's say I was, like working with someone that's like I'm like I'm trying to make it easier to like process for developers working with video pipelines or something, and then the first person I speak to is like, yeah, this is like we do this. It's like on fire. And then the next person I speak to is like, we don't do any actually. We don't do that. Like is it like within that sort of thing, how would I, like, bring it so it's, like, relevant to that person?

So first of all

I shouldn't say discard. Anyway, so it's a bad choice or what.

The what I recommend and this is this is a key problem because everyone's an engineer, and you wanna talk about the product. Yeah. It's burning. You need to talk about it. So we're already

doing that when I'm saying it to you.

Yeah. Yeah. And you gotta stop talking about the product and start talking about the problem.

So how would you for that specific case, like, how are you

Okay. Maybe there is a question recommend. Okay. This is what I recommend is that you come up with a list of questions ahead of time.

Mhmm.

Okay? And you ask exactly the same question to everyone you get a TAB interview with. Yeah. And my favorite question is, okay, is what I call the magic wand question. Yeah. It's not original to me. I mean, I read it in Cindy Alvarez's book. She wrote the book, you know, Lean Customer Development 10 years ago. Great book. Okay?

No. If you ask this long question, we need this long question.

If you could wave a magic wand and change anything about how you do the problem, right, what would it be? Don't worry about if it's possible, just anything. Okay. And then you shut up. Okay? And people will think. And what you're redoing what you're doing is you're resetting the frame. You're no longer discussing a product that you may or may not have developed. Okay? Now you're you're in you're changing the frame in that person to be, okay, something about this.

Mhmm.

Right? I could deliver 10 times as much video in a day as I do right now or a 100 times or cut the processing time by a 1000 x. Right? Now you know what people are willing to pay for. Right? So those are my 2 most favorite questions.

Yeah.

And I've got a third question, my 3rd most favorite question, which is, what change is going on in the world that makes what we just described more valuable than it was 5 years ago?

That's a good question.

Okay. It is a good question. Because what you're looking for, you you want to create urgency Yeah. In your users. Not fake urgency, like, oh, sales and need to quote close this thing or the prices up.

Okay. This is amazing. So I'm just playing this for myself. I hope everyone else finds this useful, but at least this is very useful for me. So let's say I'm looking at, like, video processing.

If you could change anything about video processing, video development, however you wanna phrase the question, what would it be? Don't worry about if it's possible, anything.

And I listen to this. Yeah. And then I say, if we were able to do that, what how would that

change your life?

How would that change your life? Okay. So the first one is the problem that I want to solve for them. The second one is how I present that to,

what they wanna buy. Yeah. Right? Why would they be interested in improving how they do video processing? Well, I I don't know. Yeah. Do you have any idea why?

I think the the thing that I'm working on is just making it easier. It's just, like, saving them a ton of time. Okay. Oh, no.

I'm I'm yeah.

That's Yeah.

Air being sucked through teeth there. Okay. I really hate the word easier.

Okay.

It's not the worst word, but it's pretty bad. Yeah. Okay.

Hey. I'm so

As a developer, when a vendor claims they're trying to help do something easier, it's like, yeah, I don't believe you at all. Yeah. Okay. So if I see the word easier and it's not immediately backed up by a testimonial from a developer

Yeah.

Not only do I not believe you, but your credibility has decreased that you couldn't come up with something more specific about what you do.

Yeah. So I guess it would be more like making sure the FFmpeg is available. It's, you know, wrangling with s 3. It's like making sure there's enough memory to process the video that

That's better. Like It's better. Okay? But, anyway, let me tell you. I've I've already using my worst word, which is better. Okay. Okay. Never use the word better. Just sloppy thinking.

Okay.

But for each of those examples you can run both, can you quantify it? Quantity numbers make it real. Okay? But it's still only half real. It's only actually real when a developer says it.

Yeah. So

because here here's the essential problem, what gets the heart of everything I'm doing. Okay? You may be a talented open source developer. You may have written books. You may have given talks. Right? People believe what you say. But now you're a vendor.

Okay?

Your credibility has suddenly dropped to 0 Yeah. Because every other developer assumes correctly that you're trying to sell them something. Yeah. And we know how to deal with people trying to sell us something. So it's like, nah. Yeah. Close down. Close down. Right? And so if you're a vendor, you can make assertions, but don't think people will believe them just because you're making them, especially if you're claiming you're better or easier.

So when you do say something and you back it up?

Pack it up with social proof. So Uh-huh. For developers, social proof is the only proof. You can give demos, you know, till you're blue in the face and explain how it works, and you're still lying. Yeah. But if a developer said it, then it's true.

That resonates with me. I recently started using Cursor, and it was only because 3 or 4 people pretty much implored me to use it. I was like, oh, it must be good.

Yeah. That's it. That's it. And so many people, they mistake their assertions for actual proof. No. No one believes their assertions.

If I say something, no one's gonna believe.

If you say something as a vendor, it's false. Yeah. If you say something as a developer, it's true. It can be the same thing.

Yeah. And I guess especially if it's a developer that they know, like a respected OSS developer.

And that's the that's the amazing thing about social media is you can actually influence people, and then the people you influence can influence people they know. Yeah. Right? Social media is a great gift for developers, which which leads into another whole topic. Yeah. Developers are the most social profession ever. And this comes as a shock. Right? Because most people, you know, they understand the stereotype of the lone developer

Yeah.

Right, with the weekend project. Basement dwelling. Basement dwelling. And while it's true that many introverts become developers, okay, it's also true that to be an effective developer, you have to communicate with other developers.

Yeah.

And every developer that's out there is is has problems. And the first thing they think about when they see a problem is, I'm not the first person to have this problem. Yeah. Right? I'm gonna do you know, I'm either gonna search or I'm gonna ask chatgpt, right, or look in developer social media and see who else has had this problem and how have they attacked it.

Shout out Sourcegraph.

Yeah. Yeah. Full disclosure, I was the first VP of marketing at Sourcegraph. Great product.

Yeah. And you have to say that because developers always have to be truthful. Right?

Yes.

Full disclosure. Actually, I we didn't do an intro. So Oh, intro. Hi, everyone. You're listening to Scattered Dervitals. I'm joined today by Adam Frankel, who is, who goes by the name occasionally of Triceratops because you were, the VP of marketing at 3 different

I was the 1st VP of marketing at 3 developer facing unicorns.

So JFrog

3 horns. Yeah. JFrog, Sourcegraph, and Neo 4J.

And you have now written a really good book, which we if you're watching the video, you can see out there. Developer facing startup, which is really good, and I think everyone should read it because you've from my perspective, here's my social proof, is that you've done a very good job at putting, like, formulas to something that feels very non formulaic. And I can say that as someone that's now interviewed, like, a 100 people about how to grow developer tools startups. I often feel quite muddled because people have very different advice and, you know, there's many ways to actually approach it. And what I like is that you've created a very, like, systematic approach that someone can follow and, succeed.

Yes. Yes. And yes. So, yeah, that's why I wrote the book. Well, actually, I can talk first of all, the whole book is designed to be a process, and in fact, I'm turning it into a course.

Yeah. I think that's actually an incredible goal, and I definitely resonate with it. I feel like especially as, like, developers are making the world better, if you believe that, which I do. It's, like, giving them the tools they need to do the a job better, and as you said, adoption is.

Yeah. And I'm I'm certainly never claiming that I've figured out the only way to be successful. Alright. There are there are many ways to be successful, but I have figured out some baseline truths. Right? And you can apply them. You have to customize them for everyone's unique situation. But here is some some fundamental things that you need to do if you want a product to be widely adopted by developers.

Yeah. And I think the, for most people who are building a developer tool startup, they probably don't really care in a sense if they get, like, how their product becomes adopt you know, widely adopted. It's more like they care about the problem that they're solving. And so if you can just give them a thing that works, it's like they're not gonna be like, oh, no. I I don't like this style. I want my own style that's like, you know?

Great. Make your own style. But but there are certain truths here.

Yeah.

Right? And and there will be exceptions. Right? But if I think back in my career, I've actually been a cofounder or early executive at a dozen venture backed developer facing startups. Interesting. First 9 of them all failed.

That's also I feel like that's that makes the free the work so much more interesting as well.

Yeah. And well, I don't I don't say they all failed. Some of them some of them were pretty successful, but but they were not

Not like unicorns. Rational

software, they were bought for a $1,000,000,000 by IBM. This was like 30 years ago. So I could say they were they were pretty good. But you there

wasn't a

But today's standards

There wasn't like a 4 horns dinosaur that you wanted to

No. There is a 5 horn dinosaur,

but there

was no 4

horn dinosaur,

but no one knows the the coin, you know, winteris offs or whatever. It's like triceratops, I'll stick with it.

Yeah. Yeah.

Alright. So but here's the difference. The difference between the ones that succeeded well well, actually, let me give you more of a story. Right? So I'll give you my personal story. How did I end up here here in this living room in San Francisco?

Yeah.

Right? Is that I'm I'm a former developer. Former. I haven't written code in professionally in many years. Right? But I started off writing code. I have an engineering degree. I worked for Lockheed Skunk Works writing code for the f 22.

Which is super cool and the sort of thing that should also be its own podcast anyway.

Its own but Lockheed Skunk Works is a crazy place. And and it is an interesting angle because you compare Skunkworks with today's startups, and they have some things in common and some things are entirely different. Okay? I can get to that later if you're interested.

Yeah.

Okay? But while I was there, we had a presentation from the CEO of a DevTools startup. And I told told him, says that we like the tools. We're gonna buy them. But you don't really know how to talk to developers. And that's a crazy comment. I was like 25 years old. And that crazy comment turned into a conversation that turned into a job offer that I took, and I became that startup's first product manager. Right? That was about 30 years ago.

I've seen some of it.

To me, it was absolutely amazing. Don Draper. Right? Don Draper. Yeah. And I had this brilliant idea. Okay. This is what I'm missing. Right? Marketing is supposed to be about being clever. Yeah. No one was more clever than Don Draper. And so I began adding cleverness to everything I did. Clever campaigns, clever taglines, clever websites. Right?

Oh, cool.

Get out of the building and talk to customers. And so I thought, okay, What if I got out of the building and went and talked to developers? Right? And for someone who had spent years being clever in conference rooms, this was quite a revolution.

An epiphany.

But I said, alright. I'll try it. An epiphany. And it worked. Okay. And the more I talk to developers, it's hard to talk to developers. I figure out ways to do that and how do you find them and what do you talk to them about? How do you think about what they're telling you? Right? And it it took a lot of trial and error to figure out a good way to do this, but all of the best ideas for how to market and promote and sell developer tools all come from users.

Yeah. That's amazing. And so we're kinda bringing it back to, to the stuff we're talking about with, like, the technical advisory board. That is how you that

is how you do it. Okay? But first of all, there there's so many different aspects of this. Right? The first aspect that I wanna communicate is you don't pitch people and say, let me get on Zoom and show you my product. Okay? That that sounds awfully tempting. No one wants to see your product. Okay? The way that that's interpreted is, okay, this is a sales call.

Mhmm.

Okay? And each aspect of that is really important. First of all, if the problem is important to people, they have 30 minutes a month.

Yeah.

Okay? There's no way it says, I can't fit that into my schedule if the problem is important.

Mhmm. Right? So it's a good filter. Yeah. For you to understand if it isn't important. Yeah. Because if they don't agree to that

Then it's not important for them. It's a good thing for you to learn that if no one will ever take a 30 minute meeting with you, then you are not attacking a problem that's important to anyone. Time to rethink what your startup is

about. Yes.

Okay? But it's also important that this is not a transactional call. This is a relationship. That's why you wanna say, I wanna do this every month for 6 months. Okay? Because they're not gonna trust you the first time, first call. But by talking to them over time and by bringing valuable information to your TAB members, you can establish a trusted relationship. Now at the same time though, you're not getting married. Right? You say right up front, it's for 6 months.

That's that's, I I really like that actually. And how many people would you typically

That's a great question. I recommend when you're starting off that you aim for 50 people.

50 people?

Yeah. Okay. Okay. Yeah. That's that's not it's quite a lot, but I found that half the people you talk to, you're not gonna get anything valuable from. Right? The way you overcome that is you talk to more people. You don't try and figure out ahead of time who's good and who's bad because that's not possible.

And what would you consider maybe this is obvious, but what would you consider as, like, a good good conversation and what's not a good conversation?

That's a great question.

Okay. A

great conversation because the point of these interviews is not to have a conversation. Okay? That's something that people take a while to get used to. Conversations, they start on topics, they go to other topics, they roam around. These 30 minute calls are not conversations, they're interviews.

That makes sense.

Okay. There's there's another thing that we haven't touched on here, which leads back what I talked about earlier, the wide variety of personas. Yeah. Right? You need to include representatives from every type of persona that you're dealing with in your technical advisory board. Right? You can't just talk to developers. Right? If you have to talk to their managers, right, this depends it differs by product. Okay?

And in terms of categorizing as developers, is that important because you would group everyone?

Everyone yeah. And I have to say even though CTOs and VPEs, right, they're technically not writing code anymore. They used to write code. Yeah. Culturally, they're developers, and you need to talk to them because they will have problems. And often, the problems first of all, no one knows what anyone else's problems are. Yeah. This is just the truth. You can sit next to someone for 10 years

Yeah.

Okay? And yet you're asked what are his or her top three problems, You'll have no idea. You know your own problems. You know them pretty well because you were thinking about them last night at 2 in the morning. But your friends' problems, you've got no idea.

many of each persona would you say? Because you've got, like, 5th like, 50 altogether.

Well, the first thing to do, right, is is when you start off, make a hypothesis about every persona that could possibly be interacting with you. Interesting. Most of the companies I deal with, they come up with a list of around 12 different personas. Okay? Then when you're constructing your tab, you need to invite multiple representatives of each of these personas and interview them.

And multiple is like At least 2.

5. Ideally, 5. Okay. You get what you can get. Okay? And then you discover if they answer in effectively the same way to your questions, then you can collapse the personas together. So you might think the VPE and the CTO are different personas, but when you're asking these questions, they give you fundamentally the same answers. Okay. From your perspective, it's the same thing. It's the technology executive.

Yep. So I feel like the if we're talking to founders, I feel like the reaction is, okay, 50 people, once a month, half an hour, You know? And there's always work. There's always work around the time. Right?

Think, oh my god. That's like my

full time job almost.

Yes. This okay. This is so important. This is what founders do. This is what founders do. I'm repeating it. Because a founder is not like an executive at a miniature corporation. Startups are not miniature corporations. Corporations exist to execute a proven business model. And you bring in executives who are expert at their functional area to execute.

Great. I wanted to let it sit. I feel like that's let's scratch the previous sound bite. I feel like that's the sound bite. If you're worried that you have so much code to write, you have so many things to do, and you don't have time for this, then you're actually kind of thinking about this backwards.

Correct. Correct. Yes. Then and there are some definitions here that I like to use out. Like like inventors are people that create new technology. Innovators use new technology to do old processes in new ways. That's the very definition of the word innovator. So if you're in a startup, you could be an inventor. You're probably not an innovator. Your customers are the innovators. They're using your technology to do some existing business process some way new. Right? Some way better. Yeah. Right?

Yeah. There's a there's a soccer player, football player in, in England or in the UK and every time, like, someone says, like, oh, this this guy's great at defending or whatever, he's like, that's your job. That's your job. Anyway, I feel like that's it. It's like customer is, like, actually talking to users. Like, if we say a company is good at that or a founder's good

at that, that's your job. This is the founder job.

Yeah.

Okay? And that the kind of a founder's job is kind of to put themselves out of a job. Right? At some point, you could say, I figured out the business model. I figured out what product we need, and I figured out how we're gonna get it to market and why people are gonna use it and how we're gonna support them.

Founder mode.

Yeah. This is what founder mode means. Founder mode means you are paying attention, right, not to everyone, but to a certain set of people that you are using to figure out where the market is going so that you can make changes to your product, to your company, to your go to market model, whatever needs to be changed, right, to go fit that new emerging need in the market. Yeah. Right?

I really want people to do this. I feel like I I wanna do it for myself. I I I'm like I put my hands up like I have not been doing this and it seems so obvious and so when you explain it like this, it's like

When I explain it, it sounds like why I haven't been doing it. But yeah. Yeah. It's hard because it's a change in cultural mindset. Yeah. It's like, oh, I'm an engineer. I'm a good engineer. I'm a brilliant engineer. I see solutions to products. I should be able to create solutions to this product. Right?

I feel like the more even the more common one because let's give people the credit of like, they are like, you know, they they they're not just building a solution because they've seen the problem themselves, and so they're, like, I'm an expert in this problem because I experienced it themselves. But I but I think it's still people need to do this. Right?

Yeah. You're right. Just because you have an idea does not make you an expert.

Yeah. It

means you have an idea. Yeah. Alright? You get to Or even even experience the idea. You've experienced it. You that that means you've experienced the problem. Or if you study if you study it and you do research on it, right, you could become an expert. And when I say research, research is not something that you need, you know, a lab, you know, or a PhD to do. Research, it's only 2 parts to research. 2. That's it. Okay. Number 1 is you have an original idea. Number 2 is you publish. That's it.

For one one thing is that.

Oh, there it is. Great. Yeah. Alright. And these are the influencers. You follow them on x. Okay? If you're giving a talk at a conference, you you wanna you wanna hear what they're gonna say. You watch their videos on YouTube. Okay?

Yeah. Yeah. And it sounds actually a lot more accessible than the pure facts of, like, being an expert because I feel like when you're solving a problem that you're not being very specific on, you could end up down in, you know, an area that you're actually not

Yeah.

An expert.

Here's the key. You could go buy a 100 books and lock yourself in some dusty library and say, I'm gonna make myself an expert.

Yeah.

Okay. And I guess this is what people used to do in the old days 20 years ago. They used to go get PhDs in this. Right?

Yes.

Don't do that. Don't do that. Alright. Instead, become an expert with a problem by interacting with people who experience the problem, have the problem, maybe they solve the problem every day.

And that's because people care about, people don't care about, like, clever No. Things. They care about actually solving their problem in your

That's correct. Right? And remember, right, vendors, 0 credibility, developers, a 100% credibility. So if you say, I'm an expert. I've studied this problem for decades, and here's the answer, like like I'm doing in my book currently. Right? Right? You think about how you would believe that. And if you had someone else that said, I talked to a 100 experts in this field, and here's what they widely agree on. It's like, I'm ready. You tell me. I wanna know that.

Yeah. I think you actually told me to write the I should write an article that's like I spoke to a 100 Yeah. Founders.

Well, first talk to a 100. Yeah. You you have talked to a 100. Yeah.

Well, I didn't

follow your Scaling Dental Experts.

I didn't follow your process though. But

Well, my process is designed to help you. You can escape from it whenever you need to. But if you don't know what to do, follow the process.

Well, actually, the something I realized, like, when I I I did start looking into writing that. And one of the things I realized is it's really hard because this because it's not structured, for me to actually gain those insights and, like, to narrow it down. It's like everything is kind of chaotic and

swirling. Yeah. That's why I like to teach people. You see, if you if you had this exact same five questions that you asked every single person, you'd now have a structure to do an analysis on.

Yeah. Yeah. So do that. Yeah. That's that's true. I actually wanted to go back to, the tab and just ask, like, 2 questions.

Ask me anything.

So the first one was, if there's multiple cofounders, should should they split this or should they do, like, one person takes the lead on this?

Yeah. You know, as long as it gets done, I I've seen success both ways. Okay. Okay. So both people can jump into this and, you know, with permit ask permission to record Yeah. When you do it. 99% of people say yes. Okay. Okay. After you make a recording, make a transcript and keep that inside the company.

Yeah. That makes sense. The second question is, which I think is gonna be I would imagine people at home that there are some people who will listen and they'll say, you know, this makes sense. This is a good thing, but we have customers, we have users, we're growing, we're busy, great idea, but we don't. It doesn't apply to us. Do you think that

we're not Yo. First, if for any start up, if you have users and you have customers and you're growing, congratulations.

Okay. Right?

You're not doing it wrong. Okay. Okay? The question is, can some of these techniques help you? Okay. Right? And that's for you to decide. Right? One of the risks that every company faces, startup or not, is you get captured by your customers.

Mhmm.

Right? And that's not necessarily a bad thing. Clayton Christensen is a Harvard Business School professor. He wrote about this in The Innovator's Delenta. Says because you have customers and you love your customers and you talk to your customers a lot and they are solving one set of problems.

So they should most for most founders, you would expect that whatever stage they're at, they're doing, they've got a technical advisory board.

Okay. So you don't have to call it a technical advisory board. Okay? But it's kind of the difference we just discussed about founder mode versus executive mode. Yeah. Right? Executives are cruising along, executing a business model, and every year they do it faster and cheaper.

Yeah.

Whereas founders are always looking for

Yeah.

The next business model. And the only way to look, they're not looking for it with microscopes or with telescopes. They're looking for it by talking to people. Yeah. And in our business, that means talking to developers, which is not something that comes easy to anyone.

That makes total sense. And I think that, in that talk that you're referencing, like, well, that's sort of that essay. He he references Brian Chesky a lot from Airbnb, and Airbnb is something that we would all I mean, I would be surprised if anyone listening has, like, a Yeah. A, like, a more valuable company that they're building than, like, Airbnb and if he's still doing founder mode.

I love the Airbnb stories. Alright. And for people that don't know how they got started, right, the founders spent an extraordinary amount of time working with their early customers, right, both their early renters and their early apartment providers. Okay. And Chesky himself talks about the example.

And then they would take the photos and then they would

people take crappy photos. Yeah. The first thing Airbnb did was they, yeah, they contract with photographers to make sure they had high quality photos of apartments and houses.

And he wouldn't have known that without

Unless he went and talked to people. Yeah.

So okay. So it might look different that you're kind of more like walk in the factory floor sort of situation of, like, I suppose actually no factory is actually

Well, okay. There's another There's another story about Steve Jobs. I mean, there are lots of Steve Jobs stories and some of them might actually be true. Right? One of which is that he used to get out of his uniform and then lurk in the Palo Alto Apple Store. Here he was, the CEO of a Fortune 500 company, and he'd forbid the staff from pointing him out or even looking at him. He'd just hang out in the corner and see how people interacted with all the stuff they had for sale.

Yeah.

Right. Imagine the CEO of a Fortune 500 company just spending a couple hours in a retail store

Yeah.

Just observing. It's that important. That's founder mode.

Yeah. So undercover boss kind of situation.

Yeah. Except it's not the employees

Yeah.

You're worried about. It's your customers and users. Remember, in in developer business, often the customer and the developer and the user comes to completely different people. And when I say different people, I mean they have different sets of problems. Yeah. And you need to have a value proposition for both the developer and for the person that signs the checks if they're not the same person.

Yeah. Yeah. This is this is amazing. So I'm gonna say my takeaways and just like there's a summary because I I really feel like this one is actually like people really should be like. For me I'm gonna be following this.

What is making it worse? Yeah. Yeah. What is the change in the environment?

Oh, yeah.

Yeah. Okay. So let me go in on a couple things. Right? One of which is when are you done? Right? After 6 months you're done with the TAB. And the answer is not every TAB member last 6 months. Okay. Some drop off because they don't want to participate anymore. Some, you drop off because you think you've learned everything you can from them. Okay? I think in an ideal situation, you're always recruiting new TAB members. Uh-huh. Okay?

Yeah. Well, it also reminded me one thing that you say is don't don't pay people for this. Right?

Oh, no. No. A tab member is not a paid role. Right? That's an that's an important point because there there are some people first of all, there are other approaches to startups that are not focused on developers.

I do.

Socks, a hat, coffee mug, t shirt?

We are we are a very frugal version. I have so many from other people there. Stickers. I've got a million people. Stickers.

Yes. Okay. This is what they're for. Yeah. Okay? It's not for showing off your own startup. It's so you can give it to TAB members so that they can brag to their peers that, oh, yeah. I'm on the technical advisory board of this startup. And later on, when they make it big, they can brag about how they got involved when you were still tiny. Okay. That's Appreciation not compensation. That's brilliant. That's really useful. I could go on.

No. This is so okay. But I think we've got so we've got that. We've got technical advisory board. We've I think there's a lot of stuff that People a lot of work to do. And then that can form the basis of the content that you put out

because Woah. Okay. So we're just getting started with the TAB. Right? So when you do these TAB interviews, right, then you need to analyze them. Right? And then Woah. Yeah. Turn what you've learned into a story. Okay?

What's an example of a story?

Okay. Let me tell you the structure of a story. And and when I say tell you, I'm just telling you something that you already know. Because at least in 9th grade English, this is covered in the US. Okay? Story has 3 parts, and some of you know this, and some of you have degrees in literature, and you're thinking he's just crazily simplifying it. That's true. I've tried to simplify this as absolutely much as possible. Okay? But all stories have 3 parts.

Villain villain is the problem.

The villain is the problem or or something that's causing the problem. Yeah. Alright. Something that you can you can personify out there. And villains, they have to be easily identifiable, universally loathed. Okay? And, you know, make them as colorful as you can. Disney knows villains. Right? One of the characteristic of Disney villains, they're colorful, they're intelligent, and they're proactive. Mhmm. Okay? Because if your story doesn't have a villain, it's not a story. It's boring.

What was the villain for, I think you've told me before, for Neo 4 j. It was like the

Oh, the villain was, connected well, the story was interesting. The villain was a graph data not a graph. The villain was a relational database. Right? Their relational databases, they're massive. They're everywhere. They're good for many things. Okay? But they don't help you when you have connected data. Right? In fact, they slow you down. They're they're hard to maintain. They are offer poor performance on your most important queries. Okay? And so you're not you're never gonna get rid of them.

Or it's a secret.

Piece of software. Yeah. Could be invisibility cloak or it could be a piece of software. And I'm guessing for most of the people watching this, it's gonna be a piece of software. Right?

Yeah.

The middle of a story. Okay? The hero on his way to, you know, defeat the villain meets an obstacle. Using the advice from the wise advisor and or the magic gift, the gift, right, is able to overcome this obstacle and move on. Repeat. Yeah. Okay. And that's why the middle of every adventure book or science fiction book is so long. Okay. It's all about the hero just getting to the next challenge.

Yeah.

Right? And then that's what their peers wanna know. Right? Once I solve this problem, then what will my life be like? Once I'm able to, you know, correctly, you know, produce all this video, right, how will my life be changed?

Yeah. And that becomes the content that you put out?

Well

Okay. So I think that's the part.

That that's the wisdom part. So that Yeah. The end of a story, what does the story end with? It ends with sharing wisdom. Right? So you can write it up as a case study.

Yeah.

Right? But whenever you do a case study, right, and this is something else that drives me nuts. Okay? So a user says, I love this company. It's great. Right? Yeah. That's a terrible quote that informs no one of anything. Okay? But when your quote is from a user that says, I was able to increase my video throughput 80 times.

I have

no idea that means anything. But but, oh, that that creates desire among that user's peers. It says I also wanna increase my video throughput by ADX. Okay? Now I'm incented to actually learn about this piece of software because I know what I can do at the end. Right? The great quote, no one's decided to do anything. Yeah. That's like it's probably your brother-in-law.

Yeah. Exactly. It's like whatever. Yeah.

Right? Do I by being able to increase my video through, but ADX, my company is a unicorn. Or I can go home and see my kids at 6 PM. Whatever whatever the object of the

real object of the desire is. And so that so when we talk about like you were saying to post everyday. Yeah. It's like this sort of the stories and the lessons that the gifts that people got from the advice.

The gifts, the challenges. I like challenges. Yeah. Challenges make great posts. So and so had a challenge. Here's how he overcame it. Interesting. You don't need to post the whole story every day. Yeah. You just need to post one little bit of it. Yeah. Right? This is a very old way of communicating. Right? Before the novel, right, every story was posted in installments. Right? There's only when publishing changed that we used to get that now we get these 200 page.

Oh, yeah. We get yeah. True. Yeah. That's a good point. That makes sense. Okay. So if if people are doing these things, that's they're gonna get pretty far with

You will get better if you have a story. At least have a reason for people to be interested in you. Yep. Okay? Yep. Now you gotta map out the the journey that all of your prospects are gonna make as they, you know, as they adopt your technology, and that's something that everyone does wrong. Let me tell you why they do it wrong. Right? This is the lead funnel. Right?

Can we get the, I guess, like the

Yeah. The the the okay. I'll just talk about the first one. Right? Which is technology discovery. How, you know, what do you start with? You're not gonna buy ads. Right? You're not gonna buy billboards. Right? How do you people learn about you? Well, it's just so happens. Right? They used to you're a developer. Everyone watching this is a developer.

it. And does this come back to the tab a little bit? The tech

supervisor Because as a researcher out what the tab is, you ask them. Yeah. You ask them. There's no other way to do it. Where do

you discover stuff?

Exactly. You describe that loop and says, what what do you do? Right? And, you know, what conferences? Because in every technology area, there are specific ways that this technology is advancing.

Yes. This is this is I actually I hear peep some people have marketers have said to me that they ask, like, the team, like, what, you know, the or like the target market, like, say iOS developer, like, what newsletters do you subscribe to or whatever. And it always struck me as, like, that's a that's a great idea actually to, like, ask people rather than to just Google, like, top iOS newsletters or something.

Would you believe it if you Google top iOS newsletter and then some vendor said, oh, yeah. I'm the number 1 iOS newsletter. I'm the number 1 iOS newsletter.

Yeah. Exactly. It's like usually one of them has made the list and, like, you know, so that struck me as, like, a good idea, but this seems like an even better idea to just do it, like, systematically. And you just, yeah, because I always, even like, you know, some I used to kind of run newsletter and I feel like with Skin Dev Tools and stuff I've kind of seen this sort of thing and it's like it would be so hard to know, like, even the value of, like, sponsoring a certain thing. And I feel like this would actually help you a lot because if you know that even if the circulation is not high, but key people that, like, it keeps coming up again and again and again.

Oh, let me tell you something that makes it even more complicated and important, okay, which is not everyone is an early adopter. Okay. So you think you've defined who your ideal user is and what the problem they have, right, but only a small percentage of them are early adopters. So you might find someone who is absolutely perfect for your product in every way, but when you talk to them, they say, yeah, I can't wait to use it. Call me back when you have 10 reference customers.

I heard someone say the other day that they ask, cost or, like, potential, I won't say leads, developers, like, when was the last time they worked to a startup, Like, bought something from a startup?

That's a great question. And what was the answer? I'm dying.

Well, no. I think it's just like he would just, like, use that as a filter. So if the answer is like

Never. Actually we

haven't, then probably they're not gonna suddenly start buying

from you. Correct.

Yeah. Okay. So we've got sorry. We've got dreams. So discovery. Discovery and then research. Research.

So someone discovers you in their technology loop. Yeah. Right? And then they say, oh, I'm gonna research this. I'm gonna and usually that takes place on your website. Okay? In other words, that I've made a decision. I'm gonna invest 30 seconds of my valuable time in understanding what you do. Yeah. Alright.

But they have, like, some memory of, like, if

I ever get

this exciting event,

then go, you know, look up this this

product again.

Yeah. Now evaluation also doesn't mean what you think it means. Right? Evaluation people want to believe that I make certain claims about product on my website Yeah. And people wanna evaluate it to see if it actually meets those plans. Yeah. Right? That would be so easy, but that's not what evaluation means. Okay? Evaluation from your actual software developers point of view is my shop is a unique snowflake.

Yeah.

Trying to get it to work. Because if they can get it to work, Monday morning stand up, you're gonna tell everyone, hey, I found a possible approach. Yeah. Right? If they can't get it to work by Sunday afternoon, they're not gonna say anything and the evaluation is over.

Yeah. That is very interesting.

Yeah. Are are you ready for an anonymous burner email doing self download over the weekend and not calling anyone to get your software up and fully functioning in an enterprise environment?

Yeah. No. That's so interesting and you would just see like, random Yeah.

I'm begging you, don't block gmail.coms because people from the largest companies don't wanna give out their email. They don't want sales people calling them. So they create burner emails just for downloading software.

Wow. Yeah. That makes sense. Yeah. Almost like the more legit they are, maybe the more likely to answer.

More likely they are to come up with a set of fake emails that they'll never use again. Yeah. Because they know people are just gonna after them. Right? They, you know, you can't reveal that you're a senior architect Goldman Sachs.

I was literally gonna say Goldman Sachs over the next

couple of years. Enterprise sales guy calling you in SAS.

Yeah. Yeah. That's that's amazing. Okay. So, discovery, research Evaluation.

Activation. Activation. So I've made the decision to bring in this technology. Right? How fast can we go from I've made the decision to do it to I'm actually getting value? Right? Yeah. Speed is the key. And the the book that is a must read on this is Kathy Sierra's Making Badass Users. Right?

Because It's not a

ever the first when you first bring technology in, right, you suck at it and you know you suck. Right? And the different the question is, how fast can you go from I suck at this to I'm actually a badass at this. I'm good

at this.

Yeah. Okay. Not how fast can you get it installed and working. How fast can you make the user feel like they are the master of this? Right? Speed is the key. Okay? And then the last part of the sequence is membership because developers, they hate to buy, but they love to join. Okay? This and I talk about community there there are people who study communities.

m. Dream.

That replaces the, funnel.

Okay. That's amazing. Okay. That that makes that that makes so much more sense than, yeah. The traditional funnel.

Yeah. This is not rocket science. This comes from observing people over long periods of time.

Yeah. It's, it's definitely it's not rocket science, I guess, but it's it's very difficult and I feel like I like the way that you framed it because for me the challenge is just knowing what things not to do and and how to have, like, a structure because, like, it's, like, just to sit down and be like, oh, mate. There's so many things I could be doing. Yeah.

That's that's actually that's the heart of it. That's the hardest part about being a founder. Okay. Is every day when you wake up, you make a single decision. How am I gonna spend the hours today? Yeah. That's it. Yeah. If you nail that, everything else will fall into place. Yeah. But that's really hard for people to do.

Yeah. I feel like that's that.

That's the hardest thing.

Yeah. And I You know I think you've done a very good job of of helping people to

have a framework

of how to spend that time. So, yeah. I've re I've already recommended this publicly but like, you know, it's a great book, it really is. So Great.

Well, I'm gonna do some shameless self promotion here. I've built a course around this book and it's a 12 week course. It's cohort course, so it's not self paced. You learn at my pace, not your pace because I will push you through. And you also learn from your peers as you do it. So if you're interested in a course, visit my LinkedIn. I think there's a link to the course from there. It's built on Mighty Networks, which is a great platform Amazing. Launching in October 2024. Yeah.

And you've already I I'm gonna get you on public record that you promised me that I can join it as well. Right?

Yes. I will send you the link. Yeah.

Okay. So hopefully see some of you on it. Yeah. Adam, oh, do you wanna just say, like, any, like, websites and stuff that you've got to go to? I guess Adam Frankel on LinkedIn.

My LinkedIn profile. Yeah. Everything starts in there. Cool. Right? I'm I'm not gonna set up a separate website trying to sell people things.

Okay. Amazing. Well thank you so much for your time and that was really really It's

a pleasure And actually, this was more fun than I thought.

I will take that as a compliment. Thank you. Thank you. Thanks, Adam, and thanks everyone for listening.