← Previous · All Episodes · Next →
Developer copywriting mistakes to avoid, with Zach Goldie Episode 60

Developer copywriting mistakes to avoid, with Zach Goldie

· 37:26

|
Zach Goldie:

Like everyone says ship code fast, Dave. It's empty. It's an empty statement. It's like the aim of every dev tool pretty much is to help you ship code faster. You haven't told me anything about your tool at this point.

Jack Bridger:

Hi, everyone. You're listening to scaling DevTools. We're joined today by Zach Goldie, who is a DevTools messaging consultant. Welcome, Zach.

Zach Goldie:

Hey, Zach. Good to be here. Thanks for inviting me.

Jack Bridger:

I wanna dive straight in to something that I find really interesting. We've had, Superbase on the podcast before a couple of times, actually.

Zach Goldie:

Mhmm.

Jack Bridger:

And one of the things that they shared was that in the early days, they were marketing themselves as real time Postgres, and things weren't, like, taking off. And then at some point, they kind of they on a on a whim, they rebranded as, like Mhmm. Open source Firebase alternative. And their whole trajectory just changed, and I think it was kind of the turning point for them. And you're an expert in this kinda area, And I wanted to hear why do you think that that worked.

Zach Goldie:

Yeah. Yeah. That was I listened to that episode, and it was definitely a fun little bit because especially, they are talking about, like, finding product market fit and how when it clicks, things do often suddenly take off. But I think it was my suspicion. Most of the way I've heard people talk about product market fit is often in terms of kind of the feature set and the core, like, functionality of the product itself.

Zach Goldie:

Whereas this was more about what I think of a bit more as kind of the message market fit or positioning fit, where even though the product was the same, just the way that they talked about it clicked more with people even though it's the same features, which is always a hard one to do. And, like, there's no, like I'm never gonna pretend, like, here's the one way to do a thing, because life's never that simple, especially in marketing. So the sounds of it is you often hear about kind of you heard about pain points and kind of people's struggles where there's definitely different like, what's the word? Different, like, levels of pain that someone can feel about an issue. There's some things that we're, like, even that we're aware of, but they're not enough of a fuss to be a priority.

Zach Goldie:

We all have those kind of that sore whatever body part. We're like, oh, maybe we should go to the doctor and get it checked out, but life's busy and I can't be bothered right now. It's like even though we're aware of it and we know it's kind of bothering us, we don't care enough to fix it. And we've kind of real time was it real time progress? Maybe.

Zach Goldie:

You know, it's like, yeah. Maybe we could use that to build this feature that we kind of had in mind, but then I'd have to learn this whole, like, new bundle of stuff. And, like, it's not enough of an issue for people to go, yes. That's what I need. Especially if it ties into I don't know that area well enough, whether they were already kind of free open source kind of whatever off the shelf things that people would be like, I'll just use that to get started.

Zach Goldie:

That will do for now. So it's kind of, are there already free options that we're doing that? There's might be better than the free options, but maybe people didn't care enough to upgrade, which is a thing I see quite a lot is that, like, you are competing a lot of the time against a free version. Yeah. So is that whereas the con the what is it?

Zach Goldie:

Open source Firebase alternative clearly just hit more of an active pain point that was frustrating people that was getting more of, like, a, oh, yeah. I really, like, need to make that change because it's having actual implications for me in the short term. So it was more of a high up the to do list, which I'd be curious what what made them decide on that path in general because I don't think they talked about that aspect of the story, but I think finding that, like, okay. People say that this is a nice tab, but it's not resonating with them that much. Maybe we need a dramatic change is just such a cool part of their story.

Jack Bridger:

Yeah. Yeah. Do you see a lot of companies that, like, kind of position themselves against, like, the big kind of player in the space?

Zach Goldie:

