The Ultimate Guide to Developer Marketing | Lee Robinson (Vercel)

There's an iteration cycle you can follow that in my opinion is almost guaranteed to help you build a great product for developers. And it's not rocket science, it's actually very simple, which is talk to them, build relationships with developers, get out there and hear what's working well, what's not working well. Really listen to their feedback, ask five whys, go five layers deep of asking questions to hear about what's working and what's not working well. Then critically go back and fix the things that they're frustrated with as fast as possible and iterate on the product experience and tell them while you have, you can have a great strategy about how to build the next billion dollar developer product. The battle is won in the trenches of every single day, iterating and iterating on how you make the experience better. It could be two paragraph change in your docs because you talked to a customer and they didn't understand this one bit about how it worked. It could be one small UX issue with one of the inputs and where the button was placed that tripped up one developer. Because for every one person you talk to, every one customer, every 10 customers, you're gonna get to a point where there's a hundred more who don't say anything.

All right, Lee, welcome. It's great to have you here.

Thank you for having me.

Yeah, so you've written a lot of really amazing articles about great developer experience, great developer marketing. So why don't we just start with this? Like let's kind of put ourselves in the mindset of our developer, right? Like how do developers decide whether to use a new product or API or not?

Yeah, the developer buyer, the developer user, the consumer of a developer product is just a little bit different than maybe other products that you're building for. There's a lot of things that hold true and that are the same across all different users. But developers in particular love to have tools that can start with a free tier. I've talked to so many developers and having a free tier is the thing that resonates across almost all of them. And there's pretty good reasons for it. I think first and foremost, developers are skeptical of a lot of tools and a lot of products and they want to try it out and get a firsthand experience of it before they decide to adopt it. And for a lot of developers too, in, you know, non US based countries, if a product is $20 USD, $40 USD, $100 USD, like that can be a pretty steep starting point for them to actually adopt the product. As well too. So they want to try it first. I think that's huge. Secondly, once they try it out, where's the first place they're going to go? And that's jumping directly into the documentation. So contrary to a lot of other maybe consumers where you focus more on the marketing pages or other parts of the kind of logged out experience for developers, they like to just go to the manual. Like they're trying to get the job done as fast as possible and they want to go look at how they actually build with the tools, whether that's the API reference docs or the technical details of what make up how you build the, you know, build with the product. Ultimately what you're trying to do is build trust with the developer that they're able to use your product, satisfy their need and you know, hopefully make a good impression before they decide to adopt it more broadly.

Got it? Yeah, like, you know, I'm a product manager. I always joke that like, if I want to work with like another team, it's better to just like talk to the developers directly than talk to the pm. Because the PM will be like, oh, you know, let me put on my backlog. Like, you know, what's. The developers will just like give you a straight answer. Right.

So yeah, there's, that's one thing. They will always give you a straight answer. 100%.

Yeah, exactly. They're like very straightforward. So like what are some of the core components of a great developer experience? You mentioned a docs, like what are some other components?

Yeah, I think developer experience for me has been something that a lot of people misunderstand. I think that for folks who haven't been in the space for as long, they think that maybe it's something that I can kind of sprinkle on and improve. But in reality, the first thing and the most important thing that makes a great developer experience is the actual product of the tool. Has to be incredible. When you're building a tool for developers, the developer experience of the product is kind of the whole product. You want to think about all of the edges. So you can't forego a crappy product basically. Right. You have to have a good product. But I think the other two that are really important. We talked a little bit about documentation, we can go more in depth on that. But then also less discussed, I think is the actual design of the APIs and the, the design of how you structure your APIs kind of also goes back to the product experience because the API is most, you know, in a lot of cases the one of the most important parts of the product. Got it.

So I'm like, I'm not a developer. I have tried building simple apps and as a novice one of the things that I get really annoyed by is like, you know, before I can even like run something or like even write some code, like I need to install a bunch of libraries and frameworks and like do a bunch of research. I'm not sure if this is just like for novices or do you think developers share this problem and is that important to make great.

