Zach Goldie is a developer tools messaging consultant who works with founders on positioning and landing page copy.
We get into why Supabase's pivot from 'real-time Postgres' to 'open source Firebase alternative' worked, why competing against a free tool is a different pitch than competing against a paid one, the 'curse of knowledge' trap that makes founders write meaningless phrases like 'improves developer experience,' and why he thinks the actual words on a page are the last 10% of the job.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at [email protected].
Supabase's positioning shift from 'real-time Postgres' to 'open source Firebase alternative' seemed to change everything for them. Why do you think that worked?
Most of the way people talk about product-market fit is in terms of the core feature set. This was different — I think of it as message-market fit, or positioning fit — the product didn't change, just how they talked about it, and that's always a hard thing to pull off deliberately. My guess is 'real-time Postgres' described something people were aware of and mildly interested in, but not enough to act on — you have that sore body part you know you should get checked out but life's busy. Especially if there were already free or off-the-shelf ways to get something close to that, people didn't care enough to switch. 'Open-source Firebase alternative' clearly hit a much more active, higher-priority pain point — something with real short-term implications for people, not just a nice-to-have.
Do you see a lot of companies deliberately positioning against a big incumbent?
A very common default in B2B, even unintentionally, is writing as if your visitor is an eager first-time buyer who's never used anything like your category before and is actively hunting for a solution — it's the 'selling the drill, not the hole' trap, except worse, because usually they already own a drill. In dev tools specifically, people have often already got an old drill and are wondering whether to upgrade, or they're already using a competing tool and are looking for something better. You'll see both patterns: pitching as if to a total newcomer, or pitching directly against an existing competitor, like 'the cheaper alternative to Datadog.'
If you're building something genuinely new, where do you actually start figuring out the right message?
I always start with the customer side rather than the product: what's their current scenario, how are they already solving this, and why does that current solution actually fail them? A lot of the time you're not solving the end goal directly — sticking with monitoring tools as an example, the end goal, spotting downtime, is already being handled somehow. The real problem is that their current way of doing it sucks, or is expensive, or is overly complex. You're not pitching 'we'll reduce your downtime,' you're pitching 'we'll reduce downtime without the cost you're currently paying' or 'without the thousand dashboards you don't know what to do with.'
How do you find out which specific pain points people actually care about, versus what annoyed you personally?
There's a trap where something really bothered you, so you assume it bothers everyone — I saw a discussion about someone who built a CI tool focused on cutting test run time, and a bunch of replies were essentially 'I like having a 15-minute break to get coffee while tests run.' It is technically a problem, but you need to find the angle that's actually a priority for people, not just something that's technically true.
What's wrong with phrases like 'ship code faster' or 'easy to use'?
They're empty statements — helping you ship code faster is essentially the stated aim of every dev tool that exists, the same way 'grow your revenue' is the aim of basically every B2B product. You haven't told me anything about your specific tool by saying that. There's a meme about this exact thing on the programmer humor subreddit — Batman slapping Robin for saying 'ship code faster' — and the discussion under it was full of people pointing out the gap between what you say and what people actually hear, which by that point is just noise, like the fine print under a big flashy ad discount.
So if 'fast' and 'easy' don't work, what's the alternative?
There are two paths once you notice a claim like 'works at scale' isn't landing. The less effective one is hyping the language further — CircleCI has a line somewhere about deploying 'at the speed of creativity,' which usually signals the writer already sensed the underlying claim wasn't compelling and tried to compensate with flourish. The better path is pulling out the actual concrete detail behind the claim instead of explaining why the claim is good — don't tell me being fast means I have more time to ship features, that's explaining the obvious. Tell me specifically what steps I get to skip. If you're an API integration tool, the win isn't 'faster,' it's that you no longer have to hand-roll error handling and rate limiting yourself.
How do you get past skepticism when a tool genuinely is faster and you want to prove it with evidence?
It's very case by case, and even good evidence is often shaky — CircleCI has a build-speed comparison chart, but you could reasonably ask whether that was a cherry-picked one-off case rather than something averaged across real users. Sometimes competing directly on specs is genuinely valid if you can back it up. What I usually end up doing is going through a client's own technical articles, webinars, and customer conversations, wherever they've explained things in a more natural voice, and pulling out the specific mechanism behind why it's actually faster or easier, rather than just asserting it.
You've mentioned the 'curse of knowledge.' What does that mean for landing page copy specifically?
It's a concept from the book Made to Stick — when you deeply understand what you're talking about, a short phrase carries a whole paragraph of unsaid context in your own head that the reader doesn't have. I might say 'I help clients create pages that are more relevant to their readers,' and I know exactly what I mean, but that phrase could mean a hundred different things to someone else. The same happens constantly with phrases like 'scales more easily' or 'improves developer experience' — you know precisely what you mean by that, and the reader genuinely doesn't.
If someone only has a short amount of time to fix a landing page, what's a practical process to work through?
Most of the people I work with already know enough about their customers — they just haven't pulled that knowledge out and organized it properly. Start by really sitting with the user: what are they already using, what annoys them about it, and if they've tried something similar before and it failed them, why might they be skeptical of you claiming to solve the same thing? Try to genuinely think through the objections someone would raise if you were talking to them face to face, forgetting about the website for a moment — what would they push back with, and what's your actual answer to each one? That becomes your set of problem-solution pairings.
How does that translate into actually structuring a page?
Deciding what to write about and how to write it are two separate stages, and trying to do both at once is genuinely hard — I do this on pen and paper, not a screen. I jot down key claims, then subpoints under each one that are the actual evidence supporting that claim. Those claims become your subheadings, and the content underneath becomes the evidence for that specific claim — not a second, unrelated point crammed in because there was leftover space. A reader should be able to get the general idea just by skimming the subheadings alone.
Is there a real risk in writing too much copy on a page?
Word count itself isn't really the problem — developers will happily read a several-thousand-word article about one tiny niche coding detail if it's genuinely relevant to them. There's a quote, I think from the film critic Roger Ebert, that no good movie is too long and no bad movie is too short — length isn't the issue, engagement and relevance are. The moment content gets fluffy or the logic starts jumping around, people start skimming, and once you've hit that point you've lost them no matter how short the rest of the page is.
Once you've got the content nailed down, what does the 'how' — the actual writing style — look like?
Partly it's just practice, but a good starting heuristic is: don't try to sound like a marketer. Imagine describing it out loud to someone sitting across the table from you — you naturally wouldn't reach for hyped-up, slightly empty sales language, because you'd sound ridiculous saying it out loud. That's probably why business-casual writing has spread across the whole SaaS market, dev tools included — nobody likes 'business speak.' Beyond tone, there's a real judgment call about how much to explain a feature versus its benefit — sometimes the benefit is obvious once you state the feature, and over-explaining it is worse than saying nothing.
How do you actually know if a landing page is good once you've shipped it?
Honestly, that's always the hard part — I love a good A/B test, even with all its limitations, because it's satisfying to see something like a doubled conversion rate. If traffic is low, I'd just do a straight swap instead of a formal test, since even people whose whole career is A/B testing will tell you not to bother running one if you're only getting a handful of conversions a month — you'd need six months to reach statistical significance. Beyond testing, panel-based website review services are useful too, though people are often bad at explaining why something doesn't work for them, the same way a non-musician can tell a band is 'just okay' without being able to say exactly why.
You mentioned an old client whose course was getting 'too expensive' feedback. What happened there?
That feedback often isn't really about price — it usually means the value hasn't been made clear enough for someone to feel it's worth buying, which reads to them as 'too expensive' even though the real issue is they don't understand why it's worth the money. With that client, an online guitar course, we didn't touch the price at all — we rewrote the page to actually explain why it was worth buying, and sales went from weekly to daily. The original feedback was valid in that something wasn't landing, but the actual fix wasn't about the number on the page.
For an early-stage company with almost no traffic, is it mostly just guessing until something clicks?
Talk to people. That's the real answer, and I think it's the biggest danger of self-serve products — you can go a long time without ever actually talking to a customer, even in a support capacity. You don't have to frame it as market research, which most people will instinctively avoid — 'can I get on a call to learn about your needs' gets a much colder response than a friendly onboarding call where you naturally ask what they were using before and why they switched. Doing free, non-scalable onboarding calls just to create space for that small talk is genuinely valuable, even if it doesn't scale.
If you had one thing to tell an early-stage dev tool founder about messaging, what would it be?
Think hard about your ideal user's current scenario: what are they using right now, how much does it actually bother them, and are they even aware there's a problem to fix at all? Some problems are invisible until you point them out — like a security issue they don't know they have — and some are things people have quietly accepted as inevitable until you show them there's actually a solution. Whatever change you're proposing, be honest about where they're starting from — including if there's a free option already doing the job — and pitch specifically why your version solves the actual limitation of what they're doing now, rather than pretending the free option doesn't exist.