Your users are smart people. That's why they're willing to use your product. Right? You want to get to get their brains engaged in solving the problem along with you. That's the best way to multiply the brainpower at a startup.

I'm talking about the importance of getting the problem exactly right. I was at Rational Software in the mid nineties. We had a product called Rational Rose, and it implemented the UML, the Unified Modeling Language. We launched it with the value proposition that we enable you to do software architecture. And it was met with resistance from our target market, who were software architects.

He said, no. He says, I do architecture in my head, right, or I write code. And we really were thrown out of a lot of accounts. And then we had an epiphany. We realized that the actual problem that we were facing was we help you communicate software architecture.

And the exact same people who threw us out before called us up and said, we I wanna talk because I do the software architecture in my head. But then I've got a 100 developers who don't understand it. And it's the same product. It's they're doing the same things. In the first instance, we weren't effectively communicating the value proposition because we didn't understand the pain point the customers had.

And the pain point was communication. So I'm gonna ask the first question. This is Adam Frankel. I'm talking to Jack. Jack has said that he attempted a technical advisory board at his new startup.

And what I wanna know is, how did it start and how is it going?

Yeah. So I would say it's been overall, it's been great. It's been the thing that especially when I joined, I think, as an onboarding, just talking to, like, you can design like a better way to onboard, I think, of just like you start talking to people about the problems and just get such a good gauge of where people's priorities are at, I think is is probably the biggest thing. But we I have a lot it's a lot of challenges as well though. I think it's like one of those things where it's like, it's actually really hard to do do it well.

And this is kind of my second attempt at doing it because as you know, like I did your course before with my own startup. And it's it's like it's a lot of work and it's hard to do it well. And I have I have question and so actually, this whole episode I thought would be quite good to kind of since I've tried it, to kind of ask questions around like, here's where I feel like I found it hard or the extra questions that I had

for you. Awesome. I'd love to discuss this. This is such an important concept.

Yeah. Maybe if people are listening and they haven't heard of technical advisory boards by the way, firstly, they should just go back and listen to the first episode that we did. But maybe we could do a quick, like, summary of technical advisory boards.

Let let me do a a I'm not sure I can do a quick summary, but I will do a summary. Right? The the the core idea behind the technical advisory board is that if you're producing a product for developers, you need to talk to developers. That's the key concept. But for most founders, that's not so easy because many founders have this idea in their head that they can write code, publish it.

People will use it. They write more code. They publish more of it. People will use that, and that's how you grow usage and the whole company. But that doesn't really work.

And and where in that cycle are you talking to developers? It takes effort to reach out and talk to developers. And let's say you go to some meetups or some conferences and you just talk to developers too. Does that count? And, well, that's better than nothing, but it's honestly, it's not very good.

Right? And so after struggling with this question for years and multiple startups, I began putting the pieces together slowly over time and seeing what worked and seeing what didn't. And so I came up with the concept of the technical advisory board. Now the technical advisory board or TAB, that's just a name. Right?

And it it's a little bit of a misleading name because it's nontechnical. It doesn't give advice, and it's not a board. That's just the name of it. Okay? But what a TAB involves is you reach out to lots of developers.

When I say lots, I'm talking dozens. Although, I've known founders that have reached out to hundreds. I don't know anyone who's done thousands, but I have known people who have done hundreds. And you talk to them in a not in a single transactional sales type call, but in a relationship where you have repeated calls over time. You talk to them in a structured manner, which is it's an interview, it's not a conversation.

You capture the results of your conversations in a way that allows you to compare and contrast what different people are saying. Right? And allows you to gain insights that enables you to build your story and build your product in a way that's compelling to developers. Now, when I say developers, I want to expand your idea of of what you think developers are. Okay?

I mean, everyone who is involved in the decision to adopt your technology. And that's for developer facing products. That's typically developers. Right? But it could also include their managers.

It could also include different types of developers. It could include SREs, UX, back end, front end, full stack. It also includes the executives that approve the budget, whether it's a VPE, CTO, or CISO. Right? It also includes them.