Yeah, it's interesting. There's been quite a few tools in the space trying to make the zero to one experience of getting started, building with frameworks, libraries, like most of the modern web tools, whether that is the ability to spin up something in the browser kind of entirely self contained and you can run all the code there, you can kind of have your local machine in the cloud basically. I think what I've been seeing more and more is that the hardware of computers is getting really good and really fast and for a lot of folks it's just makes a lot more sense for them to run things back on their device. It doesn't get away from the problem though of configuring the local tool chain, which I think is like the real problem that you run into. I mean this is why Docker existed for a subset of developers. On the like more DevOps infra side, I think on the like front end JavaScript TypeScript web development side, more and more tools are starting to focus on the end to end experience of building a great product. So historically I think in the JavaScript TypeScript ecosystem there were many different tools that you could kind of stitch together and build your website with or your web application with. And the rise of all these tools was really beneficial because you gotta pick and choose the best pieces. And I don't think that we should get rid of that by any means. I think that exploration and that ecosystem is fantastic. But what we've seen, let's call it the past decade plus is more tools start to emerge in their own verticals where they have an opinion about the whole vertical. Like they have this vertical integration of every piece so that you're not having to go configure your own underlying low level tools. I don't have to put together my bundler and my compiler and my CSS framework and like all these other pieces, it kind of just comes in one pre built solution where all the tools are included. And when you look across like game development or mobile development, this is kind of how it works. Right. Like they've been doing this for a really long time. Yeah.

Okay, so. So kind of the web is just catching up to game and mobile development in some ways, right?

Yeah, it's interesting. Like I think that there's pros and cons. Like what does mobile development do really well, I think the like for example, the Apple ecosystem, it's great that I can download Xcode and there's tons of tutorials and resources and it's very vertically integrated. It's obvious how to do things the Apple way. It doesn't come without trade offs though. Probably the biggest one and my biggest gripe with mobile, which is honestly why I started becoming a web developer, was the walled gardens of the app stores which you know, maybe is changing now, we'll see. But has always been problematic for me because the first time I used the web was really when I fell in love with the idea of being able to create things and put it online and distribute it with anyone in the world. And when there's barriers between you and getting your product or your code online, it just makes things really difficult.

Yeah, I'm not going on a tangent here because we talked like, I think one of the things you talked about is like open source. Right. So let's go on tangent here and talk a little bit about AI. There's a lot of debate about, you know, closed source models, open source models. As a developer, like which one do you like to use more or like what do you trust more? Or how do you think this thing will evolve going forward?

You know what the hardest part of this question is for me is I and why I get so conflicted on it is I have to assume or at least my assumption and I'll operate on the belief that the folks running OpenAI are smart and empathetic and generally good intentioned people. I think that's my view of the team there. So when I look at their decision to not release GPT out in the open. Right. Versus maybe other companies who are releasing open source models and maybe the argument is like, well we're trying to, we have something very powerful and we're trying to limit the broader exposure to it. I have to assume that like the only scenario I can make up in my head is that they really are cooking on something incredibly powerful and they're really trying to slowly bring the rest of the world along for that journey. Where I, I contradict myself though is you see something like a llama 3 or you see something like these other very powerful Open source models that are built in the opposite way and they're also very good. So I haven't really found. And maybe somebody else who's, you know, more of an expert in the space has a really compelling argument for why closed source. But I'm pro the open source model personally and I think we've seen this win out time and time again in the web ecosystem in general. Granted, AI is like a whole new frontier, but. And definitely partial open source.

Got it. Yeah. I don't know if they've changed their APIs. OpenAI changed their APIs a lot because I know as developers, like, it's really annoying to do, to like have something working and then all of a sudden something breaks or like do some sort of forced migration. Like, like this morning I was using ChatGPT and like it just felt like super slow and I hit the limit a lot faster. So. So even as a user, not a developer, like, it kind of, it's kind of annoying to have the experience like degrade on you randomly.

Yeah, 100%.

Okay, so let's go back to the different pieces of greater experience. So let's talk about developer documentation. I think a mistake that I see often is like, you know, like a bunch of marketing people or like PMs come up with like this very corporate sounding blog post.

Yeah.

About what's going on. So. So like talk about like what makes really good developer documentation.

