Creating a DevTool website that drives conversion

[00:00.13] - Kuba

In this situation, you have on one end a detached buyer persona who only cares about high-level value, and on the other end, you have the developer who cares about the actual functional value and what they’re going to get from it. My claim is that the CTO doesn't do it themselves. At the end of the day, it's going to be the developer looking at that website. Even if a CTO goes to the website because they heard about it at a conference, from a friend, or something like that, and they go to the website to check it out, what’s the next step? Are they going to spend time testing it out themselves? Most of the time, no. They might talk to their director, a solution architect, or maybe a senior developer to evaluate it, take a look, or share it with the team to see if people find it valuable. The CTO is not going to be evaluating this. You need to land the value for the developer because even in that most CTO-heavy scenario, where the CTO actually brings the tool because they opened your cold email and decided to take a look…

[01:18.18] - Kuba

The next step is the developer looking at the website. My claim is that oftentimes it goes the other direction, where it starts with the developer. They know they have a problem, they take a look, they test it out, see that it’s valuable, and start using it on a team—maybe on a free plan, or maybe they upgrade to the team plan that typically sits under the limits of a credit card. So, the team manager needs to buy into this. How does the team manager get bought into this? Well, the developer tells them.

[01:59.22] - Achintya

Welcome to another episode of the Modern DevGTM Brew. I'm super excited for today's episode because we have one of the foremost experts in developer marketing joining us. Please welcome Kuba Chmielniak. Kuba currently serves as the Chief Marketing Officer at Neptune.ai, the most scalable experiment tracker for teams training foundational models. He has previously been a data scientist and serves as an advisor for DevRel at Snowflake. If you’re a developer marketer, you probably already know him as the founder of Developer Markepear, where he shares frameworks and insights on marketing to developers. Fun fact, Kuba has been a professional chess player and coach, so it’s astounding how he manages so many roles. Today, we'll be speaking with him about the best practices for creating a dev tool website that drives conversions. Kuba, great to have you on the podcast today.

[03:07.28] - Kuba

Yeah, great to be here. Maybe just to give you a tip on how I manage to do so many things—it’s that I stopped doing them. I guess that's the thing. I really get passionate about what I'm doing. It's something I’ve learned about myself over time: I cannot really divide between work and life, so I might as well embrace it. That’s what I've done for many years now. But that means that I don't do many things at the same time. Typically, it's the current passion. Right now, and for many years, it has been marketing to developers.

[03:44.29] - Achintya

That's amazing. In fact, that's what I wanted to get started with because you have had a unique career path—from a data scientist to a CMO at a developer-focused company. Can you talk a bit about this transition?

[03:59.28] - Kuba

I think, like many folks who transition from dev to marketing, it happens by accident more than anything or by the need of the company. In our case, what happened was I was a senior data scientist at the time, working at DeepSense. It's a great consulting company doing mostly deep learning modeling, but not only that—a lot of machine learning modeling too. Then within that company, Neptune was created. That's where it was born as an internal tool. Piotr, the CTO of that company, decided to spin it off as a startup and asked me if I wanted to join and do DevRel work. We didn't call it that back then, but it was basically blogging, sharing with the community. We would participate in Kaggle competitions and share the open-source solutions. That was our spiel, so to speak. I didn't know much about marketing at that point. I did the DevRel stuff. But then we hired a marketing team, fired a marketing team, and worked with an agency that, in hindsight, probably wasn’t ready. But then we stopped doing that. Midway through a conversation, we were trying to hire a head of marketing, and that guy, Mark Zollner, asked, "Hey Kuba, listen, you're the end user, right? You already know the product inside out. You don't know marketing, but I do. So maybe I advise you, you learn it, and you take on marketing." That's basically what I did. I figured this is an interesting field to test out, and it seemed that by that point, many people had tried and couldn't do it. It seemed hard, and I'm always up for a challenge. I saw a lot of parallels between the things that I did before, like chess for strategy and thinking in game theory terms about many things, or just pure strategy. Then there are parallels and learnings I took from my studies. I studied theoretical physics and finance and accounting—completely irrelevant, potentially, things. But I did work in statistics on both of these. When it comes to marketing measurements, and then my master’s thesis, which was basically about modeling, figuring out which model of the universe is most likely based on supernova data and gamma-burst-ray arrays—basically, yeah, explosions of supernovas far, far away. Then if you compare that to marketing measurement and attribution today, people are talking about how difficult it is, and it is, of course. But is it harder than figuring out the model of the universe with supernova data? I don't know. We should be able to figure it out. That’s my thinking. I think that's where I started learning on this live organism, which was Neptune. I picked up every podcast, every book, every blog that I thought was useful. Over the years, we grew a lot. We built one of the biggest and most well-known blogs in the space, hitting around 3 million unique visitors a year. That's our blog on neptune.ai/blog. I grew the team and just got really embedded in this. Probably two years ago or something like that, I started sharing some of that stuff, some of my thoughts, on the blog you mentioned.