Now what all of these people have in common, even the VPEs and CTOs, if they no longer write code every day, they're all former developers, and they're part of developer culture. And developer culture is really interesting, and it's different from business executive culture in interesting ways. It's not original to me. This is the idea I got from Thorsten Fevelin, this fantastic, brilliant Stanford professor who taught in the nineteen twenties. Right?

And was he talking about developers? No. He was talking about engineers, which in the nineteen twenties were having influence on The US economy in a way that they never had before. But today's developers are culturally engineers, and their culture is very distinct from other types of people. And you have to understand and embrace that culture if you want your products to be adopted by developers.

Does that count as a brief enough summary? Can we then dive into all the all the different parts of Yeah.

That that was great. Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like SSO, SCIM provisioning, role based access control. You could spend ages tearing your hair out, building these things yourself, or you could use WorkOS.

Will, what do you guys do?

My name is Will Stewart, co founder and CEO of Northlink. We're a self-service developer platform and we help teams deploy their most critical workloads into their VPC. And you guys use We use WorkOS for our SAML and OIDC integrations. It's a pretty exceptional product. It it makes everything regarding authentication pretty seamless, and it's been instrumental for us to onboard our enterprise customers much faster.

Yeah. It's a great product.

WorkOS helps your dev tools start selling to enterprises much faster. And they're trusted by dev tools like Cursor, Fowl, and Vercel. If you use their user management or you can get your first million monthly active users completely free. I have questions around finding people. It's just Yeah.

Hard and I think it's getting harder.

So hard.

I have questions on conducting the interviews and how to keep the momentum and keep it useful throughout, like, six. I found that very difficult. I mean, have lots of questions. Maybe I should just go straight in for the first one.

Ask me anything.

Right.

I'll I'll just be completely honest. Don't have limits.

So the questions that you mentioned a lot that I started to use was the first one is like, so we're in voice AI. So we would say like, you know, when you're building voice agents, if if there's anything that you could wave a magic wand out, whether you were to make it better, fix it, whatever, What would you waive it at? So that that question is brilliant. That question is guess so much of the value. And I feel feel like for us that was where almost all of the value lay was like kind of asking that question.

Then there was

Thank you. And then Hey, I wanna interrupt you. I wanna give credit to Andy Raskin, who is a brilliant marketing consultant. He's the one that actually taught me that question.

It's it's so good. And the next one is if you if you had this, how would it change your life? And actually, I feel kind of weird saying that because I was like, how would it change your life? Because I thought it was like being overdramatic, but everyone answers it actually. It's like which is quite funny.

That

was a shock when when I first started using it. And it's like, wow. I've stumbled into a gold mine.

Yeah. That that one is also great. And then there's a question that is the third one that you I think suggest that I took away was, is there anything that makes this more valuable now than it was in some time frame? And I kinda changed this so I didn't fix. That one I would say is like I think because in our space, it's just the answer is almost always the same for everyone where it's like, yeah, Gen AI is like, this is why it's different.

This is like and it's it's kind of like kind of, you know, it wasn't possible. So we kind of get tend to get the same answer. So essentially, those questions extremely useful. And I think the first call is is useful, very useful. And I kind of what I tended to do is just almost like ask the same question again and again, like kind of go in a loop almost.

I strongly encourage asking everyone the same question regardless of whether they're an individual contributor or a top executive.

Oh, yeah. But I actually meant I kind of asked the same so, like, I asked those three set those set of questions, and then I almost go and ask it again, and I try and say it, like, in a either I say, if there's a number two, what would you wave at? Or I say, like

Got it.

Within or I kind of zoom in and I say, okay. They might say, okay. I would wave it at, say observability of voice agents. And I'll be like, okay. Within observability, like, what would you waver, magic wand?

And I'll try and like zoom in. And I found that that was the approach that worked best for us in terms of the questions. So that I think the first one is is good. And usually cut where it finishes fairly within thirty minutes, usually less. And then the second call we do like, try to do like this summary or like here is how we rank things from what we're hearing.

And that also works really well. And usually, that's really hard because everyone has different ratings And I found it quite hard to summarize it well and there's a lot of a lot of analysis in there. And we tried to we did try to use like AI stuff and I wouldn't necessarily recommend that to people because I felt like you lose a lot of the benefit of doing it for us, I would say. And it it you can sometimes try to ask it like which come up more and it's it feels wrong, like, the the way they so far, it doesn't feel like it was very accurate. And maybe it's like the emotion in the voice and stuff that's lost in the transcripts and things like that.

