Hi, everyone. This is a different episode. I recently started a job at a DevTool startup. There's about eight of us. I haven't announced which one yet.

I'm gonna do that a bit later. I am trying to help them grow. It's very, very early stages, definitely pre PMF. It's pre people really using us. So I have been trying to like study stuff and the person that I've been studying this week is Lee Robinson.

He's written an absolute ton of stuff and it's really amazing. If you don't know Lee, he was until very recently the head of DevRel slash developer marketing at Vercel. He's kind of a legendary figure and he just joined CurseUp to head up developer education, AI education. I'm sure he's the de facto head of DevRel at Cursor as well. Hopefully, there's a few gems in what he said.

Okay. So this is Lee's website. If you're not on video, then it doesn't matter. I'm gonna say it all out anyway. Okay.

So here we can see that Lee actually helped Vercel go from 1 to 200,000,000 ARR. He helps the Next. Js community reach 1,300,000 plus active devs. And, I mean I mean that that that's insane, basically. One one to 200,000,000 ARR in particular is absolutely insane.

Okay. So there are a few things that I really, really like about what Lee says. I'm I'm gonna start with what Lee has said about developer experience because I think this is for me coming into this new job, this feels like the biggest thing to just get right first is I should build a product that people use. And if you don't have the developer experience, then it's just not even gonna happen. So what Lee says about documentation.

Docs make or break developer products. They must be high quality and available everywhere on your website, in their editor, and inside AI chatbots. Your goal is to write content beginners can understand and experts appreciate. Great docs are products themselves. They need constant updates and polish.

New product features can't ship without the reference docs. So he's got suggestions here. So he's got nine suggestions. The first one is ensure docs have many code examples that you can copy paste or run. Number two, optimize for skimming.

Good use of bold, italics, lists, headings, images, etcetera. Number three, with writing, be both precise and concise. Avoid technical jargon and idioms. I think this is such a big one because I see so many times where people invent their wording for something new and just kind of use that throughout. And I have to say that we're kinda doing that as well.

And it's something that I've been trying to not do, but it's so hard when you have new concepts especially.

More often than not, if people write how they talk, company communication would be so much more clear. I wanna read something that sounds like it's coming from a human, not something that says, you know, we delved into blah blah blah, which is like, okay. Well, this is probably GPT But generated. 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 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.

Number four, keep the first time experience simple and slowly reveal complexity. That's a really good one. Feel I like that's just having an opinion on how someone should do it as well and just like, they should probably just do this and then we'll let them configure it later.

If I'm evaluating a tool and I've never used it before, there's kind of two paths for me. Either I wanna start building right away, so I would recommend all developer docs have a quick start. Kinda goes back to get started for free for great developer products. Like, I just wanna get going right now. How do I get the product working as fast as possible?

So I think that will always remain. And 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. 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.

Number five, you should still document workarounds even if it's a product gap. I think that's a that's a really big one because your product doesn't do everything and you should help them even if they're gonna even if you can't do it yet. Whatever. Use AI to automate reviews on docs for spelling, grammar, and brevity. Make it easy for developers to leave feedback on docs, e g typos.

I don't I guess like if you're using Mentify or whatever, could probably just do that. Embed docs directly in the code for in editor feedback. This was actually a bit one that I hadn't thought about. And he's put EG JS docs. And that is when you have like the kinda comments right next to the functions.

Number nine, the last one. Add automated checks for broken links and get pushes. Oh, here's an example on Next. Js where they have a GitHub action for validating documentation links. Okay.

Well, it's it's doing quite a lot of stuff but it seems to just check the links are correct and stuff like that. Traverses. Go go check that out. Okay. What else does he say about developer experience?

Number two, community. Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like audit trails, SSO, SCIM provisioning, role based access control. These things are hard to build, and you could get stuck spending all your time doing that instead of actually making a great dev tool.

That's why WorkOS exists. They help you with all of those enterprise features, and they're trusted by OpenAI, Vercel, and Perplexity. And if you use them for user management, you get your first million, yes, million, monthly active users for free. I honestly don't know any dev tools that have a million monthly active users, apart from GitHub maybe. So that'll get you pretty far.

Here's what Kyle from Depot has to say about WorkOS.