Yeah, I think that like first and foremost, even before documentation is just what makes good writing. And so much of especially the technology industry has been plagued with jargon and you know, there's a time and place for specific words. But more often than not, if people write how they talk, company communication would be so much more clear. I want to read something that sounds like it's coming from a human, not something that says, you know, we delved into blah, blah, blah, which it's like, okay, well this is probably GPT generated. Right. There's just a lot of fluff in general writing across the Internet really. But especially for documentation and blog posts and written content for developers, that really cuts all of that cruft and just gets down to the bare essentials of what's necessary to get your job done. It makes a huge difference. And you can really, you can feel the difference when you read docs that are written in this way versus docs that have, you know, five paragraphs of hedging of like kind of convoluted sentences that maybe say this thing, same thing over and over. There's, you know, it's kind of hard to visually parse. Maybe you don't realize it right away, but you feel it internally when you're actually consuming the information. One of the biggest things that I've learned in the documentation space is a lot of teams focus on the content and the writing and that's absolutely important. But I think a lot of people could also focus on visually how it looks. And I'm not talking about images or diagrams in the page, but those are definitely helpful. More of the flow of the content. I really often see developer docs that's like five sentence paragraph, then eight sentence paragraph, then six sentence paragraph, then new section and it just looks like, like if you squint your eyes and it's like kind of blurry and you look at it, it's like I, I don't know what I'm looking at here. What really makes a huge difference is having some sort of, you know, visual differentiation between parts of your page. You don't need to overdo it, but you know, having some short sentences, then some long sentences, then some bullets, maybe you know, sparingly use some bold and some italicized text, you know, use headings, put code blocks on the page. I also see this too where like non developers trying to write content for developers forget that most developers just go directly to the code blocks. Like I, my eyes have been trained when I go to a docs page and my goal is to unblock myself and get a problem done. I am absolutely skimming the page just trying to find a code block that I can copy paste that like pattern matches the words I'm looking for. And if more docs were written that way, I think it would be a lot easier. Now I will caveat all of this which the past, you know, 10 plus years I've been thinking about this. It's all going to change with AI and it's interesting because a lot of this stuff might not matter as much if you build an AI native user experience for consuming developer content. So if we step back like fundamentally to the jobs to be done of what you're trying to get out of developer documentation or content, I'm either going there, this is really high level. I'm either going there because I want to learn something or because I have a problem and I want to solve the problem. So I'm looking for a reference for something like I'm trying to read the manual and I kind of know what I'm looking for or I'm trying to just learn how this system works more of a guided Content, there's sub levels to that you can dig into further. But to me those are really the two big buckets for the reference. More and more sites and more and more developer tools are starting to do code or documentation defined by code. So whether that's through type doc or the comments in your code, like scaffolding your documentation based on the source code. And you know, I've been very conflicted on this over the years because I often see that end up in producing lower quality documentation where it's like low level effort comments in the code. But when done right, it can be incredibly powerful because you get a couple things. One, you can auto generate the entire API reference of your docs. This is not new for APIs or backends like the open API spec that you can generate like your swagger docs for. Right? But it's less common on the front end side. So you can auto generate all your docs. It requires your documentation writers, your developers to be in the code. Which is why a lot of teams don't do this. Right, because the docs writers is another team. They're not engineers, they're not going to get in the code and make PRs. But if they're in the code and they're editing the documentation in the code, that also means that my docs are now in my editor. And when I hover over something in my editor, it can show me the docs. I don't actually have to go out to the website, I can click into the function and, and I have all this context and examples. And as more and more AI tools are trained on your code base, which maybe that includes node modules as well too, all of that context is in the node modules in the source code for your tools. So that's like one big category I think is really interesting. And even with powerful large language models, you still need guaranteed 100% to be accurate. Never hallucinated reference like that will always exist. That will never go away. On the other hand, what I've been thinking a lot about recently is a lot of docs might be better serviced through. What we have today is a search like experience where like chat GPT esque, I go to a search bar, I type in what I'm looking for. It can be any problem I have or any anything that I want to learn. I can ask a question, I can get back a response and you can imagine a future of developer documentation that has a similar model where it's trained on your content that you've written about, how to use the tools. But maybe there's a world where it's not just a text based chat input, right? What if that chat input can also display components or interactive widgets or other ways to help you progress through learning the content? So if it's more of a guided course, maybe the way you're interacting with this model feels more like flipping through a book and you're getting these interactive quizzes that come up and answer questions. And if you get it wrong, it's not this like static answer that somebody hard coded and forgot to update six months ago. It's like, no, no, tell me more. Like, I don't understand why did I get this wrong? I feel like I'm misunderstanding something about how the async keyword works in JavaScript. Can you tell me more about that? And now you have this like, like guided tutor working you through as you're learning the technology. And basically nobody is doing this today. At least I haven't seen it. But I'm very excited about the next couple years. As the cost of models gets cheaper, the power of models gets cheaper. You can imagine, you know, sites that get millions of views for their documentation being built in this way.