And then I would say so then probably like one of my biggest questions is just like the third call, I think we started to get we almost like clarified it again, and I think I started to like lose a bit of steam. And also I wanted to, at that point, show them all the stuff that we've done to solve their problems. But we hadn't really made enough like, you know, because because a lot of the stuff they were saying was like quite different to what we our focus was on and we were really early. And it felt like, okay, we need before we do that, we've gotta kinda cover all the basics first. And so we it it was it's a very yeah.

I don't I mean, I don't know what my question is here except for maybe maybe we're thinking about it wrong, but we just found it very hard to like come back and say like to show much kind of progress and keep that momentum.

Yeah. Well, so in in my point of view, in the perfect framework, which which doesn't work perfectly for anyone, I don't want everyone. Right? The third call is about finding out how much of the problems you need to solve to create value. Right?

Sometimes the problems are so big that if you can solve it by 10%, that's absolutely amazing. If you could figure out a way to cut someone's AWS bills by 10%, that's amazing. That's fantastic. Right? And all you've done is 10%.

Sometimes, however, a 99% solution is worthless. It's gotta be a 100% when you're not adding value. So that's really what I want people to test in the third call. Right? Because the this you know, but the first call, you're you're in discovery.

Right? And there's a second call is all about prioritizing people's problems. Now now you found the problem that people have prioritized. Now you need to know how far do you need to go to solve it. Right?

And the way I like to talk about this is I talk about the results that my early users have achieved. It says if you could duplicate this result, would it be compelling to you? Why or why not? Alright. And the idea is that here's a fact.

This you know, a certain user got this result. If you had the same result in your shop, would that change how you work? Would that change your life? Would you get the value from it? Now if you don't have users who have results yet, possibly because you don't have a piece of software yet.

Alright? Then you can defer doing this or you can make something up. You can say, if we were able to achieve this result, right, would that be compelling? Instead of saying, instead of asserting that you have achieved it. And one of my rules is you can never lie.

Right? Developers will find you out. So don't claim you're achieving results if you're not actually achieving results.

Yep.

Right? However, if you can make any claim, you know, once in a lab test we were able to do this. You know, if you could do that in production, right, then that's a reasonable thing to ask someone.

Yeah. Yeah. That makes sense. So it's faster for them to build voice agents with

There you go. Okay. That's that's a real vibe, but people need voice agents. Right? The CEO has said Yeah.

We need a voice agent. Okay. Period. Yeah. And when the CEO says something, budget is attached to it automatically.

Okay? And billing voice agents are hard, and they take a long time. And anything you can do to reduce that amount of time is gonna be appreciated. So the question really is how much time does it take for that to be noticeable? Alright?

If you can if you can mop a month off the time it takes to the voice agent, that sounds pretty compelling. Right? What about a week? What about an hour? Is that enough to make it compelling?

This is what you need to find out. Because if if you disclaim you save time, but you shave an hour off a three month project, that's that's not really enough to do anything. If you shave a month off a two month project, that's I want that today.

On that premise, if we can help people build voice agents, even if my because my question is like, when you're building voice agents, what's your biggest problem? But

Ah, okay. So now you need to tighten the question. Yeah. Quality is the biggest problem, and it's gonna remain the biggest problem until it doesn't. Okay?

Yeah. But what is taking the most time in building voice agents? You're shifting the question. Yeah. Everyone wishes the quality was better, but Yeah.

You can't fix it, they can't fix it. You know, eventually OpenAI or Anthropic will fix it or not. Okay? But the real problem they have I mean, quality is a problem. Right?

But the problem right ahead of them right right now is my CEO wants us to ship this thing next week. Right? But with what I know and the tools we have, it's a three month project. I'm I'm making this up. I don't know.

Yeah. Yeah.

It's like, what can you do between to the shortened three months more towards the one week goal? That's a problem. Okay. So you gotta, you know, zoom in on that. Where where are they spending time that they shouldn't be?