We use WorkOS to effectively add all of the SSO and SCIM to Depot. It's single handedly, like, one of the best developer experiences I've ever seen for what is, like, a super painful problem if you were to go and try to roll that yourself. So for us, we can effectively offer SSO and SCIM, and it's like two clicks of a button, and we don't ever have to think about it. It's like one of the best features that we can add to depot. It's super affordable, which effectively allows us to like break the SSO tax joke and essentially say, like, you can have SSO and SCIM as, an add on onto your monthly plan.

Like, it's no problem. So it really allows smaller startups to essentially offer, that enterprise feature without a huge engineering investment behind it. Like, it's literally we can just use a tool behind the scenes, and our life is exponentially easier.

Lee says, building community is a long term investment. It must be in your company DNA. It's not a collection of developers you're trying to sell your product to. It's an exchange. They share bugs.

You fix them. They submit pull requests, you merge and encourage them. This is how you understand what's working or not working with your product. Their feedback shapes the product and the product direction and roadmap. A community forms around a product when developers feel heard.

They share their wins and frustrations and you respond by improving the product or clarifying the docs. You must meet developers where they already are. GitHub, x, Reddit, Slack, or Meetups. So Lee has some suggestions on community. You can't spend too much time talking to developers in the community.

Make yourself accessible to answer questions, EG host to the AMA. Monitor feedback on social media to understand community sentiment. Use a Slack bot to send real time user feedback to product teams. Invest in high quality swag for your top community members. And the final one, everybody loves stickers.

They're cheap and easy to buy in bulk. I would guess that people love Next. Js and Versal stickers more than they love your random startup. And they you probably need to put more effort into, like, making it interesting, I would guess. Although because I don't love stickers, but I know most people do love stickers.

Okay. So let's look at this. I think the biggest thing that Lee says here is that it's like the value exchange. Right? You're not just extracting from them.

If you want them to be part of the community, you actually need to give them a reason. You can't just invite everyone to Slack and just post announcements that you've got new features unless it's like actually relevant to them. So he says, they submit poor request to you merge and encourage them. They show bugs, you fix them. I've seen Lee or heard Lee say that there's like ridiculous alpha in talking to people, finding out what they need fixing or don't like.

Fixing it really fast and then telling them about it. And he said specifically that most people skip the last part of telling the person who told them about this issue. And the reason they often do that is like, well, we're making a big marketing splash anyway. We're announcing the feature. Lee said, a lot of the time people just don't realize.

So they don't see your announcement. So you have to just go tell that specific person. There's ridiculous alpha in that iteration cycle.

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 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 gonna 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, you 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 talked to a customer and they didn't understand this one bit about how it worked. 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 100 more who don't say anything.

Education is the best form of marketing, second only to customer testimonials. Good education not only shows people how to use your product, but why it exists and what they can accomplish with it. It's part storytelling, part technical guide, part product demo. So he's got some suggestions. Build demos that show real world usage of your product, not just hello world.

I think this is actually something I think about a lot is like, what is the demo? Because like in my team, people some people like, it should be fun or it should be like exciting. And I remember that someone else also said it's like it should actually be like really useful as the next stage. And it's really easy to do, like, hello world demos, and it's really hard to do, like, ones which actually represent real use cases, real production use cases.

You actually now need, like, real life examples. That's something that I did a lot with Vercel on trying to focus on building real apps. Because with real apps come real problems, and then people might start easily with a quick start. But now they they basically understand that there's more than that. And if you don't do these real apps with real examples, then either people get lost or people get pissed off because, like, oh, this works only for, like, a stupid use case and not for a real app and stuff like that.

So I think now, not just it's tailored into AI, but also starting to think a lot more about real apps and real use cases. That's what I'm seeing as the new trend, I would say, in dev tools examples and docs.

I think if you can do that, that's really good. If you answer the same question multiple times, turn it into a guide. Yeah. That's a great one. You need both reference material docs and structured learning courses.

In the last episode that I released, it was with Matt from Repla, and he spoke about the Ataxas. And it seems to be that that's kind of what the Ataxas says as well. If you want more of a concrete framework there, they have like reference as well as learning, understanding goals. So like reference, how to guides, tutorials, and explanation. I have to admit, I've not dug deeply into the Ataxas yet, but it seems to match what Lee is saying that you need both reference material, structured learning.

Okay. Now let's talk about what Lee says about developer marketing. So what does great developer marketing look like according to Lee, who seems to be very good at developer marketing? Number one, teaches how to build great products. This is actually a very interesting one.

So when developers use a great tool, they're curious about how it's built. The best developer marketing taps into this cure curiosity. What technology choices helped craft this product experience? It often comes down to the implementation. Even great tools can be paired with skill issues.