I think often websites often kind of, I think, in terms of even if you're not doing it intentionally, there's an inbuilt way that you are talking when you are coming up with your website, which I think a very common default in, like, b to b in general is to talk as if they're an eager first time buyer, as if they haven't used this kind of thing before, and they're definitely looking for a solution of the kind that you have, which is an easy trap to fall into. It's a bit of the kind of, selling the drill, not the whole kind of vibe. It's like, yes. Clearly, someone vaguely wants a hole already, and they're looking for a drill. It's like, I get that, but that's often not the case.

Zach Goldie:

It's more of a especially in things like dev tools. Maybe they've already got an old drill, and they're thinking of upgrading to a better one because the first one they bought was just like a cheap and cheerful one, which kind of can draw some holes. But now they're looking to, like, for whatever reason, drill through bloody titanium or something. So, actually, what you need to send us the ability to drill holes in new, tougher materials, which is a very different pitch. So, yeah, I think a lot of dev tools either pitch themselves as if they're a first time buyer looking, like, very much looking for a new solution or the set, like, similar, definitely looking for a new solution, but for probably using a competing software, like competing against Datadog of, like, oh, the cheaper alternative to Datadog.

Zach Goldie:

It's like a thing that I've definitely seen in places.

Jack Bridger:

Yeah. So where where would you start? Like, if you're if you're kind of like a dev tool and you've got, a message and maybe you've, like, you feel like you've kind of invented something new. I feel like there's a lot of the challenge comes because we're trying to, like, invent things. If you know it's not working Yes.

Jack Bridger:

How would you kind of go about landing on the right message?

Zach Goldie:

Yeah. So I've I've always viewed I think I'm weird in the marketing world, but I like the kind of puzzle aspect of I like the kind of think about the customer and what they're doing, what they've tried already, why it's failed, and then think about the product and kind of what does it do, how is it different. So I always start with that kind of customer side, which in particular, I think, in terms of kind of what's their current scenario of, like, how are they already tackling the projects? Like, are they often yeah. Are they using a free version way of doing the prob problem?

Zach Goldie:

Because if so, what's the issue? Often, you're not solving the end goal. I'm gonna stick with monitoring tools. So the monitoring tools, the end problem that you're solving isn't, like, spotting downtimes and, like, fixing those issues because they've already got a way of doing that. The problem is that their way of doing that kinda sucks or is expensive or is complicated.

Zach Goldie:

Like, the problem is often the way that they're solving the bigger problem.

Jack Bridger:

I see. So you're not trying to say, hey. We'll help you reduce downtime per se. We'll help you reduce downtime at a cost you can afford or, like, stop wasting money on

Zach Goldie:

Or we won't give you 1,000 dashboards that you don't know what to do with. Well, like, maybe it's that, like, their current main option is overpowered, and they don't like, I've seen some tools that aim to kind of fill that gap between the free version versus the overpowered enterprise version. So you can be like, look. We'll help you, like, upgrade from the free version, but without all the, like, costs and complications and needing a whole team just to use the, like, really expensive version.

Jack Bridger:

Yeah. That's actually a really, really valid point because I feel like a lot of us always want to feel like we are almost like the pioneers, and there are no other, like, you know, acceptable ways to solve this problem.

Zach Goldie:

Yeah. Especially, I think, a lot of dev tools are aiming to replace an existing step of workflow. A lot of the time, they're not doing something that's completely new, which is, like, completely valid. It's a better way to do your CI workflow. It's not, here's a whole new completely different way to deploy your code base.

Zach Goldie:

And even that would be replacing the old way of deploying your code.

Jack Bridger:

Yeah. That's, that make yeah. That makes sense. So let's say you kind of are figuring out, like, okay, the monitoring. So you're gonna yes.

Jack Bridger:

Then how would you think about how to kind of communicate that in a way that people would engage with? Mhmm. Firstly,

Zach Goldie:

there's always a, like a tricky challenge does often involve talking people like working out what is actually the headaches that they care about in terms of monitoring solutions in that case, what are the bits specifically that annoy them? Because there might be some things that bothered you, but not them. I think it's often the trap that people fall into. It's like, oh, yeah. This was really annoying me, and then they talk to other people.

Zach Goldie:

I saw a discussion recently of a dude who'd made, like you know, as a CI tool that was all about, like, reducing the time for all the tests to run and a bunch of responses on there that were just like, I'm quite happy having a 15 minute break while I saw my test runs. It gives me a chance to go get a coffee. And it's like, it kind of is a problem, but I think you needed to look at a different aspect of the area to be like, okay. This is the bit that we actually need to solve. So I'd always start there before looking at the okay.

Zach Goldie:

So go always more into the details of, say, okay. It's easy to use. Everyone says easy to use. It's one of my most hated phrases. It's either fast or easy to use or both.

Zach Goldie:

Like, I saw that was a good, like, meme on the programmer humor humor subreddit. It was, like, the Batman slap with Robin saying ship code faster and Batman being, like, a shut up, slap around the face because everyone says ship code faster. It's empty. It's It's an empty statement. It's like the aim of every dev tool pretty much is to help you ship code faster.

Zach Goldie:

Yeah. It's like so many b to b tools say, grow your revenue. It's like, that is the aim of literally essentially every b two b. Like, you haven't told me anything about your tool at this point. And, yeah, in the comments for that meme, there was lots of discussions about, like, the kind of what you say versus what people hear.

Zach Goldie:

It's like you say ship code faster, they hear caveat, caveat, caveat. It's like the in ads when you get the little asterisk of, like, terms can like, 80% sale or asterisk. Terms and conditions apply. Per customers must purchase at competing stores only and wearing 2 items of purple or whatever silly caveats are in there. Like, there's the developer equivalent of, like, yeah, easy to use caveat so long as you're using an ideal use case and have no conflicting dependencies or these kind of what actually gonna take a little breath.

Zach Goldie:

So I think at that point, it's okay. So, hopefully, you've got your pain points. There's the things that people care about and the aspects of your product that kind of match into that. Like, okay, part of it is that the free version doesn't scale well. It's like, okay, you can just say works at scale, but, like, what does that mean?

Zach Goldie:

How can you and I think there's a path there with, like, easy to use or scales or fast that people often, I think, write it and then instinctively maybe know it's not that convincing. And you've got 2, like, branches you can go down. The one that I think is more obvious but less effective is kind of hyping up the language, which is where you get these really fluffy statements. I've got So lightning fast.

Jack Bridger:

Yeah. Oh, there's

Zach Goldie:

I should really stop, like, dissing on Circle or CI on one of their pages, have the phrase, what is it, deploy at the speed of creativity. Oh, yeah. I saw that. Guys, that's what, like and I think that comes from the sense of knowing that what you've written isn't that compelling. So one kind of solution is to add some, like, more exciting language about it or explaining why that's a good thing.

Zach Goldie:

I think you have to get the, like, saves you time, and therefore, you have more time to ship ship features, not fix whatever. Like, I've seen the so you have more time to ship features as quite a big one. It's like, that's explaining the obvious, guys. Yeah. So I think there's a big thing about overexplaining the bits that are actually obvious versus under explaining that, how does it help you save time?

Zach Goldie:

Like, what steps does it actually let you skip? Like, we've got API, where they're all about API integration. It's like it's not just it's faster. It lets you skip. Like, so you no longer have to get lost in or is it kind of error handling and rate limiting and all of these kind of aspects?

Zach Goldie:

It's like, pull out the details of how it's faster, not try and explain why faster is good. Yeah. Which possibly sounds obvious once I say it, but I see that trap all the time.

Jack Bridger:

Yeah. Because it's not that saying fast is bad because, like, for example, I see, like, bun. Have you seen bun.sh? They're, like, kind of rebuilding, I've not used it, but I think it's, like, kind of a, you know, alternative to using Node, essentially. Mhmm.