Yep. Time is a big thing. And then I I'm having this interesting conversation with so many people right now because for a generation, everyone in developer tools assumed developer time was the constrained resource. Right? And now with the move to agentic coding, that may no longer be the case when you can have us an army of agents generate all the code you want.

First of all, life is not wonderful. Right? It's disastrous in so many ways. But simply hours of developer time, that that suddenly well, that's not the constraint in terms of, let's say, hours of developer coding time.

I

can generate all the code you want. Someone still needs to look at it. That's what people are learning.

Yeah. So it's more like the time.

It's it's time, but it's in a different dimension because Yeah. How developers spend their day after the adoption of AI tools is changing rapidly. Yep. And the idea is, I know what it'll be twelve months from now. No.

I don't. Okay. I know it'll be different from today, but it's so different today from what it was twelve months ago.

Yeah. Yeah. Yeah. Yeah. So that's that's actually really helpful.

So I should because I because it is I'm like, you know, we talk to so many people and it it's just it is so hard to build voice agents. Like, it's into production is really hard and

And no one doubts that's the future.

Yeah.

I mean, everything from the Star Trek computer to c three p o. Right? Everyone has imagined how people in the future will interact with computers and it's by a voice, of course. Here's the variable that I kinda gloss over in this book. Okay.

Right? Which is how you state the problem is the most important part of this question. Right? And there's no one right answer about you can make it broad. Right?

What can you change about programming? Right? Or can you very make it very specific? What would you change about this error message? Right?

Yeah. And if you make it so specific, it's valueless. If you make it too broad, it's valueless. And knowing where to state the problem, that's an art form. And you only get good at it by doing it and refining it.

Do you have any examples of like people that you've worked with who stated the problem well?

Okay. I'm gonna give you an example from old Sourcegraph. So Sourcegraph Yeah. Of course, right now, you know, their main product is AMP, which is absolutely amazing. You know, you can create an army of coding agents of all different types.

Okay? But when I was there, you know, our previous product was code search, but we didn't even know that. When I joined the company, right, the the slogan was the new standard developer platform, right, which meant nothing and no one. Right? And I and we did six different things.

And one of those things was we did code search, and we did cross platform code search. So if you had some of your code in GitLab and some of it on GitHub and some of it in some other platform, We could search across everything. And I said that's what get that's what gets us in. The problem that we're solving is the code search or the universal code search problem. Mhmm.

Right? That's it. And it turns out we had a number of great customers, right, that said that's exactly the problem that we have.

Yep.

Okay. I'm gonna tell you a story, and and and this is old by now. Like, one of Sourcegraph's first customers was Uber. Uber, amazing company. When they were first growing, right, the the goal of Uber was just grow as fast as possible.

Bring on new cities, new countries, any way you can. And so every country got its own dev team. They didn't wanna be slowed down by having to have one central r and d that had to coordinate. And and the dev team's got a command, which is go as fast as possible. And so it it led to the interesting thing, which is their first 20 airports were all individually coded because some development team got you know, like, said, you know, bring London Heathrow on as fast as you can.

You know? Bring Atlanta on as fast as you can. Right? And then they built up these these airports and got it to work. And then some executive at Uber says it's taking way too long to add our hundredth airport.

Right? Why don't we just have an airport library so that it's easy to add additional airports? But it wasn't easy to locate all of the code that had to do with airports. So that was, like, one of the first use cases Soriskra had. Just look across all of the code bases at Uber, which had been developed tremendously fast, cut every corner possible.

We just need to be in this market first. Right? And find every bit of airbag airport code so we can build an airport library so it's easy for us to add the two hundredth airport. So you can see there's an interesting mix of business and technology incentives that change over time. Right?

How you can start a code base from nothing and quickly grow it to the point where it's a jungle. And then you at some point, you need to take control of it again because the complexity of it is slowing you down. And the overall business driver is always speed.

So how did you frame that question?

Universal code search. So So here's the other art is boiling the question down to two or three words because that's all people remember.

Okay.

Search I've I've been using Google search for twenty years. I know what search is. Code search. Oh, it's like Google for code. Universal means GitLab, GitHub.

I still have stuff on Subversion. It's like, I wanna just find it all.

So you would say, if you could wave a magic wand at universal code search, what would you wave at?