So just let's make this just to recap this, like, how does a developer explore documentation today? Like do they start with like maybe some quick start examples and then they look at the API reference and like how would this change with the AI first world? Like they just stay in their development environment and it just helps them.

If I'm evaluating a tool and I've never used it before, there's kind of two paths for me. Either I want to start building right away, so I would recommend all developer docs have a quick start which is like, it kind of goes back to get started for free for great developer products, like just cut the cruft. I just want to get going right now. How do I get the product working as fast as possible? So I think that will always remain and that works today and it will continue to work in the future. The second thing that people do today is I'm going to a tool. I've heard it's good. I'm not exactly sure if it solves my problem or not, but I'd like to find out. So I would like to go through something, it's a bit more of a guided resource to help me understand how this thing works. The con of most AI tools today is that they don't have any guided sense to it like you're prompting it. You have to know what questions to ask. And one of the things that's great about docs today is that people build information architecture or curriculums that guide you through the course, that guide you through the resources. You know, this is nothing new. This is how everyone teaches content to anyone, any student of any kind, through the, you know, whether it's a course or in a. In the school room. And then I think the last category of how people use documentation today is the API reference. It's like, I hit an error, I had a problem. I'm trying to use an API. I know it takes these like, three parameters. I'm not sure if the third one is a string or an integer and what the order is. So I just want to go look it up and that those are like the three main categories, in my opinion of today.

Yeah. And maybe there's like a couple of thoughts. So, like, for example, at Roblox, like, we have this like, AI tool to help people write scripts, like if you want to make a monster follow a player or something. Right. And I think what we learned is that the more context you have on the rest of the code in the person's game, the better of a script you can write. Right. And also, like, you know, because a lot of people actually learn, like a lot of kids learn how to code through rootblocks. So, like, there's kind of like a middle ground between just like having the AI generate all the code for you and looking up all the docs yourself. And there's a middle ground between, like, you know, it makes it easier, but you actually still learn something. Like just copy and pasting stuff.

Yeah, yeah, yeah. And there, this is something that I don't think has been explored well yet, but I'm very excited to see which is, you know, developer educational materials that are a guided curriculum or a guided course today that are completely static, hard coded. Here's the curriculum. Go from this to this. And along the way, you're trying things out, you're writing code, seeing if it works. You're comparing the expected result versus what you wrote. So you're learning and failing and learning along the way as you build your knowledge. I'm interested to see a version of that's generated from the source. And I don't know how good it will be. I'm curious actually, to see how good that could be. So if you imagine next js, for example, what if there's a world where you can have a AI model that's trained on all of the next JS source code? It's also trained on all of the documentation we've written so far. And it's aware of like the general community content as well too. So you can imagine there might be a world where that can generate, given the right setup, a guided resource to walk through, learning some of the concepts, that includes interactive bits and questions and answers and places for you to write code and compare the expected result and run it versus, you know, what you wrote in. I think it is possible. I just don't think it's been done yet.

Yeah, that's really exciting. Yeah. Cause otherwise you just looking up stack overflow or something, trying to figure out what's going on. Right. So yeah.