Jack Bridger:

But, like, everything is faster, and it seems like almost all of their marketing is essentially Jared, the founder, like, demonstrating, like, what features he what clever, like, tricks he's written into the code that make make it run way faster, and how fast you can write tests and stuff. Mhmm. And it seems to be really popular, that kind

Zach Goldie:

of stuff. That's good. Yeah. It's always nice to see those evidence. And even evidence is a tricky one.

Zach Goldie:

Like, that circle CI thing that I rip on has a little speed comparison of, like, running a build on them versus other things. But I'm like, you could be like, oh, well, that was probably just like a onetime use case that was probably tuned to their system, and it's like it wasn't averaged over a 100 different users self reporting, blah, blah, blah. It's like, even there, like, providing evidence to get past that skepticism is kind of hard.

Jack Bridger:

Yeah. How do you do that?

Zach Goldie:

I mean, that's on the case by case basis. It's kind of it will be how well could you prove that it's not just in, like, you cherry picking data, or what details can you give to say that, like, maybe it's written on a faster language or something or in a different way or got more of this, that, or the other. Sometimes competing on specs is valid. If your yours just is more powerful because x y zed, you can say so. Like, it's a little bit of a hard one to give a blanket statement, but it's what I often end up doing a lot of.

Zach Goldie:

It's like going through, like, articles technical articles of clients written, like, written, go through maybe if they've had, like, YouTube webinar, whatever, isn't they've, like, talked it through in a more natural way? What do they mention that makes it faster or better or easier or, like, scale better? Kind of pick through those details of exactly why it does the claim that you say it's doing.

Jack Bridger:

Yeah. This seems like these are kind of hard things. Like, when I've been working on, like, a landing page for ideas, it's so easy to get caught in that trap of, like, fast Yeah. Built by developers, for developers, stuff like

Zach Goldie:

meaningless things. This Yeah. I think curse of knowledge comes into play quite a lot if you've heard of that concept.

Jack Bridger:

No. Curse

Zach Goldie:

of knowledge. I came across this in I think it was Made to Stick by Chip and Dan Heath was the book where they talk about when you know what you're talking about, you can say a statement, and you, like, have the unsaid paragraphs of information behind it. Like, I can say, I help my clients create pages that are more relevant to their readers. And I know what I mean by that, but that can mean a whole load of things to the other person and what they interpret that to mean and can mean a lot of confusion. Like, what do you mean by more relevant?

Zach Goldie:

Do you mean the sort of, like, personalize their names in there? Or it can, yeah, be interpreted in a 100 different ways. Because I knew what I meant by that, like, short phrase, but the other person doesn't. Yeah. And that comes into play a lot where it's like, oh, yeah, scales more easily.

Zach Goldie:

It's like, you know what you mean by that and why it scales more easily and everything else, but the reader doesn't, especially when you start adding slightly fuzzy words such as developer experience in there. Although it improves developer experience, it's like, in what way? That's quite a big topic.

Jack Bridger:

Yeah. So if someone was, kind of working on, like, a landing page, and they had a very short amount of time, so you mentioned, like, going to speak to someone, speak to, like, customers and try and

Zach Goldie:

Mhmm.

Jack Bridger:

Obviously find something that seems to actually be important. But assuming they kinda have done that, like, how how is there are there any kind of, like, sort of things that you'd recommend just, like, working through or, like, is it really case by case?

Zach Goldie:

No. There's definitely I do have a whole like, gonna slightly plug. I have a whole, like, messaging guide on my site that people can go read that kinda walks through this in a not too long a format. So, yeah, a lot of the time, the people I talk to, the clients, do know enough about their customers. It's just that they haven't kind of pulled out and formatted the information the right way.

Zach Goldie:

So, like, talking to new people always isn't that necessary. I'd always start with that like, okay, sit and think about the user. Your ideal people were like, what are they using already? What are they annoyed about? If they've tried something and it failed them, and now they might be skeptical about a new version that claims to do the same thing, why would, like because that's a whole, like, getting around that jadedness.