Yeah. Yeah. Exactly. Well, think we start with code search and it was like, well, make it universal. It's the first thing.

Okay. Okay. That makes sense. Okay. This is great.

Here here's the other problem it solved for us, which is that GitLab and GitHub each had their own code search things. They were just a button in each interface. Right? And, originally, that was a problem for Sourcegraph because all the VCs went pointing this out and said, look. You're just a feature and not even a major feature in your competitor's platform.

Right? But the real problem was that everyone has everything. Right? And GitHub was never gonna search GitLab's repository and vice versa. Right?

That was the big problem. Many years ago, I was the CEO of a voice over IP company, and we did and our quality was terrible, honestly. But we did a bunch of testing. Right? And what we learned was microphone quality is 90% of the audio quality.

This is in 1998. Wow. Okay? And so there there was almost nothing we could do in software to improve the quality if people had crappy microphones. And in 1998, everyone had crappy microphones.

Right? The these brilliant sure things that we're both using, these MV seven pluses, right, this was better than the best professional microphone of 1999. So the microphone quality problem has been solved.

Yeah. You just got But

not the transcription voice

quality browser when people are in on their MacBook Pros in a shared co working space. It's Oh my god. Yeah. Yeah. It's hard to keep the enthusiasm from your tab members, I found, over time.

Yeah. Because they the the here's the the real there's an implicit promise with your tab members, which is you're not paying them. You're you're not gonna give them stock. Right? But they but you're asking for their time, which is their most important possession, their time.

And the implicit promise you're making them is that time that you spend with me will help me solve your most important problems. Right? And they have to believe that. And if they no longer believe that, they will not give you their time. Right?

So don't lie to them. Right? But simply say, look, understand this is your problem. Right? We're we're not gonna be able to get anything to you in in a short amount of time, so can I reconnect with you when we were able to talk about this in more detail?

Yeah. Be honest.

That's They're very generous people. Right? But they all sneakily suspect that vendors just wanna sell them stuff. So Yeah. Be honest with them.

Yeah. And we we did do that. Should we just cut it way down? Yeah. Like we did the first two and they were like, I felt yeah.

Great. And and I think in six months or whenever you're able to come back to them, you'll get a surprising number of people that say, hey, we wanna pick up this conversation. Yeah. We now have we've learned a lot and we've got more interesting things to talk to you. They'll come back.

Not all of them, but some of them are.

Yeah. Okay. So I also wanted to ask about recruitment. One of the ideas that we were playing around with was having because we tried doing like so all of our tab members got recruited for like some kind of a warm intro like event, stuff like that. We had zero success with cold emails.

I remember doing it even last year, I think, when I did your course, and our success rate was success rate then was higher. Feels like it's it's hard it's getting harder to cut through, but it feels like you can we we have had a lot of success with, like, kind of some not cold scenarios.

Yeah. I'm I'm hearing that from other people too. And my favorite platform is still LinkedIn. Right? But LinkedIn has changed a lot in the last twelve months.

And part of it is due to people trying my techniques. Part of it is due to AI generated messages. Okay? But it's a lot harder to break through the noise on LinkedIn. More people are just skipping LinkedIn messages.

Yeah. Not bothering to read any of them.

Yeah. So I guess, do you did your is that I I actually feel as I'm saying this. I'm looking for the easy way easy way. Is there an easier way? Shaking out.

Unfortunately.

There isn't. Let let let me tell you the the easiest way, the best way, right, is to be constantly publishing on social media. Right? Publishing on topics that you know are interesting to your target market. And when you get engagement, immediately reach out to the people that engage with you.

Right? Because at that point you have someone, they're interested in your topic because that's why they're following you. They've just indicated that they've gotten value from whatever you've just given them. Right? So you've got a short amount of time to reach out to them and say, hey, you know, would you mind having a fifteen minute call to discuss this?

Yeah. Yep. So I would double down on social media presence.

The content that you can create from the calls is very, very good, I would say. Like, putting it

on calls, the content, the social media, the engagement, the reach, this is all part of a cycle.

Yep. It's incredibly useful. Because my role is, like, dev experience. Like, you could say DevRel. It's those six people is, like, write some code, do lots of, like, product stuff, product testing support, kind of bit of everything.