Yep, yep, yep. I mean, the invariant here is that even in this world you still have to have content that explains why that is technically accurate, detailed and included somewhere. Like the, there's, there's no foregoing, clear, concise, articulate, technical writing. Because that is now arguably more important because it is the training data to the future AI.

Yes. So let's say you have like really amazing docs now and now you want to get the word out right that like your API or your product exists. Let's talk about developer marketing now. So like, what is kind of like the goal, the high level goal of doing developer marketing and how's it kind of different from regular marketing?

Yeah, I think since developers want to try things out and hack around and build something. To me, developer marketing is about showing the art of what is possible. Like open my mind to what I can actually build with these tools. And I've certainly seen this through my time at Grisel. I've seen it with other companies that are in the space. What seems to really work and to really capture the minds of developers is to show them what they can build and then teach them how to do the same thing. Because when I see a great product, when I go to OpenAI.com and I view source and I try to figure out how did they make this element or how did they do this transition or this CSS property. I want to know how they built it and I want to recreate it myself. A lot of beginners learn from trying to make clones of popular websites, which I think is really fun because there's a very clear end goal. Like I want to rebuild Netflix. Like, I know exactly what it looks like. It's gotta have a login state. I've gotta save my movies to the database. I should show different movies based on the region that the visitor's in. Like, you start ticking down the requirements for the product and pretty soon you've built something that's pretty compelling and pretty interesting. So kind of going back to the original question, for me, it's getting a developer excited about the possibility of what they could build, showing cool demos, and then giving them the resources to actually go and do that thing. Because that's how you're going to build trust with the community. That's how you're going to build trust with your potential customers to want to come back and continue consuming content. Because most developers don't adopt a tool the first time they hear about it. They certainly don't buy it the first time they hear about it. It's probably like the 10th time. Like, I, I usually hear about things and I'm like, you know, I heard really good things about this product. I haven't tried it out yet, but I'd love to hack around with it one time. And then I keep hearing about it, I keep hearing about it and I'm like, I really need to just try this thing out. Like, people keep talking about it.

Got it. So developers are, most developers are kind of late adopters, kind of skeptics, right?

Oh, 100%. The more experienced a developer is, the more skeptical they are. And there's good reasons for that, actually. Like, I understand it as well too, because as developers, your decision making can be very influential to the business. And you often, if you stay around at a company more than a few years, have to live with the decisions of the architecture that you've chosen or the products that you've chosen. So developers who have worked at companies for a really long time or who have a long experience of building products, they've lived long enough to face the consequences of their earlier choices, and now they're a little bit more skeptical about how they evaluate tools, how they evaluate vendors, what they put their trust in. All it takes is one vendor that you bet on that you were super excited by. And then they actually, you know, close source their product, they jacked up their prices, they, they made a product decision that, you know, really affected trust in the community. And it, it kind of makes you just a little bit jaded, like, just a little bit. So a lot of developers have a chip on their shoulder, I think, from that as well too.

So you talked about how you have like a cool demo or a video, and then, you know, you actually need to make it possible for developer to do the thing that you're demoing, right? So like, so, you know, we've seen examples where the demo was like, really amazing, but the actual, the actual Thing is not there. Like, I think the most recent one was like, Devin, like the AI engineer thing.

Yeah.

Which apparently there's a thread about how it was faked. So I guess it comes down to really just like building a really good trust. Right. So how do you build trust and how do you kind of avoid like, losing trust with developers?