Zach Goldie:

How do you get past that? I think thinking about oh, like, take a while to think about the objections people might have. Like, why might they go, that sounds good, but, like, why might they doubt you and how if you were talking to them face to face, like, pretend you were just talking to them, forget about writing website for a while. If they were to be like, yeah. But how does or what does it do in this use case?

Zach Goldie:

Or what about if you I need to integrate it with? Like, think about all the ways that someone might be like, yeah. But and what you would answer to each of those. Then go from there into the, like, okay. So what are, like, key, like, problem solution pairings, and what are the issue, and how do I solve it?

Zach Goldie:

I tell people I find think it's quite a big challenge, but it's an obvious and easy thing to do of when writing website content, you're essentially doing 2 things at once. Because there's 2 stages in my head of theirs, deciding what to write about and how to write it. I'm pointing at my fingers, so everyone in the podcast can't see me doing that. But I

Jack Bridger:

Yep. I shouldn't write. So

Zach Goldie:

I think that's very hard to do both of those things at once. I would always say I can't do this on a screen. I have to do it still on pen and paper. I'll sit there and jot out key points, and then, like, they'll kind of then a few subpoints for each one of, like, what are the like, what's the evidence or the detail that would support that point of, like, here's a claim, and here's the evidence evidence to reinforce it.

Jack Bridger:

And that's the that's the what you would write about?

Zach Goldie:

Yes. That becomes the the claims essentially become the sub subheadings of, like, each section down the site, and the content becomes the evidence for that claim. I think Austro becomes a bit con if you're skipping that step, I think one thing I see on a lot of websites is you'll get a subheading and then one sentence that's relevant to that sub subheading and then a second little paragraph that's actually about something different that they didn't have space to mention anywhere else, so they're just gonna mention it here.

Jack Bridger:

Is that bad?

Zach Goldie:

It's not ideal. It becomes a bit of a their aim should be that people can get the general idea by getting the sub by just skimming the subheadings. I think it also makes it I've got a little gripe about, like, copy length and word count where people worry about too many words. But firstly, people like, developers will read several 1,000 word articles about 1 niche little coding, whatever, like, tiny thing. Like, people do read if it's interesting to them.

Zach Goldie:

Yep. There's a good, what's the name? There was a film critic, Roger Ebert Egbert, something like that, who has a quote about no good movie is too long and no bad movie is too short. It's like it's like the issue isn't just the amount of words on the page. It's is it engaging and relevant?

Zach Goldie:

Yeah. Like, as soon as something becomes a bit fluffy or you get a bit lost of, like, how these points relate to each of them, it's darting all over the place, you start skimming. Because why do you not start skimming at that point? And as soon as you've, like, hit that fluff trap, you've essentially lost them no matter how short the rest of the pages.

Jack Bridger:

Yeah. That's actually such a good point. I feel like so much of it is, like, laziness. Like, when someone reviews when someone first looks at, like, a site you made, landing page Mhmm. A lot of the feedback you get, they're like, what's this?

Jack Bridger:

And then half the time, I'm like, oh, well, I couldn't really think of anything to write, so I just put something in there. Yeah. I definitely don't stand by this statement.

Zach Goldie:

That's fair. And I kinda get similar things sometimes. I'm like, I feel like I need a second point to support that statement just because otherwise that section will look too short. And I kind of sit down like, okay. But what would actually be relevant?

Zach Goldie:

How can I expand this in a way that is meaningful? Like, I kind of get close to that myself. I'm like, I think this just needs a little bit of extra text or a little less extra. How can I cut it down without making it just seem a bit fluffy? Kind of hitting that balance is a tricky one.

Jack Bridger:

Yeah. This is really good. So and that is kind of so you would start with that as the what. Mhmm. And what what is the how then?