But they want to learn more. Your product is your best marketing. Explain how you built an exceptional product with your own technology. Share how your customers were able to do the same. Once you've captured their interest of your product, you keep your developers engaged by focusing on the developer experience.

Write docs worth sharing, filled with helpful diagrams and detailed detailed descriptions. Create code examples and templates to help them get started quickly. This is interesting because it's like you're actually explaining how to build a developer product in some parts, like how you because because often I feel like developer products are quite difficult, more difficult than most SaaS apps for instance. And so even though most devs are not building those things, you could actually dig into those fun difficult parts of it. And it's very interesting.

And then, yeah, also, like, he's got about sharing how you dog food at your own product and how your customers have been able to build with your products and getting into the technical parts of it. Number two on developer marketing, builds and retains trust. So great developer marketing builds and retains trust. Building, growing, and retaining developer trust is your most valuable asset. Developers won't try your product the first time they hear about it.

They need to hear positive feedback several times before they trust it enough to give it a try. Experienced developers are skeptical of almost everything. It's hard to earn trust. They don't want to contact sales, jump on a quick call even with James from Posthoc, or get junk emails. Trust is built by sharing helpful content sometimes unrelated to the product.

Be ruthless with your content editing and quality bar. Don't publish anything you wouldn't share yourself. Avoid buzzwords, acronyms, and vague explanations of the technology. Make sure every code example and link works. Be careful about overpromising simplicity.

This is often the job of developer relations. And I also saw Lee posted a tweet about how there should be someone inside the company who says no to all the, like, BS that ends up being put out by marketing or whatever. And Lee said this is basically the job of DevRel, and he's not not joking. Don't overpromise, underdeliver. Under promise, over deliver with your product.

So he said it's really easy to get excited about what you're launching about the technology, but don't act as if it's some panacea when it's not because it will just come back and bite you in the ass. And I also heard Lee talking like about Next. Js. And I remember clearly him saying, oh, you know, I think he was talking about, like, markdown. He's like, oh, markdown support is not where it should be yet.

Next. Js needs to have better support for for markdown and and MDX. So there's room for us to to grow there. It's pretty good. What do you mean better support?

It's pretty good. You just said Maybe maybe I'm I'm obviously hypercritical of everything. But But what what could be better? Understand. There wasn't multiple ways to do markdown in Next.

So the pro and the con of that is that you have the flexibility to choose which one you want. But selfishly, from a, like, encapsulated bundle perspective, it would be great if it just worked out of the box. There's trade offs, of course, but I I don't know. That's a world I would like to get to. Okay.

Alright.

This was in, like this was, like, April ago, by the way. 2021. So I'm sure it is now. But in in that short time that I've been at this company, I've been, like the guy that's like, oh, we can't say that because we're not. We we don't we can't say we're the best.

We can't say we are the fastest. We can't say unless these things are like verifiably true and you are, like, it's because I think in most other marketing context, you could easily just, like, say, like, Buzzwords acronyms, fake explanations. You you wanna keep putting content out, all this sort of stuff. But, like, in developer marketing, it feels like that trust is just so high. And if and people are skeptical.

And if they see you, like, not, like, overpromising, under delivering, or just, like, talking like a marketer, then you're gonna lose trust.

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. 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, really only comparing against yourself. I think this is also a mistake that I've made in the past.

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 wanna stay focused on just making your product better.

Number three, concise and precise. Great marketing values your time. Every word matters. Show them how to build interesting things. Don't fill a post with 1,000 words of garbage.

Okay. So this is Lee is telling us how to write an email here. So he says, put the bottom line up front. If I stop reading after the first paragraph, did I get what I needed to know? Is there action required?

Put that in the email subject line. Make it easy to scan. He also says this about documentation. The visual flow of the content is as important as the words you choose. They should be able to quickly scan for landmarks, like code examples or commands they need to run.

I think he also talks in the documentation about, like, use of, bold and italics and underlining and stuff. I don't know if you said underlining. I guess that's just links. Address their fears directly. This email mentions a migration.

Am I going to lose my data? Do I need to make changes right away? By what date am I going to be charged more? Personalize the content. Show them their team name, the date the migration starts and finishes in UTC, exactly how much their price was before and after and how they can take action.

Maybe a CLI command that shows their usage. Yeah. This is lot of work, but worth doing because then you're actually not leaving them any doubt in they have to they have to, like, go calculate. Oh, do I do I do I was I registered before the thirty first of November two thousand and twenty two? Yeah.