To extract from the Devin controversy, that I think is also like the OpenAI SORA controversy, which is also the rabbit controversy, which is also the humane pin. Like, it's kind of all the same thing, which is, how much do you hype up a product that is based on a new technology? Because obviously you're excited by it. You think that this is going to have a profound impact on the world, on developers. You think it's going to be transformative. And I think in the case of, especially the newer AI tools, there's been a few instances where things needed to be doctored a little bit. They needed, like, the message needed to be polished. So in the SORA example, I think, you know, there was a footnote that was like, you know, by the way, there was like a little bit of video editing on this thing and it's like, okay, well, that probably would have been good to know. Right. And I think on the Devon controversy, I think it was like, I'm sure, you know, a good majority of that is still legit, but I think what that person was saying was like, I don't think that you can actually just like press a button and then it's magically done. Like, I don't think it's that perfect. And I think, you know, same thing with AI devices, just more in general. The theme here, especially with developers or like early tech enthusiast adopters more broadly, is you. There's a fine line to walk between hyping something up and what the actual product experience lives up to. Like, a lot of people say, like, you know, under promise, over deliver, and I think it's even more critical for developer products. And I say that as somebody who has failed at that before. I have definitely been very excited about something that I was working on that Purcell was working on that I personally thought was incredible. And it probably came off like, Lee is hyping this thing up. He's super excited about it. This thing is going to be incredible. And there's been cases where, you know, we missed the mark. The product wasn't actually as good or the first experience wasn't as good as what it sounded like. And, you know, now after making a few of those mistakes, I really have A new appreciation for being very humble about the state of the product, especially if it's new. And secondly, like really only comparing against yourself. I think this was also a mistake that I've made in the past. Like, you have to be very confident if you're going to be comparing your product with other products. And especially for evolving your product over time, it's much better to talk about how you've been improving yourself, your own product over time versus others. Like since the last version, we've made this better and that better. And that's what we're focused on, is listening to customer feedback, iterating, making it better and then improving the customer ultimately will decide what tool they pick, whether it's your tool or a competitor's tool. And you want to stay focused on just making your product better. So that, that's another thing that I feel like I've learned over time as well too.

Got it. And is there also like a learning around but like when you're working on a new feature, do you involve certain customers or developers early in the process and maybe then they have more empathy for the shortcomings of some of this stuff?

Yeah, absolutely. I think a lot of the best practices for product development apply here as well too. Like you want to get that customer feedback early and often. And even better from what we found is for some of our larger customers, they want to be design partners along the journey. Like if we're making a big change to Next JS or to the frameworks that are powering a lot of these large companies that they're very invested in and they've spent so many hours building their tools around, they want to have a say, you know, they want to weigh in, they want to share their opinions on what the actual experience looks like and what maybe the end API looks like, for example, so the earlier you can get them involved in the process, sharing feedback, helping share the narrative is really important. It doesn't mean it's a design by committee. You know, whatever what these customers say is like the only thing that you're going to do. You still have to have an opinion about what makes a good product. And, you know, maybe that means making some decisions that are an API choice that not everybody would agree with, but the feedback is incredibly helpful, for sure.

Got it. I'd like to go back to what you called before. Like, do you have an example of like something in that you screwed up in developer marketing and, and then how you kind of recover from it?

Yeah, I think one of the tough things about being A advocate for a developer company is that when you make a mistake, developers expect there to be clarity. Like they, they don't want to hear some generic verbose message, they want to know the details, what happened. Like they know the systems, they know what you're working with, they understand how these things are built. And extreme clarity and precision is incredibly important when things go wrong. Which is why sometimes if you see like incident retros or reports that get shared out, you know they're in UTC timestamps, they're very detailed about exactly what happened. You're able to really follow along and understand what happened at the system or architecture level that caused this. Was it user error, was it infrastructure error and what are we doing about it going forward? Because it all comes back to trust. As a developer, I placed my trust in this company and something didn't meet the mark and I want to know why and what you're doing from it. So one of the things in terms of, I guess building developer products, that has been hard is just finding the right way to communicate that message and the right way to do it that is authentic and empathetic to the customer who's having a tough time because the service wasn't working as well as they wanted to. But I think the other thing that's been tough for developer marketing kind of goes back to the conversation around how much do you hype something up? Like how do you temper your excitement versus letting the product speak for itself? Because there's a healthy dose here. Like you should be able to talk about the thing that you're excited about. You have conviction in it, you think this is really going to be a great thing for your customers. I'm not saying that we should get rid of all of that, but what I'd learned more over time is the earlier you're validating the product with yourself first with your own team, so dog fooding it and then with early customers as well too gives you a lot more confidence that when you come out and say here's the new version of X and we're so excited about the features in it, you have a lot more confidence that's gonna be received well because you've already showed it to customers, you are using it in production for your own systems and you know that it's working well, which just gives you a different level of clarity and confidence.