And I've been leading the tab and doing all the interviews and stuff. And do you think that it should be spread out among people or do you think No.

Actually I don't. I think having one person is is actually beneficial because it means you get consistency. It also means you you just get better at interviewing. The only way to get better is to do it. Now having said that, I think that the recordings and the transcripts are super valuable.

And if you can, you know, have your whole team understand what's going on, I think that that's that's a way to transfer value to everyone.

Something we did actually that maybe other people might find useful is Damien, the CEO, made like a internal podcast behind like we use like Cloudflare's like all thing. So it's like it's just like a website that's like you can play. Like, we put all of the tab calls on there and then people can just go and like anyone. Because yeah. I felt like that's quite important part that we found was just like trying to get everyone to be on the same page with what we're hearing.

Because like sometimes you come away from a call and you're like, oh my god. We need to do this. Like and then it's hard to like just generate the same enthusiasm across everyone else when you've had that.

And if you can easily, you know, grab clips, people will watch clips whereas no one wants to watch a a thirty minute video. True. So used long video to create and then if you want people to consume it, I mean, this is the TikTok age. The sixty second video is what people are used to.

Yeah. True. Do you think it's okay for like me to do it or it should be the founders?

I think you can do it. And and it's a so I've got a couple opinions on this. One of which is I think this is a founder level responsibility, but sometimes the founders just aren't up to this. Right? In which case you need to bring someone on board to do it.

So I think you can do it. Right? And you should get recognized somehow for this this absolutely essential founder like contribution. I

I've gotta I've gotta rebuke you saying that they're not off to it. But I Okay. Thank you.

It's hard. I don't underestimate how hard it is. Right? And lots of people, you know, lots of technical founders just want to write code. Yeah.

And I think if you just wanna write code, but you understand how valuable it is to talk to developers and you hire someone to do that, that's better than ignoring the problem. Yeah. Right? It's probably a better recognition of your own limitations to say, I am not gonna be able to do this.

Yeah. I think for us it was mostly because this was like my the thing that I was like, as soon as I joined, we gotta do this. And so Yeah. I think it was like followed from that. And do you hang on.

I had a question. Wait. It's just it's just disappeared into the ephraim of things. Oh, man.

See, that's a crazy thing about having ideas and they go away. The the the key inspiration behind Google thirty years ago was that every word was innumerable. Right? And because of that, you could search the whole Internet. But the key idea behind the LMs right now is not that every word is innumerable, but every thought is innumerable.

That thought he just had, it's just a vector. And can you find it faster than, you know, a GPT can?

Probably not. Okay. Oh, yeah. Actually, no. This was what it was.

So I okay. This is the thing. I don't know if you're really gonna have any answers here but I'm gonna say anyway. So the hardest thing is honestly, if anyone's done like kind of DevRel y stuff or like whatever. I mean startups, you just do you're just doing so many things.

And my biggest struggle is like I just have time for stuff like it's like, that's the problem. It's like I'm trying to spin all these things. Trying to be like possibly good in so many areas that it's really easy, you know, when I came in like, do the tab. We're gonna get all these people. Plus we get the boost because we have oh yeah.

I've got these five people I can ask. In the beginning, everyone's got like five people they can ask and then you get that boost and stuff. And then it's it becomes like much harder like to kinda keep it keep the ball rolling. And which also gets me onto a question of like, the way I understood the tab at the beginning was very like, this is a project I'm gonna do. I'm gonna and I think it's how most people understand it.

It's like, I'm gonna do the tab. I'm gonna do the tab at six months. It's like, speak to 20 people over six months. But I know that you don't see it that way and it makes total sense. But I I guess

In my experience, the most successful startups are ones that talk to the most users and potential users early on. Mhmm. Your users are smart people. That that's why they're willing to use your product. Right?

You know, when you get to get their brains engaged in solving the problem along with you, then that's the best way to multiply the brainpower at a startup. And I don't underestimate you're absolutely right. The most constrained resource you have in a startup is hours. And how you spend those hours is the most important decision you will make, and you make this every day.