[00:07:46.00] - Achintya ‍

It's fascinating. I also believe that all of these things ultimately come together in life. Can we do something more specific? I mean, just looking at your role as a CMO at Neptune—you spoke about your blog. Yes, content plays a very crucial role in engaging developers. But when you’re a category creator, your content strategies will be different than when you’re in a more mature or saturated market. Could you speak a bit about that since you’ve seen that across your career?

[08:22.39] - Kuba

I think this is super important because sometimes we try to take tactics that we see are working for different companies and apply them to ours. When I speak to founders, I see it all the time. You've seen this working for that company, let’s do the same. I think the crucial part there is to understand the awareness of the market and the situation in the market. The awareness on the market, awareness about the problem, and then about the products—but the problem first. If you're entering, let's say, the observability space today with so many companies doing a great job and big incumbents that you can anchor to like Datadog or New Relic or other folks like Sentry. Or if you contrast that to entering a completely new category or building that completely new category and attacking a completely new problem—not an angle on an old problem, but a completely new problem, maybe something around AI now instead of ops around AI—the strategy should change. They should change because the simplest way I like to think about it is as a dev, as your target audience—what do I Google? Would I ever Google your category? Would I ever Google your category? Obviously, in observability, many folks, when they choose, will look for alternatives to something or comparisons or migrating from something. Then observability and APM would be something very well known. People would Google it. Then you’d have categories that are completely new, maybe AI-driven, I don’t know, error resolution. I don't know. But many things like that where there is no category yet. It's a new problem. You're attacking it, but it's a new one. Then it's important to understand that because if you're entering that new… You’re solving a new problem, more than anything, you should be talking about the problem and marketing the problem. You’re marketing the category, so to speak. You’re marketing the new category, and you hope to be number one in that category or most recognized, most memorable—whatever it is—but become associated with that category. Whereas if you're in a mature one, what you want to do is focus on differentiation because people know what the category is. If you're a startup entering observability, is it going to help you a lot to write another post about what observability is? Potentially not. Talking about the differentiation and different ways of doing it and problems with it, and then helping people migrate, helping people choose the tool for a particular use case, etc., makes sense. That's the most important part—differentiation of whether there is demand. Do people know the category, or do they not? If they do, then you can rely on higher intent channels—Google being one example—or running Google ads to those higher intent pages, etc., relying on intent data from other tools or using the signal-based tools like Reo.Dev. You can rely on this stuff. Whereas if you're marketing this new category, if you're entering this completely new category, there's no demand yet. Nobody's googling anything. They don't understand they have a problem even. Then you should talk about a problem, and then the channels change. It becomes more Twitter and social media and sharing thoughts on Reddit and Hacker News and engaging in those discussions, etc. Now, it is always valuable to do it. It's always valuable to be in the community, but it is going to be especially valuable and important at the beginning when the category is not established. Because when the category is there, you can create those anchors, etc. But if it's not, you have to create it. You have to create awareness for the problem way more than for your solution to that problem.

[12:42.37] - Achintya

I agree, and that's very insightful. Do you see this also changing based on the persona? If you are creating content for developers versus you are not, and if you are creating content for developers—because I've seen you writing a lot about it—what are the things that somebody should keep in mind?

[12:59.18] - Kuba