Yeah, I'm surprised by like how many product teams don't do this. Like it's like to me it's like a no brainer.

Right?

Like you should dog Food your own shit. And then you should launch it to a couple of beta customers and see what, how they feel about it before you just do the big general announcement. Like. Yeah, I don't know.

I think one of the. Yeah, one of the, one of the things that's tricky for developer companies is surprisingly not a lot of them actually build everything with their own tool, which is I, I bet. I'm surprised when I hear that when folks don't do that because I think it's absolutely critical to be able to know what's working well. Like you have to be customer zero, customer negative one of every single thing that you do.

Yeah, I think Stripe has some really good practices around this. They have like friction logs that they maintain. Even the execs go through their products. Like. Yeah. I think a lot of our companies make the mistake of like being so vision focused that they don't actually like care about what they're shipping next. Like. Yeah, what's coming out of the door actually matters more, man.

So I like, I really like Stripe's idea of vision or friction logs. But I, I've taken it a little bit further to something I like to call exposure hours, which is a term stolen from UX research. And because we're building a tool for developers that's open source that anybody can use, it's free to use. There's a lot of content online about people's experience using Vercel, both written and video content. So if I really want to have a fun time, I'll just go to YouTube and search Vercel and just watch people's videos where they're using the product, they're building something. It's like a three hour video tutorial where somebody's building on Next JS and Vercel and you would be surprised at how many little things you catch, you know, because I know everything about the dashboard. And like that one little thing like the spinner showed up just a little bit too earlier. Did you see the timestamp there was like formatted a little strange. They might not even notice it, but I notice it. And that's like on the micro papercut side. But sometimes you can. It's just user testing. Like you watch them click around and they're missing the navigation bar. Like they can't find where they're trying to go to. It's democratized user testing, basically.

Yeah. It's like watching yourself on a YouTube video. Right. It's like you gotta embrace the cringe.

Oh yeah.

And make it uncomfortable. Yeah.

Yes. 100% so any kind of two, two last questions.

First question is I think you're a great writer and we talk about, you know, writing for developers, but like, can you share just like a couple of tips about just great writing in general, whether it's for developers or whatever customer you're writing for?

Yeah, I think there's no one writing process that works best for everyone, but I can share what's worked well for me and maybe it will resonate for others. So for me, the process that helps me kind of get towards a piece of content that I feel really good about, it's usually been brewing for some time. So it starts with an idea that I scribble down in in my notes app and maybe I'll write down a couple bullet points of what I'd like to talk about, but I kind of just store it away. Like I had the post I had on developer marketing, I've had written down as a, like a, a bullet point. For a while I wasn't really sure exactly what I was going to say. Then over time, usually I'll maybe I'll add a couple more bullets or just some other notes as things come up or as I think about it a little bit more. And then usually there's this critical moment where I realize that this needs to be in the world. Like, I need to put a pen to paper here and get this out of my brain because I keep wanting to reference a hyperlink that does not exist. And in the case of this developer marketing one, I was like, I keep explaining myself here and I haven't put in the time to like really codify this into a piece of content. And that's the motivation that gets it over the finish line for me. I'm like, all right, I gotta sit down, I gotta do it. So I sit down, I take my bullet points, I expand them out to an outline, and I start to actually go through and put a pen to paper and write some content out. Now the first draft is usually shit. It's usually not very good. And then from there I try to lean on people that I trust to get feedback from. So I'll send it out to a couple people and say, what do you think? Like, especially if it's on a specific piece, I will ask people that are experts in that area that I know or people who are in that area that I know for their feedback. Like, hey, I know you work in developer marketing. What do you think about this? Like, is it missing anything? Do you disagree with any of it? And that usually comes back with, you know, a bunch of notes and bullets of just what people liked and what they didn't like. And I kind of just let it sit there. Honestly, I think about it a little bit more. I let it stew in my brain and then I come back to it with a fresh set of eyes and I usually refactor it quite a bit. So for the developer marketing piece I wrote, the final draft looks pretty different than what the first draft looked like because I got a lot of feedback that I thought about for like a week and then rewrote most of it and I actually ended like moving the conclusion up to the top basically because you kind of want to get to the point sooner. Like, so what actually does it look like? There's basically like five bullet points in the post. Like what is great developer marketing look like? Like, I don't want to have to wait to get to the bottom of the article to get the summary. So I put the bottom line up front. Like publish content that don't publish content you wouldn't share yourself. You know, don't treat developers with this one time transaction. When something sucks about your product, you need to own it. You should be involved in the community and you want to build a great developer experience. Like a lot of the themes we've talked about today, I just wanted to shift that up to the top. So that's been the process that worked for me. I also revisit my post every now and then. Like maybe if something's been out for three years, I go back and reread it and just think about what I got right and what I would maybe update and sometimes I'll put a little footnote, like updated in 2024. Like, here's how I'm thinking about the latest bits, but that's what I, that's what's worked for me.