Yeah. And then the other thing is like we started to get when we've when I first joined, we didn't have like anyone using us. And now we have people using us. We have like some customers and we get, you know, there's just from like the support stuff there and things that don't work or things they want, things they need, things they absolutely need for launch. It's like we get this starts to become like the biggest like, my time is not like, you know, I'm not like sat around like shooting shit thinking of like, oh, no.

Cool marketing ideas. I'm like, they are it's like they're like it's like our guy someone's paying us and they want this SDK. They want this extra stuff in the SDK and they want this extra feature and they and this this thing is broken for them in Chrome. Like, it's just like See try to fix that. This is like

That information is so valuable. Quite frank frank frankly, the feedback you get from early users is your most important IP. It's more important than your code. Right? So you need to you need to, as you're doing right now, spend time capturing it, documenting it, and explaining it.

Because all your early code, you're gonna throw away and rewrite. But the insights you learn from your first users will put you on the right vector.

It's not the Koji right. It's the insight she gained along the way.

Yeah. Yeah. Essentially. Yeah. Great tagline.

But how do you how do these things sit side by side? Have you got like a mental model around like the stuff you get from people just struggling with products or like things they want or like versus like the tab and stuff like, how how do you, like, struck do they sit in the same place? Is it like

So and this is kind of a Weasley answer, but the answer is it depends. But but the overriding principle is that communication is the most important thing. Right? If you're talking to users every day, either as part of a tab or as part of early user feedback or just as part of technical support. Okay?

Then you're doing the right thing. If you find yourself coding all day and not talking to users, then you are probably not doing the right thing.

Yeah. I've been trying to only work on which is hard. And I stop myself. But like, I'm trying to only work on stuff that's like or work on the things which are closest to like actually solving something that people ask for rather than what I'm trying because I find myself like anticipating like, well, people will probably want this, which I like No.

It. Validate it. Yeah. Your users are smart and they are dying to tell you what they want.

Yeah. Yeah. Definitely. Definitely. No.

I I I feel like that's wrong. What what I when I when I anticipate, I just I try to just put it out of my mind.

Well, I know and there's a there's a role for that. Right? When you when you say anticipate, right, I'm thinking you are constructing hypotheses, and that's valuable. Okay. Okay?

But a hypothesis by itself is nothing. Hypothesis only means something if you actually carry out an experiment and and you validate it or you unvalidate it.

Okay. And so just ask them in Slack, is this useful? Or

Yeah. Okay. So actually, I I actually led a session. I was at BasilCon last week. For people who don't know what Basil is, it's a system open sourced by Google for doing large builds.

And when I say large, I'm talking like Databricks and Snowflake. Right? And other companies too. Right? And so I led a session there, which was it was entitled AI Breaks Everything.

And what I did was I came up with eight ways that AI breaks everything. And I sort of list them one by one, and I put them out there. And I said, this is what I'm hearing. Here's a statement. How many people in the audience agree with this or disagree?

And then I had a discussion on them. And what I learned was two of the statements out there, everyone said, yeah. Absolutely. This is important. Two of them said, no.

We're not saying that at all. Right? And the other four sparked an interesting conversation. Okay? This is a way of involving people to move the conversation forward.

Right? So your hypotheses are great. There there is the goal of hypothesis that is to get people to talk about it, not to pretend that hypothesis is true. Because I have been involved in too many startups in which we had some founder hypothesis that we just accepted as truth with no validation. Okay?

And the problem with these things is that, oh, the truth finally catches up with you, it is so expensive and painful.

Yeah. It's it's been actually crazy how you know, you're like the saying users are smart. And it is actually I kinda knew this, but I was still like completely shocked. Like how how smart. So like people would almost like, they will lead you to the water.

Like, are they

They want you to solve their problems. They really do.

And even just on, the micro level, like, they'll almost, like, solve they'll come up with, like, fixes almost and just

Yeah. It's great. That's that's why I love being a developer and and understanding developer culture. Yeah. Developers are hardwired to help each other.

Yeah. It's an amazing community.

Yeah. This was a very selfish episode, but I hope that it's actually useful for other people.

I do too. And and quite frankly, I think that many people are struggling with the same issues that you are. They don't even know how to formulate the question, so I'm very glad you asked me about this.