Yeah. No, I think that's a great point. I think generally it all comes down to, are you actually creating something valuable? Can you actually teach me something? Can I actually learn something from your content? A lot of the time, when a non-developer is writing content for the developer, it's going to be hard to create that value. It's just harder because it’s harder to resonate, harder to understand the pain at a deep level, etc. It doesn't mean that it never happens, because it definitely can, especially when you're very embedded in the space maybe and you can combine the experiences that developers have in the space right now. You could run reports and surveys and talk to different folks. You’re basically a reporter within that space. Then it can definitely work. There are cool examples of some companies. I forget the name, but I listened to a podcast—I'll try to send a link to it—where basically this company figured they are an equivalent of Bloomberg in security, and so they created an equivalent of Bloomberg News in security, hiring reporters to basically write the things that they would learn from informants within that space and have that network of folks who know what's happening in security. You can definitely do it without being a developer. But when you're educating, think about it this way. Can a senior writer who's writing about productivity tools, marketing tools, sales tools, best diets, best car to pick in 2024, write an article about platform architecture for doing DevOps in 2024 that a senior architect is going to learn something from? The answer is very unlikely. Unless you do a ton of research, but extract that research from subject matter experts, etc. But it's hard. I think for as long as you can do that content and share that knowledge, the ROI could be huge. There are examples of Cockroach and other folks doing it at the beginning. Cockroach Labs is a huge company now, but at the beginning, what they did is they actually did a lot of marketing through sharing how they do things on Hacker News. Basically, how they migrated from this, how they set up this problem, how they figured out this particular super technical thing. Those were founders or almost founder-level engineers that shared it. Tailscale, which is very well known for doing that, does the same thing. Folks who write for Tailscale are engineers building it. You read those articles and you know that this is something that will be interesting to other devs because those folks know what they're talking about. This is a dev writing it. This is better because you may need help from a content writer, but this is a dev writing it. Fly.io is another fantastic example. I think if you have that lens of, is what I'm creating valuable? You'll do fine. Really have that lens. Would you send it to your CTO? Would your CTO send it to their friend? Would the dev you respect like it? Would they share it with their friends? If the answer is resoundingly no, then rethink it. That’s what I'm saying.

[16:35.10] - Achintya

I completely get it. Moving on from the content strategy, another great asset for a CMO of a dev tool company is their website. What are the essential elements that you think contribute to building a powerful DevTool website?

[16:55.03] - Kuba