So it sounds like time is a key requirement, right? Like, like it take takes like weeks or maybe like it's like a week to go through this process, right.

For the best stuff that I write, it takes a little bit more time. I think sometimes I will just completely write and ship and post something kind of off the top of the head, but not as often anymore.

It's kind of funny because sometimes I, I would tweet some random stuff and it goes super viral. But if I reflect on that, it's something that I, I actually wanted to get off my chest for a long time and yes. And then finally I just did it.

You, you make a good point, which is the tweet is a Very good medium sized bit where a lot of my written posts are expansions of a tweet. So sometimes when I share that or I save that note in my, you know, notes app, other times I just tweeted out like I tweeted out product Engineer greater than full stack Engineer. That was it. And the tweet got really popular and I was like, huh, I should probably write about this. Like I should probably write about why I think that, you know, product engineers are an interesting role that's growing and yeah, underrated the X platform. Yeah.

It's good to screw your testings before you invest the time to do it, to flesh it out. Yes.

Yeah.

So last question is just kind of recap everything you talked about. Any kind of great closing words of advice for people who are building for developers?

Yeah, yeah, I think there's an iteration cycle you can follow that in my opinion is almost guaranteed to help you build a great product for developers. And it's not rocket science, it's actually very simple which is talk to them, build relationships with developers, get out there and hear what's working well, what's not working well, really listen to their feedback and you know, go five, ask five whys, go five layers deep of asking questions to hear about what's working and what's not working well and do a little discovery on how things are going. Then critically go back and fix the things that they're frustrated with as fast as possible and iterate on the product experience and tell them. I think a lot of people surprisingly miss the tell them step. They think that if I just broadcast this message to the world, well of course they're going to see it. But people are busy and algorithms on socials are weird sometimes and maybe they are on holiday and they didn't log on that day and people miss stuff. So if you fix something that you talk to a customer about, should go tell them and build that trust and then repeat and do that over and over in small chunks. There's small iterations towards this broad vision. So while you have, you can have a great strategy about how to build the next billion dollar developer product. It's actually the battle is won in the trenches of every single day. Iterating and iterating on how you make the experience better. It could be two paragraph change in your docs because you talk to a customer and they didn't understand this one bit about how it worked. It could be one, you know, small UX issue with one of the inputs and where the button was placed that tripped up one developer. Because for every one person you talk to, every one customer, every 10 customers, you're going to get to a point where there's a hundred more who don't say anything. And that's why I like the exposure hours thing in particular, which just more generalize is, you know, customer research and you know, customer testing is you're seeing how people are actually using your product without having to be there all the time.

I love that. I think, yeah, the fast iteration cycles. I think it matters for all kinds of products. I mean, and like if you keep doing this, like from my experience, you kind of build this like neural network of like what customers want. I mean that's what people call product sense, I guess. And then it probably will like shift your grand vision and like you learn more about what people actually want long term too. So.

Yep.

So yeah, it's a very virtuous cycle.

Absolutely.

So where can people find you online, Lee?

Yeah, if you go to leerob IO it's got links to my socials and stuff there. But that's where I publish blog posts and I have a guest book if you want to sign it. Very, you know, 1990s web.

Awesome. Well, thanks for your time. I personally learned a lot. And here's to building for developers.

Thank you for having me.

Sa.