This is really good. Number four, builds a community. Developers are more likely to trust open source tools. These tools likely have a community of other developers learning together. They can take their knowledge of the tool from job to job as they grow in their careers.

Community is built on trust and transparency. When something sucks with your product, own it. Don't try to hide the failure. Lean into it. Bring the community along for the continuous iteration of your product.

You told us this was bad and we fixed it. Follow-up with people after you ship. That's what we're talking about earlier. So don't try to hide the failure. Lean into it.

Bring the community along for the continuous iteration of your product. You told us this bad and this was bad and we fixed it. Follow-up with people after you ship. That's just I think it's really, really, really important. You should host hackathons or meetups.

Spend time talking to developers one to one. Their feedback drives, product improvement, and content ideas. What are people struggling with? Where are people struggling? Write about how you fix that.

Yeah. I feel like this is just. This goes to what Lee says as well. It's like, you can't spend too much time with users or something. I think he says oh, yeah.

You can't spend too much time talking to developers in the community. You cannot spend too much time. And also this always feels like you're kind of wasting time because you're just like, we we like to just be like shipping stuff. But if you talk to users, then you actually know what you're doing. This is what I'm trying to do anyway.

And then he also has a article on developer products. So let's see if you all agree on this. Number one, you should embrace open source. Experienced developers love open source products because they've seen the opposite. They've struggled to debug a black box closed source tool or worse had a previously open tool change licenses or close its source code.

New developers love open source products because they're learning skills that help them advance in their career where knowledge transfers from company to company. Open source tools often have better documentation as well. I don't think this is a surprise to anyone, but I think that even if you're not open source, I think that these points are important that Lee says, whereas, like, the kind of people getting, like, experienced developers have been burned and they're gonna be skeptical about license changes, but also just, like, pricing changes or, like, deprecations or like companies not delivering on reliability and stuff. New developers value learning new things that they can take on to the next job. So and I mean, documentation is obviously important.

So I think this is a very good point and especially the reasons that he gives. Number two, you should have a free tier. Developers don't want to talk to your sales team. They want to trial the products with as little friction as possible. Start free, then grow once they validated the product works and will solve their needs.

There are exceptions to this rule. You might have procured software that required months of negotiations, license keys to get access, and hand guided provisioning of resources from a human. But ask your developer. They would have preferred if they could have started self serve. I guess this was a call out to Twilio there.

Especially if you're doing something new, I think you need to have a free to if you're a planet scale and everyone knows what a database is, that's different. Okay. You should have excellent documentation. The better the documentation, the more likely the developer is to try your product. This isn't about specific UI features like dark mode or command k search dialogues.

How quickly can they find an answer to their problem? Great documentation is either a reference guide or an educational tool. Educational materials should be equally compelling for both beginners and experts. Experts love to hear concepts explained in a simple way. Beginners want new concepts progressively explained.

Don't drop 10 new concepts and five acronyms right away. Write like you're teaching beginners. This is just difficult to do. This is very difficult to do. And remember Lee said, education is the best form of developer marketing, second only to customer testimonials.

So this is not easy, but it's very important. Number four, you should be able to get support from developers. When developers can't find the answers in your docs, they'll reach out to support. They want to talk to someone who emphasizes and understands their problem. It's easy to tell whether the support person actually gets it.

Minimize the number of hops between problem and support and solution. Ideally, cutting out layers of humans in the middle. This is why roles like developer advocates or customer success engineers exist. Developers expect to talk to developers. I remember speaking to Gonto from Vercel or perhaps it was an article from Hank, maybe both of them.

And Hank was the CMO of Vercel. And they spoke about hiring salespeople from the Apple Store and that sort of, like, very technical person. And it just changed the way that, like, the salesperson wasn't suddenly reaching out to you to just talk about contracts and, you know, went trying to figure out if you had urgency. They were actually just trying to help you and and and the conversation completely changed when you when they reached out with value. So I think you just need to have your company stacked with people who are technical and who like helping developers.

Right? I think that's seems to be what Vercel have done really well.

One thing, for example, that we did with Versal was build this team that was called product advocates. Like, every company has SDRs. When the SDR goes after developers, developers don't wanna talk to a sales guy. It's like, who the fuck is this guy? I don't wanna talk to them.