Yeah, that's a very good point. I think the website is more important than some folks think because basically your homepage—because we're talking about the homepage here—is going to be the most visited one. The website obviously has other pages, but the most important to me are basically the homepage, pricing, and docs. Those would be the most important pages. Docs typically don't even need to live on that same page. But the homepage is where people land a lot of the time, especially when you're early. They may be landing on your GitHub project, but if you're not open source, they will be landing on your homepage. The homepage should be the representation of your positioning, and it should be speaking to the user. That's important. I think many people get this one wrong. Especially if, at the end of the day, you plan on selling to enterprises, or even if you're selling to them right now, you need to convince the developer that there is value in this, that the product does something valuable to them, that it solves the problem. At that point, you don't need to convince the CTO or the CFO that there is ROI in this or that this is going to bring you, I don't know, your revenue will grow faster or whatever that is. You’re convincing the developer first that there is value in the product, that it has functional value, and focusing on that. Once you have the lens that you are speaking to the developer, a lot of things get easier. A lot of the times I see websites that conflate the two. It speaks to both, and it's very conflated all the way from the top, etc. I'm not saying over time it doesn't change, or if your motion is completely outbound to the CTO, sure. But be honest with yourself, who’s actually visiting this site? If it’s devs who maybe saw your article on Hacker News or got interested or saw your ads or saw somebody posting on Twitter and they go to your website, this is a dev, so explain it to them. Now going to those principles—it’s hard for me because I really love websites and homepages, especially. Devs will go to the docs. A lot of the devs will go to the docs. So you assume that’s going to happen. But it’s not great because there are things that you can explain on the website that you can't really do in the docs. There are things that allow a bit more visual and interactive engagement, social proof, sharing all that stuff. You're not going to show it there. Then flow of information, making it attractive and interesting, and going a bit more into values, benefits, and features, but explaining it in a way that is not extremely technical, but still technical, that speaks to both sides. That's easier to do on the homepage. But devs will go to the docs. So make it prevalent, make it visible, make it there, put it there. I do like people putting them in the header, a CTA, having them visible in the navbar—super important to me. Always have the docs out there. Then you want to explain what you do. Maybe that actually goes before everything else. What do you do and how are you different? The reason I'm saying this is because people miss that point. If I typically know other tools because I like to explore, I explore the space, I look at all those different tools, maybe I use some of those tools, etc. If you talk to me as if those other tools didn’t exist or I’ve never heard about them, then you're missing the point. Because most of the time, I do know those other tools, or at least some of them. I do understand what they do. If you tell me that you're basically solving an API for notifications or whatever the problem you're solving is—taking observability again—we solve observability. Yes, you say it so that I know this is the category. You can do it in many different ways, but then explain what’s your angle. Because without the angle, what’s the reason for me to take a look? There are angles. Maybe you're great for a particular architecture of applications, particular languages, particular scale or geography or whatever it is. It could be many things. Spell it out. Make sure that you land that differentiation because you can only afford to speak as if no other companies exist if that's almost the case. If it's that early market, the one we talked about at the beginning, if you're marketing the problem, then by all means, speak about the problem. I'm solving this problem, and that's it. I don't think you need to talk about differentiation because you're differentiating versus the cobbled-together solution, but it typically speaks pretty easily. But make sure to explain what you do and how you’re different. At least hint at it. Because otherwise, you're going to lose them. You're going to lose them because I know those other tools and I know they work. So unless I'm really hitting the problem, I don't want to go further. That’s the second one. The third one is you want to lean on social proof, and social proof from other devs. One thing is social proof as logos, having logos in the header—I think that is important. But funny enough, I think it's important because not having them suggests that people don't use this in production. It's not that having them makes me feel extremely safe and sold. It’s just that not having those logos makes me feel unsafe, that people are not using this. But then you have the part that I really like, and I think is really important, which is having some quotes, social quotes, or just testimonials coming from devs explaining this—that we used it in this way, explaining it in technical terms. I think that is important. I recently listened to an episode with Adam Fard where he said that one of the core principles is that the only proof that matters is social proof, or the only proof that matters to devs is social proof. I'm so with him on that. You really can't understate it. If you can grow that, build that, have it out there, use it on many different pages, use it because devs will trust other devs way more than they can ever trust you. You want that. The next principle that I want to touch on is letting people test it out. That could manifest in different ways. It could be something like a template gallery or a sandbox that is open for me to play in, or it could be just signing up and getting to the value quickly—signing up and testing it out. Make it possible for me to test it out with no commitment. Ideally, do both. Ideally, have both a free plan, some option for me to use this and see that it works for me. Maybe go for either the templates or the full-fledged sandbox, depending on your case, on your situation. There are nuances to when to use which. But the core principle is to make it easy for people to test it because they see your claim, they understand what you do, they understand your angle. They took a look at the docs, maybe, and they understand that the docs claim similar things. They look reasonable. They saw those tweets from other devs talking about getting this value. They want to test it out. They want to see that it is true. They want to experience that value. So make it possible for them. Don't block it. Don't request a demo because that will cost. I'm not saying in all cases it makes sense to get people to the free product. There are situations where it doesn't. But a lot of times it does. In all cases, you want some value that they can experience in that first session when they're exploring. Sandbox is a good example when you have a product that is very hard to test out in that single session. You have this interactive environment on your Sandbox.

[25:36.38] - Achintya

Yeah, it’s amazing. It’s a very valuable insight. Very open-ended one also, Kuba, because you are saying that essentially create the entire website experience around the developer and all the things that follow from there. As a CMO, have you felt conflicted about that? Because in many cases, the developer is not the buyer, and the entire experience is being created around a developer while the buyer is taking a secondary role on your prime estate, which is your website. Have you felt conflicted about that? Should I also, and how much should I, target the buyer also or not at all? Should I just focus on this persona as a developer and build that asset around them?

[26:20.22] - Kuba

