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 wise 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 doll developer product the battle is one 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 100 more who don't say anything all

right Le 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 developed 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 uh 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 stocks 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 developers directly then talk to the PM because the PM will be like oh you know let me put on my backlog like you know what 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 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 really 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 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 should is 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 uh 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 frontend JavaScript typescript web development side more and more tools are starting to focus on the 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 got to 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 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 it's kind of how it works right like they've been doing this for a really long time yeah okay so kind of the web just catch up to game 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 tradeoffs 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 go on tangent here because we talk 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 littleit about a AI there 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 moving 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 open AI are smart and empathetic and generally good intention 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 contradict myself though is you see something like a llama 3 or 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 you know more of an expert in the space has a really compelling argument for why Clos 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 I'm definitely partial open source got it yeah I don't know if they've changed their apis op I change your 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 force migration like this morning I was using chat GPT and like it just felt like super slow and I hit the limit a lot faster 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 grade

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 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 which it's like okay well this is probably GPT generated right there's just a lot of flop in general writing across the internet really but especially for documentation and blog posts written content for developers that really Cuts all of that CR and just gets down to the Bare Essentials of what's necessary to get your job done 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 it's like five sentence paragraph then eight S paragraph then six sentence paragraph then new section and it just looks like if you squint your eyes and it's like kind of blurry and you look at it it's like 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 have 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 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 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 Su levs to you can dig into further but to me those are really the two big buckets for the reference more and more sites and more developer tools are starting to do code or uh documentation defined by code so whether that's through typ 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 EP in producing lower quality documentation where it's like lowle effort comments in the code but when done right it can be incredibly powerful because you get a couple things one you can autogenerate 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 side so you can autogenerate 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 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 I have all this context in 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 gpts 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 hardcoded and forgot to update six months ago it's like 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 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 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 uh do today like do they start with like maybe some quick start examples and 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 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 a great developer products like just cut the crft 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 that'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 they resources you know this is you 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 had 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 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 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 Roblox 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 just the middle ground between like you know it makes it easier but you actually still learn something like just copy and pasting 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 hardcoded here's the curriculum go from this to this and along the way you're trying things out you're writing code you're seeing if it works you're comparing the expected result versus what you wrote so you're learning and failing and learn in 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 nextjs for example what if there's a world where you can have a AI model that's trained on all of the nextjs source code it's also 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 because otherwise you just looking up stack overlow or something trying to figure out what's going on right so yeah 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 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 Grell 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 open. 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 in goal like I want to rebuild Netflix like I know exactly what it looks like it's got to have a login State I've got to save my movies to the database I should show different movies based on the region that the visitors 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 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 it's probably like the 10th time like 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 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 L adopters kind of Skeptics right 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 sourced their product they jacked up their prices they made a product decision that you know really affected trust in the community and it kind of makes you just a little bit jaded like so a lot of developers have a chip on their shoulder I think from that as well too so you talked about how you need to have like a cool demo or a video and then you know you actually need to make it possible for developer 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 thing is not there like I think the most recent one was like Devon like the AI engineer thing yeah which apparently is a threat 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 Devon controversy that I think is also like the open AI soraa controversy which is also the rabbit 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 overd 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 forcell I personally thought was incredible and it probably came off like Leah hyping this thing up he's super excited about it this thing is going to be incredible and there have been cases where you know we missed the mark and 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 is 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 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 like 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 nextjs 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 we T before like do you have an example of like something in that you screwed up

in develop marketing 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 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 has been hard is just finding the right way to communicate that message and 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 speed 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 going to be received well because you've already showed it to customers you're 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 a to me it's like a no-brainer right like you should dog food your own 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 think one yeah one of the things is tricky for developer companies is surprisingly not a lot of them actually build everything with their own tool which is I 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 they exact go through their products like yeah I think a lot of other companies make the mistake of like being so Vision focused that they don't like care about what they're shipping next like yeah what's coming out the door actually matters more man so I like I really like Stripes 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 versell both written and video content so if I really want to have a fun time I'll just go to YouTube and search for cell 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 verell 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 it like the spinner showed up just a little bit too earlier did you see the time stamp there was like formatted a little strange they might not even notice it but I notice it and that's like on the micro paper cut 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 a democratized user testing basically yeah it's like a watching yourself on a YouTube video right it's like you gota embrace the cringe oh yeah and make it uncomfortable yeah yes 100% so any kind of two last questions

first question is I 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 tips about just gr 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 works 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 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 the post I had on developer marketing I've had written down as a like 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 got to sit down I got to 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 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 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 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 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 work for me I also revisit my post every now and then like maybe if something's better 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 it takes like weeks or maybe like Le 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 would twe some random stuff and it goes Super viral but if I reflect on that it's something that I actually wanted to get off my chest for a long time and yes and then finally I just did it you make a good point which is the Tweet is a very good mediumsized 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 notes app other times I just tweet it 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 why I think that you know product Engineers are an interesting role that's growing and yeah underrated the xplatform yeah it's going to test things before for 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

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 wise 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 were 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 dooll developer product it's actually the battle is won in the trenches of every single day iterating an 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 generalized 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 oh yeah it's a very virtual cycle absolutely so where can people find you online Lee yeah if you go to ler rob. 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 learn a lot and here's to building for Developers thank you for having me