So our idea with them was let's hire somebody technical. So we went into Apple Genius Bar, to Best Buy tech support, and CS boot camps to hire people who were slightly technical but were still gonna be cheap enough to be an SDR. Once we had those people, we trained them on how to use the product slightly. And then after that, the whole idea was when is a good time for these people to reach out to connect with sign ups. And the reality was that it made sense when they were blocked.

So we tried to guess when people were blocked. If you click on a section in the dashboard, go to docs, come back, and do nothing, maybe you are blocked. In those cases, we had these product advocates, these technical SDRs contact you, try to help you get unblocked, and then eventually say something like, hey, we got you unblocked. You want to have somebody on your team talk to sites.

Number five, you should be part of a community. Where do developers go to hang out? Online and in person communities. This doesn't mean you need to start a community for your product. In fact, you probably shouldn't.

Instead, look at where developers are already spending time. Go there, talk to them, and contribute to the discourse. Communities are not a transactional relationship. You are there to provide value. This is a long game, sometimes taking years to materialize value back, but then obvious in hindsight.

And then Leah's links back to building oh, he's actually got an article on community moderation as well. Okay. Let's dig in on communities as well. I didn't see this one. This is like a hidden article.

Okay. So Lee has written five points on community moderation. I'm gonna fly for this a little bit. So number one, be kind. Always be kind even when enforcing rules.

This can be difficult. Address issues with empathy and understanding. This compassion can and should exist with firmness. Clearly explain why moderation actions were taken, and if relevant, link back to the code of conduct. When addressing negative feedback, be exceptionally detailed in your response.

Be calm, factual, and empathetic to their concerns. Number two, build long term relationships. Community trust is slowly built over time. There isn't a shortcut or hack. Give the community more than you take.

For example, you should be adding value in 90% of the conversations or interactions you have, EG being helpful, answering questions, and only 10% asking for things. EG, read our new blog post, try the product. When community members do wonderful things, celebrate them, highlight their work, give them kudos, maybe even offer some swag. I'm in the developer marketing community, which you should join if you're not already in. Just search marketing2.dev.

Like this? Marketing2.dev. And, yeah, it's like you you see people that are just like constantly helping other people. And you see people that just like drop in and just like post a link to something that they've done and, you know, that that's just different. Right?

Like like, that's a small example, but like, we all notice that people that are just like always helpful. And then when that person rarely asks you for something, you're like, yeah. Like, I wanna help you. Whereas, yeah, it's just like value. Give, give, give.

Number three, don't stop the conversation too soon. Resist the temptation to overly moderate. Some tension is natural as it encourages open dialogue. If discussions turns dogpiling, consider closing them and providing more focused next steps based on the feedback. I mean, I'm guessing this is something that most people are not gonna get tons of, but next year is just so big and people got so passionate about it.

I guess he's talking about, like, when someone someone starts off just like saying, oh, this feature is like just doesn't work well. And then someone else says, oh, yeah. And that's fine. And then there's like, you know, valid criticism. And then someone else comes along and says, making personal attacks or whatever.

And then it's like, alright. Just shut it down. Number four, mostly mute, rarely block. If possible, mute before blocking. This minimizes escalations from upset members after being blocked and creates a less hostile environment.

Blocking should be a last resort. If the conversation turns into harassment or violates code of conduct, be vigilant and take swift action. I'm just gonna I I feel like most of us are not gonna get this like stuff, but you should come back and read what Leah said if if you're lucky enough that your community gets so big that you start to attract rude people. Number five, take personal conversations private. Always respect community members anonymity.

If you need to discuss private information, move the conversations to DM or email. Okay. So some good stuff in there. This is most of Lee's stuff. But I just wanted to like also just look at this page that Lee has about like things that he believes.

And some of this is not related to developer tools. It's just like personal stuff. The reason I think this is interesting is just like if you think that Lee is doing the job that a lot of us spend a lot of time doing at developer tools and he's exceptionally good at it. And so some of the things that he believes probably help that. Okay.

So I know this was an unusual episode, but I just really wanted to share what Lee has written. Lee, I would if you hear this, would love to interview you on the podcast. Everyone should go check out Lee's writing at leerob.com and listen to the various podcasts that he has been on. He's absolutely brilliant and excited for the work he's gonna do at Curseur. One quick note, I used a few clips in this episode from podcasts that aren't mine, especially the PT Yang podcast because he did such a great interview with Lee.

I'm gonna put a link to the episode as well as all the other episodes that I used in the show notes.