Yeah, for sure. I love this question. I think it's super valid because most of the time, yes, the buyer is not the end user, right? Especially when you go enterprise. By the way, we talk about this together with Ben Williams in our ultimate guide to DevTool websites that we wrote together, both the principles. This actually came up there as well. I highly recommend it. I'll share the link with you. But what's important is, yes, you need to address both. Both are important. Both the user persona and the buyer persona are important. Now, the question is, how do you address both? What I claim, my claim is that the CTO is not evaluating your tool themselves. Basically, everything sits on this claim. If the CTO is actually evaluating your tool, then either you're building a tool for the CTO, so they are the end user, or that CTO is very hands-on. Maybe it’s a startup or someone like that, where that person is actually very hands-on, i.e., they're also the user. Or maybe the manager of the user, but they touch the tool. But typically, when you think about this situation, you have on one end a detached buyer persona who only cares about high-level value, and on the other end, you have the developer who cares about the actual functional value and the things they’re going to get from it. My claim is that the CTO doesn't do it themselves. At the end of the day, it’s going to be the developer looking at that website. Because even if a CTO goes to the website because they heard about it at a conference, from a friend, or something like that, and they go to the website to check it out, what’s the next step? Are they going to spend time testing it out themselves? Most of the time, no. They might talk to their director, a solution architect, or maybe a senior developer to evaluate it, take a look, or share with the team to see if people find it valuable. The CTO is not going to be evaluating this. You need to land the value for the developer because even in that most CTO-heavy scenario, where the CTO actually brings the tool because they opened your cold email and decided to take a look.

[28:54.49] - Kuba

The next step is the developer looking at the website. My claim is that oftentimes it goes the other direction, where it starts with the developer. They know they have a problem, they take a look, they test it out, see that it’s valuable, and start using it on a team—maybe on a free plan, or maybe they upgrade to the team plan that typically sits under the limits of a credit card. So, the team manager needs to buy into this. How does the team manager get bought into this? Well, the developer tells them that this is valuable for our team. This is what I see. You can take a look. They are doing the selling. Then when it’s not even their boss, the developer's boss, but the boss of their boss—in this case, the CTO—or when it gets adopted, who does the selling? It’s either the manager or the developer. It’s not going to happen where the developers start using this, they tested it out, or they evaluated it, and then it goes to the CTO. And what? The CTO goes to the website and says, "Oh no, this is not valuable because it doesn't talk about..." No, it's not going to happen. But what you need is ammunition in different ways of convincing the buyer persona. You need those things. My claim is it's just not in the most visible places on the website. Let me double click on this. What I see is that the CTO is going to need a lot of the... Or other buyer personas, they’re going to need those ROIs, they’re going to need trust building. They want to understand that they’re not making a stupid mistake that is going to cost them their career because maybe they are migrating away from a non-database to a completely new database that is going to be risky. They need to manage risks. When you manage risk, what do you do? You lean on your peer group, you lean on social proof, you lean on reviews of the sites that actually give you trust—the G2s and Forrester and Gardners of the world. You lean on, "If Uber is using this at scale, then that's great. I want to see that... I want to see that trust. I want to see those case studies. I want to see that the guy from Uber, the CTO of Uber, says that this basically... Basically, I don't know, halved their time of CI/CD job creation or something." Basically, they managed to build those apps faster or their iteration cycle decreased or the retention of devs has increased because they are so much happier now. Yes, you want to hear that from those big teams, but it's about trust. It's not about the value that that individual developer gets as much. Maybe that example when I said about those CI/CD jobs is actually a higher level value—that they get faster. You want to speak to that trust. When you go to the pages on the website that actually address it. From my perspective, it's mostly about us and enterprise. They'll address it where you want to see that the company is not going to go belly up. You want to see that it’s been there for a while or has great funding. There are this many people working there. They will be able to support that organization. It's a global org of 400 people or whatever. I want to see certifications. Is it SOC2? Is it GDPR? Do I have HEPA? Do I have that stuff? Do you want to see those signals? Do you deploy on my infra, or would I have to switch from AWS to Google to use it? I want to see that you have it, that it works on private clouds, and everything is nice and smooth when I actually deploy this or when we try to roll it out. But it's mostly trust if you think about it. Then the ROIs help, but they build that trust. You want to have them. You want to have those case studies. You want to have those white papers. You want to give your sales team materials that they can share—semi-ready slide decks that they can reuse or the one-pagers and things like that. You want to do that, but you don't want to do that on the homepage. Not on 70% or 80% of that homepage. I do like having the enterprise section very low on the page. I do like... But it’s, again, all about trust, all about those big enterprise logos, big usage numbers, big… It's basically like, "Do enterprises trust you? Do people trust you? Can I trust you?" This is what you want to convey because the developer should do the selling for you. They should be doing the selling. You're not going to sell your slightly better way of doing notifications to the CTO. I think it's impossible. It has to be your dev who explains that this actually saves us so much time because it's better because in our way of doing this, this actually translates to us working quicker, blah, blah, blah. That's what I believe.