That's good. Do you have any things that you're seeing at the moment that you kind of like, you kind of wanna get on the on the soapbox and and tell founders like, you got you gotta do this.

So many things. You know, I actually gave a presentation last week and the the here's the key thing that all founders have trouble with, which is telling a story instead of just preventing a laundry list of their features. And I've I've repeated you know my story of this, I think I've got a chapter on it in the book, we talked about it. Right? If you wanna get people's interests, you need to tell a story.

Right? Don't hand them a grocery list. I I can talk about this for hours and hours, but but think about it.

Yeah. It's really like a lot to not not the book, but so much to actually do.

Yeah. Yeah. Who who knew becoming a billionaire was this hard?

What are you working on at the moment? Have you have you got anything that people should check out?

No. If you haven't bought the book yet, go buy the book. I'm begging you. Available on Amazon. Here.

Can I

Yeah?

Right up here. The developer facing startup. So what I'm working on right now is I'm working on leveraging AI to speed up this process. As you mentioned, you know, it's not I know when I first started, said, oh, this is sland dunk. Can I just throw stuff in here or ask them some questions?

Oh, it turns out to be a little trickier than that. I'm also doing research on how to what's the best way to get technical information into the AIs. And I'm talking to a lot of people and trying stuff out. And I've I came to an interesting conclusion, and I'm still trying to validate this. Okay?

But it seems to me if you want ChatGPT and the other AIs to repeat your messages, which is becoming increasingly important.

Mhmm.

The AIs love long form video. Yeah. That was an interesting result. In other words, that humans love short form video because it fits our process. You know, we're standing in and if we're at our desk, we're working.

But if you're standing in line at Starbucks, you're you're watching what's on your phone. Yeah. And that's where short form video really shines. Okay? But it seems to me that long form video, especially podcasts, are great for getting ideas, yeah, into the GPTs.

Right? And because GPTs need a lot of words. Right, and they also love the conversational format. They really understand the conversational format, so that's even better than lectures. Wow.

The same Because because of the growth of the podcast format that the the GPTs have been trained, right, to absorb this kind of thing.

So go on more podcasts, founders potentially.

Or Create podcasts. Go on podcasts. I'm a you know, I've become a huge fan of podcasts. And you do like hour long podcasts. Right?

That's just you. I'm That's

just you.

Lex Free oh, it's just with that's

just when you're

on Can't shut up.

You're still no. Not at all. But you'll you'll do special one because it Like comes with asking you

Lex Friedman, three hour long podcast. Right? Joe Rogan, I I don't even know how long his arc, but it's like AIs eat this stuff up even if humans don't.

Yeah. That's a that's a that's a very interesting nugget.

Yeah. I think here's the other transition that people are still worried about website design in 2025, right, and search engine optimization. Right? Go to ChatGPT or whatever your favorite AI is, right, and just ask it about your company and your products. I suspect that if we haven't hit the transition point, we're about to, where more devs will get their information that way instead of going to your website and struggling through all those badly designed pages.

Yeah. Because you're right. Interesting. So that's where your head is at. It's all about Yeah.

The new way. Yeah. I mean, I guess it killed not killed, but Stack Overflow, just the traffic just sank completely sank.

Yeah. Oh my god. In fact, my last call was with a former executive at Stack Overflow.

Really?

We're talking about that. Yeah.

Okay.

Sometimes, you know, the the technology wave just sweeps the rig out from underneath you on the assumptions you made. Right? They they were right at the time, but they're just wrong. And and the only way to know they're wrong before it hits your business model is constantly be talking with your users.

I think that's a good point to close out with.

It is. It's the most important thing.

Yeah. Yeah. So thank you, Adam. And thanks for coming on again. I'm sure I'm gonna get you back again.

But thank you for coming Anytime. As a return person. And people buy the book. If you haven't already, buy it. Buy a couple.

Buy buy a copy for work.

Yeah. Yeah. Even if you've read it

The toilet.

You know, if your monitor isn't at exactly the right height, I find it's a very useful book for stacking to improve your ergonomics. So the book can help you in multiple ways.

Yeah. Give it to all your team members as well. I've bought at least three or four at this point, I think. So Brilliant. Well, thank you so much, Adam.

Thanks

everyone for listening.