Developer marketing is a different game with its own set of rules, and being technical yourself doesn’t guarantee you’ll win it.
In this episode of plugin.fm, Meg Scarborough, founder of content agency Megawatt (now acquired by LaunchSquad), shares why traditional marketing tactics fall flat with technical audiences. She unpacks the nuances of developer psychology, explains why trust and proof beat flashy claims every time, and breaks down how non-technical marketers can still create content that speaks to makers.
Whether you're a software maker selling to fellow developers or a marketer learning the ropes of technical content, Meg offers practical advice on how to communicate with clarity, authenticity, and relevance. Learn how to structure your content strategy, segment your email lists, avoid community backlash, and build marketing assets developers actually value — from documentation to deep-dive tutorials.
If you’re targeting technical users and want your product to stand out (without sounding like a walking ad), this episode is for you.
plugin.fm is brought to you by Freemius, your all-in-one e-commerce partner for selling software, plugins, themes, and SaaS. If you enjoyed this episode, head to plugin.fm to check out more interviews with makers and marketers.
Meg: You can't really market to developers. What you really want to be doing is showing them that you understand their challenges and showing them that you can help them with those challenges.
Patrick: In this episode, we're hosting Meg Scarborough, brand developer, expert technical communicator, and founder of MegaWatt, on why marketing to software makers is unlike marketing to anyone else.
Meg: They're very picky, and picky for a good reason, right? Because they're buying software, but they're also building software.
Patrick: Software makers aren't some fringe niche. They're your early adopters, internal champions, and ones that make sure your software is understood and actually gets used. Here's the catch: being a technical person doesn’t mean you know how to market to technical people.
Meg: They really don't respond well to marketing speak, to corporate jargon, to fluff. You need to learn how to speak their language.
Patrick: Today’s chat is all about what works and what falls flat, and how to bridge the gap between technical brains and marketing mastery.
Hello, everyone, and welcome to another episode of Plugin.fm, where we extract key lessons from top entrepreneurs to inspire your business growth. My name is Patrick Rauland. I'm an e-commerce expert and educator, and I'm here with my co-host, Goran Mirkovich, a content marketing specialist and the CMO at Freemius.
Meg, I’m really glad you’re here!
Meg: I’m so excited to be here. Thank you for having me.
Patrick: So Meg, if you're at some sort of technical event and someone doesn't know anything about you, why should they listen to you talk about these technical topics?
Meg: I'm a communicator. That's something that comes naturally to me, and it's a skill that I've really honed over the course of my career. I've worked with quantum tech companies and nanotech companies and biotech companies, but ultimately I've specialized in what I call deep tech—so applied AI and machine learning, data science, developer tools, things like that. Those are difficult things to communicate about to technical folks. They're even more difficult to communicate about to a more general audience or a business audience. And I think it's important that people like me exist who can bridge that gap. I think there's a lot of value in knowing how to communicate the purpose and the functionality and the ultimate, like, value to society or to people of what you're building to all of these different audiences. And I think it's important that people like me exist who can bridge that gap.
Patrick: So I think many people who make software make software for technical audiences. You know, people make website software to help website developers do stuff, right? That's just a very simple example.
And I think if you've ever tried to communicate with those people, they're different from a regular consumer looking to buy shoes or something. So I guess let's just start with: what makes your work important? Why is it important to speak to technical audiences?
Meg: Yeah. I mean, as you put it, a lot of software is built for technical audiences to use. Even when they're not, you know, the ultimate buyer, they are probably going to be the ones who are putting their hands on the actual technology. So they're usually champions in the process. And developers in particular, you know, if we're talking about that kind of technical audience, they're very picky—and picky for good reason, right? Because they're buying software, but they're also building software. So they know a lot about what they're buying.
They really don't respond well to marketing speak, to corporate jargon, to fluff. So it's really important that you are able to understand and communicate to these audiences. And I think it takes a lot of—and takes a lot of time—talking to these audiences, listening to these audiences, interviewing them to really understand their point of view and get it across in a way that resonates with them. And it can be really hard for brands to do. And so I think that's why it's important that people like me—who are nerds and love to talk to developers exist—but who also love writing and love communicating with people.
Patrick: Quick reality check. Do you really know who you’re talking to? Developers, CTOs, product managers—they all want different things from your content. Meg breaks down how to map your messaging to the right audience, because getting this wrong means wasted work and ghosted leads.
Let me just take one step backwards. How do you know if you have a technical audience? If I make a calendar software, you know, is that a technical audience or is that just a regular user? How do you even know if you should think about this?
Meg: Yeah, that's a great question. I mean, I think I would hope that most people, by the time they're starting to create content, understand who their audience is. But it is a good question, because I think often I've seen a lot of companies actually not understand that while technical users are ultimately the people who are going to be using their solutions, they're not actually the people they should be marketing to. So the question really is: who's your buyer?
How involved in the buying process are technical people? And then, like, who's gonna use it at the end of the day? And then I think you kind of have to figure out how much content you need to create for each of those audiences based on how they're involved in the buying process and then how they're involved in the user experience.
Patrick: I've made a lot of marketing stuff for developers, and I feel like developers have—I'm trying to think of a nice way to say this, but they can smell...
Meg: They're very particular.
Patrick: But I also feel like sometimes the marketing you do for a regular user does not work well for a developer. Like, if it's really fluffy language, I feel like that actually pushes developers away. Can you speak to that a little bit?
Meg: Yeah, absolutely. There's a very famous book—I think I have it over here—Developer Marketing Does Not Exist by Adam Duvander. The basic concept is: you can't really market to developers. What you really want to be doing is showing them that you understand their challenges and showing them that you can help them with those challenges. So any type of quote-unquote marketing, quote-unquote content, that you're producing for developers needs to be about how you can help them. It needs to be genuine in that sense.
And you absolutely need to avoid fluff. And I can talk a bit more about what you need to do as opposed to not do, if you want to get into that. But I think you're absolutely right—they do not respond well to fluff or any type of traditional marketing.
Patrick: Are you a developer selling to other developers? Perhaps you’re not a developer at all. It doesn’t matter. Meg argues that curiosity, listening skills, and the willingness to learn can be more powerful than a Computer Science degree when it comes to writing effective dev content.
Goran: I think like we are now in a phase where it's no longer enough to be just helpful. Like, you still need that entertaining factor. You need to, like, bring something new to the conversation. And I think this is especially hard. Like, we have, for instance, an audience of a lot of technical folks who potentially are facing difficulty marketing their products because they can’t do it alone, and if they can, it's like incredibly draining, especially because a lot of them are not marketers or, like, writers. So it requires, like, even more time if this is not a muscle for you.
And the second part of it is, like, hiring people, right? You are faced with a big challenge of, like, hiring someone who can actually, like, run with it—who has, like, expertise and knowledge. So in your mind, like, if you're just, like, in this, like, perpetual hell of: should I build a skill as a writer, or should I, like, look to hire? And how I would look to hire? Why do you think it's the best bet, and why?
Meg: Yeah, I mean, it's a good question. I have met developers who are absolutely fantastic writers, but I think they're—I don't want to say they're few and far between. I would... My brother is actually a really talented developer who can communicate very effectively. I don't think he would call himself a writer, because he tells me, you know, if I were to write a thousand-word blog post, it's going to take me, like, 20 hours. Whereas, you know, for me, that takes an hour probably. So honestly, I don't think it's usually worth an internal technical expert spending a bunch of time to try to become a writer or become a marketer. I think it's usually a better idea to either hire somebody internally or find—you know, if you're smaller, scrappier—find a freelancer you can work with. These days, there are tons of freelancers out there who specialize in very specific niches. So it's not as hard as it used to be to find writers who can do this.
Meg: And I think if you're a larger [company], working with an agency that specifically specializes in writing for the audiences that you're trying to reach can be really helpful. But I don't think it makes any more sense for, like, you know, me to spend enough time on coding that I'm able to, you know, write an app as effectively as one of my clients could.
That's not a good use of my time. I need to understand the basics. I need to understand it enough to ask good questions. And then the other thing I would just say is: you do need to invest in that relationship between marketing and the technical or product side of things. And both sides need to be willing to embrace the other side's perspective, step in their shoes, because there are going to be things that you disagree about fundamentally. You kind of have to have a level of trust, right? Like, I trust you to tell me things that your audience is gonna care about, but you gotta trust me to tell the story in the way that makes the most sense for your brand, even if it feels a little uncomfortable to you. So yeah, I mean, trust and those relationships are really key to getting it right.
Goran: This is very interesting, especially as we are kind of developing the story. Do you think, like, as important as it is for, let's say, like, a marketer or a technical writer to take on, like, a technical project, is it equally important for the founder or, like, the owner of a technical business to actually have some understanding of how this actually works?
So the person can kind of brief the writer or a marketer to help them make their life easier?
Meg: Yeah, it's a great question. You know, I've been thinking about writing an ebook about this and one of these days I'm gonna carve out enough time to actually do it. But I think one of the things that I find missing a lot when I run into these types of challenges that you're describing with clients is clarity from the writing and content and marketing side of things about, you know, what you need from the developer and technical side.
So, you know, for example, I've run into this multiple times and it's always a lesson I'm learning, right? You don't want to put a blog post, let's say, in front of a founder and say, “hey, can you edit this?”
They don't know what "edit this" means. And even a writer is going to say, what do you mean by edit? Do you want a top edit? Do you want a line edit? Do you want a copy edit? Those are really different things. And you do not want to ask a technical person for a line edit, a copy edit—probably even a developmental edit. What you want to ask them for is, like, where am I missing the mark on technical details? Where am I missing the mark on voice? Give me that, like, high-level feedback, and then let me fix it.
Meg: So I think that's explaining what you mean by an edit, and that this is just one example of how we can work better together. But I think that sometimes is a tough thing for marketers to do because they forget that there's some knowledge there about what we mean when we say "edit."
And there's some, like, assumptions we can make when we're working with each other that we need to really, like, make a lot clearer when we're working with developers. And I really think if you're starting at a company as a marketer for the first time, or your marketing team is starting to work with the development team or the product team or something more closely for the first time, getting everyone in a room and saying, like, okay, this is what we're trying to accomplish. This is what our content plan looks like. Keep it high level. Keep it executive summary level, right? But this is what it's gonna look like. This is what I'm gonna pass over to you. This is how much time you should spend on it. This is what I'm looking to get from you. Really just, like, sets those expectations so clearly that you don't run into issues where, like, you turn something over to a technical reviewer and they're like, "This totally missed the mark. Oh my god."
When in reality, it's probably a few simple tweaks for the writer, but a developer doesn't necessarily know how to communicate that. So I guess what I'm saying is just: it's a lot of communication upfront, and then it's a lot of trust-building and relationship-building.
Patrick: From long-form blog posts to high-signal documentation, to Reddit ads, Meg breaks down which content formats developers actually engage with. Spoiler: most devs like to dive deep.
So it sounds difficult to make all this content. And speaking of content, there's a bunch of different types, right? So there's blog posts, white papers, video tutorials, case studies. I worked with a company that did a really good job with code snippets. Do any of these types of content work really well for developers? Like, would you specialize in one or—or—or double down on one?
Meg: Yeah, it's a great question. It's a great question. So I would say, first and foremost, it's important to expand your definition of content when you're thinking about developers. Everything that you think of as, like, marketing content is—probably like this much—and then developers, there's other types of content that they're really interested in.
So one of those types of content is community. So it's how developers talk to each other in forums that may or may not be public. They might be semi-public in the sense that, you know, people are anonymous on those—those types of sites. But it's important to understand those types of conversations that are happening and know how to get involved when it makes sense, know how to build a community when it makes sense and you have the resources.
So that is the type of content. And there's also a lot of content that you can build based on what's happening in those communities and questions that are being asked.
So I think that's a really good place to start. But the other thing I'll say is: the developer lands on your website, the first thing they're going to click most likely is your docs. So your docs need to be really good. They need to be really clear, thorough. They need to help a developer get up and running with your product quickly.
The other thing I would say is you'd be shocked by this, but developers really like long-form content—both long-form written content and long-form video content. And this has been borne out in data over the last several years.
And the reason for that is that developers want to go deep on things. They want to learn things. And so if you're writing a white paper about something they don't know a lot about, they don't want a, you know, a quick-hit blog post that just covers the top tips or whatever. They want to really understand it so they can apply it. The other thing I'll say is they really like actionable content—things they can read and then implement. It doesn't have to be tutorials necessarily, but often it is.
They really want content to come from authoritative sources, so your authors need to be technical, well-known in the industry, authoritative based on their title and their experience. The other thing I'll say is devs don't tend to like social media from a marketing standpoint. If you're going to use social media for devs, you need to be smart about it.
I recommend quick-hit things like short videos that they can click through and go watch a longer video.
And I recommend, if you are good at it—doing funny, entertaining content for devs on social can work really well. But if you're not good at it, you gotta be careful about coming across as authentic on social media, especially.
Patrick: Driving devs into the sales funnel is harder than opening over-caffeinated house cats. You can’t just show up to a developer community and drop a link to your product—you’ll, like, get ignored or banned. Meg explains how to participate authentically and add value without sounding like a walking promo.
Goran: I love this. We actually, you know, since we target primarily to a technical audience, most of our, customers—I mean partners—are, you know, indie devhackers, people who, like, build products on their own and, like, try to grow them. And we first-hand saw that, like, community is actually an aspect. So we have, like, a big dev community of around, like, 2000 people.
But from a marketing standpoint, like, doing marketing on those platforms is extremely hard because anything ingenuine, anything that feels mildly promotional gets bashed. And then, like, you make one mistake and you're literally out of the game.
So can you, like, give some advice based on, like, how to communicate to these forums? Let's say you have a product that you want to, like, promote—it fits well with, like, what's the topic—but you don't want to sound that overly promotional. Can you give us some pointers?
Meg: Yeah, it's a great question. I think on some platforms, ads can work really well if they're relevant ads in-stream, you know, where somebody is reading about something that's related to your product. I think those ads can work really well. Reddit ads work really well for developer.
The other thing I would say is if people are talking about your product, and maybe asking questions about your product, you can absolutely jump in, be straightforward and honest and be like, “Hey, I happen to be a developer or the founder at XYZ, and, you know, here’s the answer to your question.”
And maybe the question is like, “I wish they'd add XYZ into the roadmap,” and you might come in and say, “Hey, we don't have an exact timeline for that, but it is on our minds and we really appreciate you sharing that feedback.” I think that kind of thing comes across authentic. It doesn't feel like marketing, but it is marketing in the sense that you're demonstrating that you care about your audience and that you're trying to be helpful.
You can also answer just questions when somebody's like, you know, “I don't know how to do this with the product.” You can answer those questions.
I don't think you should send marketers—even your really good technical marketers—unless they are former developers. If they're like truly dev rel folks, you can have them get involved in communities, but usually it's better for one of your engineers who's a good communicator, or one of your founders, if you're smaller, to be the one who gets in there and responds within communities.
I don't really recommend, like, if somebody's saying, “What's the best product for XYZ?” that you go in and say, “Hey, I happen to run this and I think it's the best.” Like—don't do that. Don’t do that.
Let people bring it up organically, and once it's been brought up organically, you can get involved in those conversations. But again, just like, be straightforward.
Do not bullshit devs. Do not over-exaggerate things your product can do. Don’t promise things that aren’t on the roadmap. Just be straight with devs because they—they don’t like it when you mislead them.
Patrick: I was just gonna add a comment there. In the past, what I've done—so if there's ever an opportunity to talk about one of my products—I will bring it up. But I will also say, like, “I created this, I think it's really good. But there's also 1, 2, 3 alternatives.”
And there's something about that with developers where if you just, like, if you just acknowledge that there are other options—even that, even that little thing—really helps with just communicating with developers.
Forget marketing hype. If you can’t prove it, developers won’t believe it. Meg shares how data, real examples, and even embedding your flaws can build way more credibility than polls claims ever will.
So Meg, I'd love to ask about hard data and numbers—and I have a recent experience myself. I just made some engineering changes on a website I was working on, you know, and it like reduced the average memory load from 64 megabytes to fifty—what—minutes? Something like this. And I got so much engagement on this post.
And I got so much feedback from the parent company. Is there something magical about talking about statistics and facts and figures and hard data with technical audiences?
And should you try to include it?
Meg: Yes. I wouldn't say there's something magical about data itself, but there is something magical about proof for developers, right?
They don't want to hear, "This works really well," or, "This is best-in-class," or, "It's the best in the market." That might work on a marketer or a CEO or something, but it's not going to work on a developer.
They need you to show, not tell. They're not going to believe your claims unless there's something to back it up. And that something could be data—and very often is data—especially if it's data that demonstrates how it's going to make their lives and jobs easier.
And I think there's a lot of ways to use data to reach developers more effectively. If you have proprietary data coming out of product usage—so this is a real example—but one of my clients was able to say, "Developers using our tool are able to complete a task that used to take them three days in 30 minutes."
Like that's—I mean, that's huge. That's game-changing for a developer.
I think the other thing you can do is use data to illustrate the problem you're solving for developers, especially if you're kind of on the cutting edge of solving a problem that maybe they haven't fully conceptualized for themselves or that they've just kind of accepted as part of the way things are. So they're just like, "Yeah, okay, that's a really annoying part of my job, but it's not something that can be fixed."
But you're there to fix it. You may have to define the problem for them, and data can be really helpful there.
So a good example here, again, is Snyk. You know, they run these reports about the state of open source security.
So how much of the open source code that's out there on the internet that developers are using right now has bugs and flaws and security issues in it? And when you can show that to a dev, and they're like, "Oh crap, like, I'm probably pulling insecure open source code and I don't even know it," that's going to illustrate the problem for them in a way that makes them go, "Yeah, we should probably do something about this."
The other thing I'll say is, you know, if you don't have proprietary data, surveys and research work really well also for developers. So especially if you're, you know, surveying other developers about what they're doing, what kinds of tools they're using—they really want to know what the cutting edge is and what they should be doing, what the best practices are.
And the good news is it used to be so expensive to run a survey, and these days you can do it for a few grand very effectively. You sized audience sample, it’s very relevant to your target audience.
Meg: So yes, to answer your question simply, I don't think it's just data, but it is all about proof. It is about showing, not telling.
Patrick: I love that. The perfect word for that is proof. Because I think, right, anytime you use flowery language with a developer, they kind of don't believe you. And then as soon as you say, "We developed this thing, it reduced our hard drive capacity from 300 gigabytes to 200," like, they're, "Oh, cool, there's a real example. I believe it now." There is something—that proof is evidence that backs up all your language.
Goran: I can follow up on that if it's easier. So it's interesting that you say that like data is not the actual thing—it's proof, right? But obviously, you know, channeling that proof is often a lot harder than people think, especially if you're trying to like convey the message on different platforms.
So we said that devs prefer, yeah, you know, reading long form reports, but they are also on social media, they are also on like forums and so on. So it doesn't really make sense to just like blast a monster message on a forum and just like expect people to read like 10k words. So how does that—like does the proof that you have—influence the channel you are going to use it in and how you're going to utilize it? I know that everyone uses [channels] differently, but how [do] different channels play [into] utilizing content?
Meg: It's worth saying that marketers can only do so much, right? So you're—hopefully you're doing some type of product-led growth and you are doing the best you can to build the most amazing products out there. And you're getting in communities, you're having positive word of mouth because the product is that great.
That's, I think, [one of the] ways to communicate proof around your product in communities—being really involved and answering questions honestly and pointing people to useful resources, including like, you know, somebody asks a question about like, "Okay, I'm trying to use the product to do XYZ," and it might be an appropriate place for you to be like, "Hey, like, we had a customer do a similar thing, and here's a case study we wrote with them."
Devs don't always love case studies, but if they are focused on a developer use case and there is data and social proof and quotes from other engineers, they do tend to respond well to that.
I also think, again, if you're running ads on a community-driven site like Reddit, those ads can lean on data. So, you know, you could use that: "Devs using our tool save on average two and a half days of time doing XYZ workflow." That can be pretty effective.
The other thing I would say in terms of using data—you know, long form reports that are data-driven, again, are really effective. And I think there's lots of ways you can—well, whenever I'm working with a company on their website, especially on their homepage, you know, we do a lot of website copywriting. I recently helped Snyk rewrite their website.
We went really heavy on: What are the different types of proof and social signals that we can include on the website that will demonstrate authority, credibility, and peer recognition?
So there's a lot of ways you can do that. You know, you can have an embedded video of a developer customer talking about how they use and love your product. You can have stats on there. You can have just, you know, scrolling logos from companies the developers are likely to be like, "OK, well, if MongoDB uses your product, then I should probably consider your product."
There's a ton of different ways that you can communicate that value in different formats.
Goran: But still, like the message is to kind of keep it, you know, keep it casual and like facilitate where you can based on the conversation.
Meg: Yeah, definitely.
Patrick: Let me ask—so we usually ask about things to do. Let me ask about, I just had this idea, this question. Let me ask about something you might not want to do. So my perspective is a lot of businesses treat their email list as: You just keep hitting your email list until someone buys. It's very repetitive and it's very sale-focused. Nothing wrong with that. It's a magical sales tool. But I almost wonder if there should be a carve-out on email lists where it's like: email everyone but anyone tagged with 'developer.' Just like, I feel like that should be—I feel like that should be a business practice because it's like these people are allergic to BS and fluffy language. And if you—and eventually, you will hit them with too much fluffy language.
I unsubscribe ruthlessly, whereas if you send me a product email once a quarter, once every six months about all the features you added to a favorite tool I use, I'm probably going to stay on your list.
So anyway, sorry, that was me answering my own question.
But do you have any perspective on that? Are there things you shouldn't do that you do with the typical audience, like hit them all the time on an email list, that you definitely shouldn't do with developers?
Meg: Yeah, I mean, email is such an interesting channel, right? Everybody's always talking about email's dead. Email's not dead. It's probably the most valuable owned content you'll ever have.
But you have to use it really intelligently, especially for devs.
I absolutely agree. We—you should segment your audiences. I think it should go beyond just separating devs from everyone else. But I do think there are some things that are unique to devs. Don't waste a bunch of time on like the design of your emails and stuff like that.
They actually don't like that. They just want text-based emails. They want them to be short, and they want them to be helpful. So a good example: I was reading a blog post the other day about like how to make a welcome email good for a developer. And it looks really different from how a welcome email should look for like a marketer getting started with, you know, whatever, a new CRM system.
For a dev, it should be like: "Hey, so just saw you signed up. So excited to have you in the community. Shout if you need anything." And maybe a link to one part of your docs or a blog post about getting started or a quick-hit video about getting started—something like that. It should come from a founder or somebody technical on the team. It should sound really conversational and simple.
And then your follow-ups should be like: "Hey, how's it going using the product?" Don't push the sales, but like, you know, make yourself available. Make it clear that you're responsive. So if they do want to talk to sales, ideally like a sales engineer or somebody who can speak in their language, that's easy for them to do.
And then I agree with you: like, think really carefully about the content of other types of emails that you're going to send to them. Don't send them all your marketing emails.
But do send them things like product updates that, again, like, you know, the CEO or CTO, who might be the buyer, they really don’t want those, but your devs, they want them for sure.
Patrick: Love it. I was just jotting, you're giving me a lot of... you're prompting a lot of questions, which I think is a good thing here.
So I've done a lot of stuff with SEO, and I feel like nowadays, SEO is very much geared towards learning and is very entry-level and basic. And I just feel like, yeah, I guess I'm wondering, are there dis-synergies with SEO and technical content? It feels like you can kind of only go for one or the other.
Like, if you write a really technical article, you probably aren't going to rank super well. That would just be my hypothesis. Do you have any thoughts?
Meg: Well, okay. I have to say, like, in general right now, I think companies' SEO strategies to date have often, at least at the foundational level, focused on 101-level types of content.
So, what is this? What is that? How did you XYZ? Blah, blah, blah—like, very simple things that, sure, your brand could write that, but so could all of your competitors. There's nothing unique or differentiated about that.
We are already at a point where AI answers 99% of those questions.
Stop using that for SEO. It's not going to work anymore. It's a waste of your time. And don't even do like programmatic SEO around it because that type of content is just garbage. It's just a waste of everyone's time.
I don't think SEO is dead for devs at all. I do think often marketers, just because we're so rough and held to pretty intense standards in terms of, you know, traffic and all these data points that indicate our marketing is being successful, we can sometimes get a little too obsessed with, like, how much traffic does this particular key phrase have?
And it might be something really long tail, and you're only anticipating like 50 people are going to care and come to your website.
But if it's properly tailored to what your brand does, and it's something unique to what your brand does, and the person who authored it is super credible and well-known, those 50 people are probably way more valuable to you than the 5,000 people or 50,000 people who might come read something that's like, what is a container?
But those are not the people who are going to buy from you. Those are, yeah.
Patrick: I have a particular case study with that, and then I'll let you go to Goran. When I was working at WooThemes, I think we had one of the things we uncovered was something like—it was a very high number. I'm going to say roughly around 2/3 of the people that bought had previously read at least one article of documentation on our website. So like at least 2/3. So while the documentation seems very boring, and how many people are going to Google—and again, 10 years ago, you know, how to install Stripe on WooCommerce, again—
The number of people that read at least one doc before purchasing was like at least 66%. Yeah, I bet it's higher. So I guess that it just makes it, it feels true with what you just said. Goran, did you have a follow-up?
Goran: Yeah, I mean, it's great that we kind of brought the whole SEO story up again, because I don't know if you've been following lately, but some of the biggest players, I won't name them, have been taking massive hits in traffic. These are known for top-of-the-funnel content that is just extremely surface-level.
And I completely agree that if you want to bring someone in who is a developer and actually make a connection, you have to offer them something that will make their lives better and add value.
So, based on everything we've discussed today, if there's one person watching this who is not a technical person or targeting a technical audience, what can they take from this episode and apply to their own marketing?
Meg: I think just like when we talk about how developers have unique language that they speak, places they hang out online, types of content they want to consume and don’t want to consume, messages that resonate and don’t resonate, it’s really the same thing with any audience. It’s a tenant that’s been around forever in marketing, but I rarely encounter a company that has done enough customer research, in my opinion. So, the better you understand...
The better you understand how your audience likes to consume content, what types of content they like to consume, the more successful you're going to be. And the less resources you’re going to waste trying to be everywhere for everyone. It lets you be more tailored. And if you don’t have infinite resources, that’s really important when it comes to marketing.
Patrick: So, we’re getting near the end here, Meg. I wish I could chat with you for another hour, but I unfortunately don’t have the time. I guess let me just sort of wrap it up with, like, there’s a lot of businesses that I don’t think invest enough into technical content, you know, writing content for these people.
What is, you know, what I guess, what is the one thing you would suggest someone who doesn’t have a lot of budget does? What is the one thing so that they can stand out and take advantage of this strategy? Like, what is the one thing they can do?
Meg: So, what I would recommend is to pick one channel and start there. Don’t try to boil the ocean and be everywhere all at once. I think that’s the biggest mistake I see. So, in general, I would say that when you’re focusing on technical audiences, you probably want to start with an engineering blog.
And then you want to figure out a publishing cadence that you can commit to and sustain. You want to build out an editorial calendar for the next three to six months so that you know what you’re going to cover and you can plan ahead. That’s going to let you be a lot more efficient. And then once you get good at that and you kind of get into a rhythm with that, you’re going to have a lot of content on there that you can take and repurpose on other channels in other formats. You can combine them into an e-book. You can atomize them into social posts. There’s a lot of ways you can reuse and recycle that content. But...
And it doesn’t have to be an engineering blog. That’s just an example of where I would often steer technical clients. But pick a channel, do it well, make sure it’s sustainable. Once you’ve done that, then think about how you want to expand.
Patrick: Love it. Perfect. Meg, it's been really great to have you on the show.
Meg: Thank you so much for having me. This has been such a fun conversation.
Patrick: And thanks to our listeners for tuning in. If you enjoyed this episode, like, subscribe, and tell your friends so we can carry on enticing awesome and influential guests to join us and share their remarkable journeys. If you subscribe through the plugin.fm website, you will get early board access to our future content. plugin.fm is brought to you by Freemius, your all-in-one payment, subscription, and taxes platform for selling software plugins, themes, and software as a service. If you're struggling to grow your software revenue, send a note to contact@freemius.com to get free advice from Freemius' monetization experts. My name is Patrick Rauland, and thanks for listening to plugin.fm.