[34:13.08] - Achintya

Makes sense. Thanks. That is super insightful, Kuba. This is perhaps the last question that I ask on my podcast most of the time, but what are some of the best books, podcasts, blogs, and other resources that you recommend to developer marketers out there?

[34:29.01] - Kuba

I'd start with our... Well, maybe if you have to plug it, then let's plug it right away. I definitely believe that my blog is really good and the newsletter too, so go to markepear.com and find it. But we have a great community together with other DevTool leaders. We created Marketing to Devs. I think it's fantastic. I wish I was more active, but people are already asking great questions, giving great answers. I love that community. I think it's one of the best things out there for DevTool GTM folks right now. When it comes to podcasts, I love Scaling DevTools. I love Open Source Startup. I do look through Saster and stuff like that for good episodes that are with DevTool folks or there are some other places. But yeah, those would be the ones. Then other resources—I think Heavybit is very under... I don't know. People don't know about it for some reason. I find it extremely valuable. The content is fantastic, especially for open-source folks. I love that. On the books front, I’d say that there are some great books for every marketer, but developer marketing specifically—I think reading the book from Adam Duvander, Developer Marketing Does Not Exist, even though I do believe it exists, is a great book. More recently, I bought a copy. I haven't read it yet, but knowing the content that Adam Frankl has put out, I imagine that book must be amazing. I bought it. I haven't read it yet. I'm hoping to actually sit down with it this weekend. But Adam Frankl's new book—I think it’s Developer Startup or something like that—but it’s got to be fantastic. But if you do one thing and you want to be plugged in and see all of those other resources, then I'd suggest you go to that community. There’s Marketing to Devs, and people are sharing great stuff in there, including all of those places.

[6:36.49] - Achintya

Yeah, I agree. Some of these are amazing resources. As a DevTool sales/revenue person a couple of years back, these were some of the ones that I was visiting. Of course, I also always felt that there are very few resources out there. Now, that has changed a lot in the last one or two years. All of these are really amazing resources. I definitely recommend Heavybit. I definitely recommend Adam Frankl's thesis on all of this in the book.

[37:05.34] - Kuba

Just to add, when you were talking about, I definitely have to mention yours as well. There’s one more—like your Substack, some of those developer funnel articles, I keep sharing them. I love this. It's such a good explanation of what I talked about with this user versus buyer and things like that in so much more detail. I think that's great. One more resource that is... I mean, sometimes it's about that, sometimes it's more about the general POG, but content from Hypergrowth Partners is a bomb as well. They have this marketing funnel article that I keep sending that I absolutely love. Now there is a lot of content. Funny enough, two years ago when I started this blog, one of the reasons for me to start it was there was nothing there. I figured I'd start it to start a discussion and hopefully find other people who could disagree and tell me, "No, there are a hundred better ways of doing it." I found that too. But it's such a better place right now with so many more resources that are very valuable and come from practitioners that, yeah, just use them.

[38:15.39] - Achintya

Well, absolutely. Thanks to all of your work and the work of others in making this a much easier place to navigate for anybody who's trying to learn here. That's all from our side. Thanks so much for being here on the podcast. It was amazing—really, really valuable. Thank you and have a nice day.

[38:35.48] - Kuba

Thank you. Thank you so much, Achintya. It was fun talking to you.