Zach Goldie:

The how, partly a matter of practice. Partly, there's a lot of don't try to sound like a marketer, which sounds obvious because I don't think anyone does. But there's a lot of how would you describe it to a person, like, if you were talking across the table to someone. Like, imagine you were just writing it out as you were talking to someone in your head. What would you be writing?

Zach Goldie:

You probably wouldn't write the kind of sales style hyped up, like, slightly empty claims because you know you would sound like a tool. So I'd always and I think that's why kind of the business casual style of writing has propagated quite heavily across all of the SaaS SaaS market even outside of dev tools because it's just like business speakers annoying. So I'd always think about that. I would always think about how much do I need to pitch, like, the feature versus the benefit? Will it be obvious if I just say it does this?

Zach Goldie:

Why that's a good thing? Do I need to explain why that's a good thing or not? Which yeah. I think you've already discussed the article. Yeah.

Zach Goldie:

Do you need to point out why the good thing is a good thing or not? There's always a big one. And if yes, do you need to, like, go up a lane in terms of abstraction? Do you need to at the ground, well, it was to do, like, git hooks. And it was like, oh, yeah.

Zach Goldie:

We have automatic git hooks or something along those lines. And that was fine, but it wasn't obvious. That was one of the actually more unusual cases of, like, there wasn't obvious why that's useful. They had to, like, point out that it meant that you could, like, force your team to run local tests before deploying or something along those lines. It's like sometimes if that's more on a feature by feature base, is it innovative enough that you'd need to point out the point of the feature?

Zach Goldie:

If not, can you just say some stats about it And people will go, oh, it lets you, like, not have to do this thing that I hate doing. You don't have to say why not doing the thing is good.

Jack Bridger:

Yeah. And do you think about a specific person when you're doing this? Like, when you say, like, oh, it's it's it's obvious or it's not obvious. I guess that kind of slightly depends, like, who you're talking to as well.

Zach Goldie:

Yeah. It will depend a bit on I think that comes back a bit. Are you aiming for users already using an existing tool or someone trying it for the first time? Because someone who's already using a competing tool might have come up against the bad version of this feature and know why it's annoying versus someone who hasn't used, like, a feature of that style might not know really the point of it. So it will depend a bit on your target audience.

Zach Goldie:

I don't think of, like, an an individual, like, person sitting across from me, but I have that kind of level of familiarity in mind.

Jack Bridger:

That makes sense. Are there any kind of, like, examples where like, of dev tools that have just, like, really good, copy pages that you would recommend, especially if it's, like, for a start up, so not like, you know, huge company where they have, like, a gazillion different product lines and stuff.

Zach Goldie:

I feel like I should know some examples off the top of my head, but I don't, unfortunately. Like Yeah. Yeah. There's I've definitely seen a lot. I just don't always remember the name of them, which is quite annoying now.

Zach Goldie:

I think it's hard to know because it's hard to know without the context, partly because

Jack Bridger:

I am

Zach Goldie:

not a developer. So a lot of the time when they say, oh, it does this thing, As an outsider, I'm like, that sounds cool, but it's only when then, like, talking to the clients that I am able to realize why it's good or bad. Yeah.

Jack Bridger:

That's actually interesting. So it's not inherent, the obvious.

Zach Goldie:

Yeah. Like, you can write copy that sounds good, and there's generally I guess that's 2 facts of it. Is it, like, well written and generally kind of does well in the whole, like, balancing product versus features versus is it well targeted in its pitch is a different layer. Like, it's hard to know, are these problems that you're addressing actually problems that people care about? Yeah.

Zach Goldie:

Because even yeah. Especially not as a developer. Some it's hard to know without talking to, like, the developers who made it. Some might be obvious to other developers where you're like, oh, yeah. It says it does this, but I don't care about saving 15 minutes off my CI time.

Zach Goldie:

Why are you talking about this? So, yeah, I think the question to me is more the priority of is it matching the pain points and the priorities of people versus I kind of see words as a delivery mechanism. Like, the words are there only to deliver that, like, general high level pitch. Yeah. I don't care too much about them being, like, nicely written with good grammar or anything else.

Jack Bridger:

That that doesn't matter that much

Zach Goldie:

compared to That's the icing on the cake. That's the line I check to clients. That's like the last 10% I do is the actual words themselves.

Jack Bridger:

Yeah. That that makes sense. How do you know if it's if it's good?

Zach Goldie:

That's always a tough one. I love a good AB test even though they have their limitations. It's always satisfying to hear that kind of it's doubled conversions versus the old version of the page or something along those lines. Is probably just the main key one. You can't really know without testing.

Zach Goldie:

I haven't got that far into doing user testing, but it is an area that I'm interested in. There's various, like, b to b website review services where they'll make a panel to kind of feedback on the site, which is quite cool. I've done that just a little bit, and it's quite nice to hear people go, oh, yeah. That is kind of a thing that we struggle with. But even that does have its limitations of people aren't very good at saying why they don't like a thing.

Zach Goldie:

Yeah. People I like using music as an example of, like, I can play you a band that are kind of decent, but not that great. And you'll know they're decent, but not that great. But unless you're also a musician, it's hard to actually pinpoint why. You might be able to be like, well, the singer's a bit out of tune or whatever.

Zach Goldie:

But even then, maybe they are in tune. It's just like unless you know about things like phrasing, you might not know that it's because the drum is going let's say it's and it's making the whole thing drag. Like, you'll know if something's good or bad, but not why, and I think that applies to websites as well. Like, a lot of the time people will be like, it's too expensive. I don't want to buy it.

Zach Goldie:

But what they actually mean is they don't really understand the point of it or why it's worth buying, which isn't the same as it's being too expensive. Yeah. Which is a thing that was actually a case with like a very old client who did their online guitar course, but he kept getting the feedback of it's too expensive. I'm like, I don't think it is. I think it's just not very like pitched very well or like it hasn't really shown why it's worth buying.

Zach Goldie:

And without dropping the price, we rewrote the page and, like, yeah, sales, like, shot up from weekly to daily or something along those lines. Yeah. So, like, the feedback was kind of valid and that it wasn't hitting the spots and people knew that. But in the way that it yeah. Like, the details around that weren't quite right.

Jack Bridger:

Is that kind of just like an argument as a start up? Like, where, like, barely anyone's using you of just, like, trying loads of different stuff until it's so obvious that it's right that you've that it's better than, you know, like, you make like, with SuperBase, like, I don't know if they did an AB test. They probably wouldn't have had to do an AB test by the sounds of it where, like, suddenly everyone just start it is, like, very obvious that Yeah.

Zach Goldie:

It's a lot better. I think definitely just do a straight swap if you've got low traffic because you've kinda got nothing to lose at that point. Like, you're aiming for a big enough change that it should be hopefully obvious. Yeah. And even people who, like, may their whole careers about AB testing will say, yeah, if you're getting only a few conversions a month, don't bother doing an AB test because it'll take you 6 months to get a statistically significant, like, result.

Jack Bridger:

Yeah. So just throw stuff at the wall. So essentially and try.

Zach Goldie:

Talk to people. I think that's a danger of self serve stuff is that you're not talking to people even if it's, like, as a customer support thing. And I think people can do market research without pitching it as market research. There's a difference between, like, hey. Can I talk to you on a call so I can learn about your needs?

Zach Goldie:

Versus just being like, hey. Like, more pitching it as a support call. I want to help you make sure you're, like, you're using the setup correctly and do some small talk at the beginning. Like, it's fairly natural to, like, oh, so why, like, I I'm curious about, like, why you started using this and what you were doing before. Like, that's kind of just natural small talk before a support call.

Zach Goldie:

So do, like, onboarding, free onboarding, even though it's not scalable, just so that you can have that chitchat at the start. And do that bit of small talk like, so what were you using beforehand? Like, I'm curious why you picked this one over the other, and that's just being friendly.

Jack Bridger:

I think that's a really, really crucial point. I have not seen many companies do this. I've seen Zoopla. We've had them on the podcast, and they did us I was trying out their tool, and they they did an onboarding call with me. And I don't remember whether they asked me, like, those kind of questions, but it was great from my perspective.

Jack Bridger:

But if they'd have said, can I do a quest you know, like

Zach Goldie:

Market research call kind of thing? No bugger off. Why would I wanna do that? Even if you offered me a $50 Amazon voucher, which is

Jack Bridger:

Yeah. Kinda certainly changes the dynamic because it's like, oh, actually having a call with someone who's very knowledgeable on this space, especially because it was the founder of the early stage companies. Right?

Zach Goldie:

Yeah. How can you make it sound like a good deal for them, not for you, not just for you?

Jack Bridger:

Yeah. Zach, if there was, one thing that you would advise, early stage dev tools to be doing or not doing, what would it be?

Zach Goldie:

Think about your ideal user's current scenario. Like, that's the number one thing of, like, what are they using already? How much does it bother them? Why does it bother them? Doesn't it?

Zach Goldie:

Like, what aspects do they care about? Are they are they even aware that, like, security is quite common? Like, do they even know that they have an issue that could be fixed? Like, do they know that their website is being probed by malicious people a 100 times a day? Because if not, you're gonna have to start it, like, highlighting that issue.

Zach Goldie:

Or have they written their offers, like, something that's just a bit inevitable that maybe they can't fix, and suddenly they'll be like, oh, wait. There is a solution. So, yeah, always think about your potential users. What are they using even if it's like, are they doing it manually? And they're kind of happy with that.

Zach Goldie:

Like, maybe they don't care about automating it, but maybe they do. Like, what's the change that you are suggesting, and how do you fit into that potential change? And pitch the upgrade if you need to pitch the upgrade. Don't pitch it as your yeah. There was one about keyboard SDKs recently where that was in the Slack group that were both in the DevRel Slack group where they were saying about was it in there?

Zach Goldie:

Maybe it was someone else saying about, like, new app builders aren't that bothered about using their keyboard SDK stuff because there's a free option. I was like, well, yeah, of course, they would use the free option, but then you could come in later and be like, okay. So now you're getting tired of the free option. Here's now what I should use a paid one, which is a completely different, like, pitch to, oh, yes. So you've started developing an app.

Zach Goldie:

Why you should use our keyboard?

Jack Bridger:

Yeah. So you're kind of acknowledging that there is a free Mhmm. Version.

Zach Goldie:

But Yeah.

Jack Bridger:

Why it's different.

Zach Goldie:

Yeah. Why is your version fixed and the problems of their current methodologies so often the pitch for dev tools?

Jack Bridger:

Yeah. Yeah. That's a really good one. Zach, thanks so much for joining.

Zach Goldie:

You're most welcome.

Jack Bridger:

Yeah. And thanks, everyone, for listening. If you're interested in learning more about Zach, I really recommend going to dxdot tips and reading Zach's recent article about benefits layers. It's a really good read about messaging on dev tools. Mhmm.

Jack Bridger:

And I think there's a link in there as well to Zach's page, where you can kind of reach out to him as well. It's very

Zach Goldie:

hard to find at zachgoldy.com. Zachgoldy.com. Yeah.

Jack Bridger:

Amazing. Thanks everyone for listening, and see you soon.

Zach Goldie:

Bye.

Jack Bridger:

Bye.

View episode details


Creators and Guests


Subscribe

Listen to Scaling DevTools using one of many popular podcasting apps or directories.

Apple Podcasts Spotify Overcast Pocket Casts Amazon Music YouTube
← Previous · All Episodes · Next →