Once Upon A Time, A Database Had No Users

There was a devtools company that had been building their product for four years. Four years. Without incorporating any user feedback. They’d been engineering in the dark and when they finally tried to get customers on board, nobody came.

The team was almost entirely engineers. No real technical product marketing function. Their sales motion was generic - the kind where you blast the same pitch at everyone and hope someone bites. They were building a database and had convinced themselves they were competing with the giants.

They had zero brand awareness. Zero product awareness. Their product wasn’t remotely ready for a PLG motion, so they were running sales-led outbound into a void. Being a devtool in the 2020s without any PLG motion is... unusual, to say the least. But that’s where they were.

The Scramble

They needed people to know they existed. So they did two things:

They started an organic blog - behind-the-scenes content about building a database from scratch. The engineering challenges, the tradeoffs, the war stories. And they started doing events. Sponsorships, specifically, which got them booths and speaking slots. A lot of money got burned on the wrong conferences, because they had no real understanding of their ICP yet. They were buying visibility from people who would never buy their product.

But it started working, at least directionally. People began hearing about them. And as that happened, they layered in more.

Product feedback loops, driven by actual user interviews. More frequent releases, which meant more product-led content to ship alongside them. Market research and competitive intelligence, figuring out who else was in the ring.

The Part Where Everything They Believed Was Wrong

After a few months of gathering feedback, they had enough data to see clearly. And what they saw was brutal.

They weren’t competing with the companies they thought they were competing with. Their ICP wasn’t “data professionals” broadly, it was data engineers and data architects, specifically in a very targeted company segment. Their product roadmap was building the wrong features. Their positioning and messaging was completely off. The product components they thought made them competitive were irrelevant, because their stack was missing the features that actually mattered.

This was the moment they started understanding who they weren’t. Who they shouldn’t build for. Who they shouldn’t sell to. That negative space turned out to be more valuable than anything on their roadmap.

Around this time, they added CTO ghostwriting to their content arsenal - a mix of business and technical thought leadership - to drive traffic while the product caught up with reality.

The Overhaul

Because they’d been accumulating this feedback for months and had already started pivoting their content engine toward the real ICP, the conditions were right for a full positioning and messaging revamp. Not a tweak. A total overhaul - copy, visuals, everything.

The product was no longer “a high-performance database for [vague use case verticals].” It became a high-performance, self-hosted database with data warehouse capabilities, targeting specific personas, industries and use cases. That repositioning wasn’t invented in a brainstorm. It was the direct output of product interviews feeding into product development feeding into marketing. The whole pipeline, working the way it’s supposed to.

With the new positioning came a new vision and mission behind the product. Not the aspirational kind that lives on an About page and does nothing. The kind that actually informed what got built next.

But Where’s The Outbound?

Reading this, you might think everything happened organically. That they just blogged their way to customers. Not even close. They leaned hard into GTM engineering - tools like Clay and Lemlist - to run highly contextual outreach to people matching their ICP criteria. The content made the outreach work. The outreach made the content reach further. Neither alone would have been enough.

The Payoff

What followed was narrative-led and product-led content flowing through their organic channels and ghostwriting pieces, all targeting their actual ICP - the one they discovered through months of painful feedback and finally attracting the right users and prospects. The right people started engaging with the content. They entered the lead pipeline. The multi-year commercialization problem of having no customers, of literally having to fight for every single one, started dissolving.

Their new technical product marketing motion, combined with genuinely strong engineering underneath, poured into fresh branding, did the thing. Not overnight. Not magically. But it worked.

The lesson is almost stupidly simple: they didn’t find their customers. They built them. They built the feedback loops, the positioning, the content engine and the outreach machinery that manufactured a pipeline where none existed. Four years of building product in a vacuum, and then maybe six months of building customers on purpose.

Guess which period generated revenue.

Takeaways

It’s 2026 and some of these will feel obvious. The story above is proof they aren’t:

• Validate with real users early and often. Not your investors. Not your team. Actual people who would use the thing

• If you’re a devtool without a PLG motion, you’re sabotaging your own growth engine. It’s 2026. Developers have wanted to try before they talk to sales (like always). If your product can’t be touched without a demo call, you’ve already lost half your funnel.

• Do your technical product marketing homework. Don’t outsource it to an LLM. Use the LLM to accelerate, not to think for you. Positioning, messaging and ICP work are judgment calls. If you skip the judgment, you get generic output and generic results.

• Engineers love building and shipping. Ship less, ship what people actually need. The best feature you didn’t build is worth more than the three nobody uses.

• Hire product engineers, not software engineers. At the end of the day, the people building your product need to know why it exists and how to sell it on the street. Not just your sales team. Everyone.

The Old Outbound Was Dumb

Before we had AI enrichment, data platforms and hyper-personalization tooling, sales teams had one big channel: outbound. Cold email, specifically. The strategy - if you can call it that way - was volume. Blast as many people as possible with a pitch about your product. Not the problem it solves. The product. Features. Pricing. A calendar link. You know the email. You’ve archived hundreds of them.

Conversion rates were, predictably, terrible. Nobody used terms like SQL (sales qualified lead) back then, and honestly I’m not saying you need to now either - but at least the concept of qualifying before you pitch has entered the chat.

The macroeconomic backdrop was different too. Companies wanted to grow steadily. Gradually. If it happened to go exponential, wonderful, but nobody was planning for it. Now? Every company with a Series A expects the hockey stick, because a massive pile of VC money is sitting on top of them and the clock on returns started ticking earlier than it used to.

The game changed.

LinkedIn Made It Worse Before It Made It Better

Those early sales teams eventually discovered LinkedIn. The platform changed. The intention didn’t. Same generic message, new inbox. The conversion rate stayed low.

Automation tools showed up and - at least initially - made things worse, not better. Suddenly you could blast generic outreach at scale. A lot of sales folks are still running this playbook: high volume, zero personalization, praying the math works out.

The Model

Last September, after a decade of in-house devtools work, I tried consultancy. I’d been doing product content, narrative content, thought leadership and vision content (among others) for companies and specific people for over 10 years. Why not start writing for myself again - like I used to, back in the Medium dinosaur era?

That’s how this Substack started. But not literally that way, because if I’d just started writing without a plan, I’d be doing the same thing as the old outbound sales teams: high volume, no targeting, hoping something sticks.

Instead, because I’d spent most of that decade doing technical product marketing - I ran a workshop for myself. Nailed down my positioning and messaging. Figured out how I wanted to differentiate my content from everyone else’s. Competitive intelligence, but pointed inward. And also, first and foremost based on personal experience.

Once I figured that out, I started executing on the content.

The content came first. The outreach came second. That order is the entire trick.

The Reverse-Engineered LinkedIn Playbook

If you’ve been in the game long enough and been doing great work for years, your LinkedIn network grows organically whether you want it to or not. Connection requests pile up daily. But as I’ve written before on this blog, organic alone is not a solved game. You want to mix it with outbound.

Here’s how LinkedIn outbound typically works: you (or a tool like Clay) do research on a person, gather context, craft a personalized invitation note and send it. Because sending a blank connection request doesn’t work well - though honestly, that depends on who you’re reaching out to.

If you’ve done your ICP work properly at the positioning and messaging stage and you know what you’re writing about and you know LinkedIn lets you send roughly 100 invitations per week, here’s what happens.

You get a list of people you want to connect with. Method is up to you. Then you craft value-adding content regularly - content built specifically for your ICP. Then you send those 100 invites weekly with no note at all. No personalization. Nothing.

And you hit a high acceptance rate. Because your profile is full of content that speaks directly to the person you’re inviting. They click through, see three posts that describe their exact problem and hit accept.

The invite is just a door-opener, while the content already did the selling.

What Just Happened?

You reverse-engineered outbound. Instead of front-loading personalization into every individual message, you poured your experience into content that does the persuasion passively. The 100 blank invites per week are just distribution. The content is the pitch.

And now the inbound conversations start happening on their own.

That’s the model. Nail your ICP. Write for them relentlessly. Then let the outbound mechanics carry content that already resonates. The old model was “personalize every touch.” The new model is “be so obviously relevant that personalization is redundant at first contact.”

The conversations that follow? Those you personalize. But by then, they’re already warm.

There’s no grand unified theory here. No framework with a cute acronym. Just the one thing that separates content teams who ship from content teams who drown.

Narrative Angles

When you craft an asset - text, video, doesn’t matter - it should never be a one-off. Never. The blog post isn’t the deliverable. The *angle* is the deliverable. The blog post is one expression of it.

What I mean by angles:

• Product-led: educational and creative content built around the product itself. You’re showing people what the thing does and making them want to use it.

• Narrative-led: starts with a problem, ends with a solution. Observations-based. The product might not even show up until halfway through. That’s fine. That’s the point.

• Thought leadership: technical, business-oriented, or both. You’re staking out a position.

• Vision: where the industry is going. What the future looks like. The kind of piece that ages either very well or very badly and that’s what makes it interesting.

All four of these can go viral. All four should drive traffic and growth regardless of format or style. You’re supposed to execute on *all of these angles* for a single feature or product. Not one angle per launch. All of them.

You produced a product-led piece? Great. You’re not done.

Formats

You’re going to work across a lot of formats - text, video, short-form, long-form, whatever’s next. If you work in content, I’ll assume you don’t have an ideation problem. And in the best case, you’re not solving the blank page problem by prompting an LLM. You start yourself, then bring your agent in to help. That order matters.

Formats. Play with them aggressively. You wrote a long-form blog post? Work with devrel to cut a video series from it. Flip the angle - take the narrative-led version and reshoot it as product-led. Once you have one solid asset, treat it as raw material. It’s feedstock, not finished goods.

Do the content dog-fooding. Use your own stuff. Remix your own stuff. If your team isn’t constantly cannibalizing its own output into new formats, you’re leaving reach on the table.

You produced a blog? Great. You’re not done.

Distribution Is Not “Also Important”

There’s a comforting lie that content people tell themselves: “create great content and distribution takes care of itself.” It does not. Distribution is more important than creation. Full stop. And the evidence is everywhere - the people who handle distribution, whether in-house or as contractors, earn the most. A lot of them aren’t even domain experts. They don’t need to be. They just know how to get things in front of people. That should tell you something.

Pay attention to three things:

Channels: where are you distributing, to whom, and increasingly for what kind of consumer? Human readers and AI agents don’t discover content the same way. Think about both.

Timing: how often, and when. Cadence matters more than people admit. Flooding a channel is almost as bad as going silent on it.

Amplification: we’d all love pure organic reach. It’s rarely the whole story. Budget for paid. Don’t be precious about it.

How you weight these depends on your GTM motion. PLG-heavy? Your distribution engine looks different than sales-led or sales-assisted.

Know which game you’re playing and distribute accordingly.

When you think about it technically, from a product marketing perspective, there’s a finite set of launch elements you can choose from. Messaging. Assets. Channels. Dates. Sign-offs. It’s not infinite. It’s a checklist.

So why do some companies nail launches while others fumble around like they’ve never shipped anything before?

Because the good ones automated the boring part and spent their calories on the part that matters.

Boringness Is A Superpower

You want a to-do list so mechanical, so tedious, so utterly devoid of creative thought that you could run it in your sleep. Because the creative work - the stuff that actually gets people to care about your launch - needs every ounce of brainpower you’ve got.

The checklist is short. It’s always been short:

• High-level info: go-live date, launch tier, who owns what

• Asset buckets: positioning, external copy, paid, video, whatever else you’re shipping

• Links to drafts and finals, with freeze dates

• Accountability: who’s doing the work, who signs off

• Notes if you need them (you probably don’t)

Technically, some combination of Linear, Notion, and Google Workspace handles all of this. The communication layer is Slack and calls, as God intended. The sooner your team stops relitigating the *process* of launching and starts treating it like plumbing, the better.

Why? So you can focus on creativity and actually attract users.

This should feel almost automated. You should be pouring everything you’ve got - your personal creativity, your team’s collective creativity - into the work that makes someone stop scrolling and pay attention. There are approximately a bazillion launches every week, especially in devtools. I assume you don’t want yours to disappear into the noise. Neither do your potential users.

No Two Launches Should Feel The Same

Despite everything I just said about checklists, not all launches are created equal. And they shouldn’t be. Depending on the company and the product, you’re shipping features of wildly different scope and ambition. That’s atomicality by definition. Your launch tiers will reflect it.

A feature launch is smaller - less strategy work, fewer assets - than a product launch. Fine. But here’s the trap: if every launch *feels* the same, you’re dead. Same blog post template, same tweet format, same “we’re excited to announce” energy? Your audience tunes out. Your activation rate quietly declines. The excitement factor stops working.

Differentiate your launches the way you differentiate your product.

Timing Is The Whole Game

Everyone involved - product marketing, engineering, product, sales - should know what’s coming 2-4 weeks out. Not a vague roadmap. Actual clarity on what’s launching and roughly when.

If you can plan further ahead than that, great, but in 2026 I’m skeptical. If your planning horizon stretches to Q3, your competitors have probably already shipped what you’re still scheduling meetings about.

Your teams need to know what’s coming. Engineering needs to know *what*. Product needs to know *why*. Product marketing needs to know *how*. Not so they can over-plan - so they can stop over-planning and focus on nailing prioritization instead.

Timing isn’t just about individual launches. The coordination *between* launches matters enormously. Stack two big ones on top of each other and you’ve cannibalized your own attention. Space them wrong and you’ve got dead air. This is an underrated skill and most teams are bad at it.

Developer Experience, or: The Part That Actually Matters

I haven’t even touched the product feedback loop, and the fact that whatever you’re launching should, you know, solve a real problem and deliver real value. This feels almost too obvious to state.

If your product doesn’t do that, product marketing and sales can work miracles of positioning, but for what? You’re putting lipstick on a roadmap.

Anyway. Developer experience. Among technical companies, some players use DX as a serious competitive weapon when crafting launch assets and executing launches. They don’t just announce features. They make the first five minutes of using those features feel like magic.

If that’s where you think you should invest and if you’re in devtools, it almost certainly is, then you need your operational checklist game to be even tighter. Because the creative overhead of crafting great DX moments is enormous. You cannot afford to also be figuring out who’s supposed to write the changelog.

Nail the boring stuff. Then go make something people remember.

In the LLM era, most people skip long-form content and hand it straight to an agent to extract the core.

That’s exactly why I read it myself. Going analog often leads to gold. And that’s what happened here.

Now that I’ve read the whole piece, I’d love to expand on that.

Here’s the original source. I’ve named sections the same way Tessa did, so you can quickly map back to the original. If I had to recommend one section to read from her piece, it would be Time-to-Value: The Metric That Rules Them All.

The Three North Stars

Two of the three components Tessa describes here deserve more space: active users and revenue influence.

Measurable revenue influence

This one is deceptively obvious — and that’s the point.

No matter the department - DevRel, product, engineering, sales, support - we tend to frame success around what people do day-to-day. Implement a tool integration. Close X customers. Decrease support tickets. Pick your metric.

At the end of the day, those are all just means to driving revenue.

In the AI era especially, if what you, your team, or your department does doesn’t have direct impact on revenue, you’re a cost center. And cost centers get cut.

Attribution isn’t a solved problem. You won’t always know exactly where the money came from. But you need to make sure you can technically and correctly attribute as many events as possible.

Growing developer active users

One actively engaged customer is worth more than a hundred signups.

That’s not an argument against measuring new users. You should. But that number always needs to live alongside active users.

Many open source companies start with an open source GTM motion, which means activation rate matters, but so does conversion between free and first paid tier. And as the company matures, the data gets more granular:

• Tiered activation rate: what percentage of users run a specific volume of workloads

• Number of users who performed a specific action or used a specific feature

Engagement Is Not the Goal

“A Discord community with 10,000 members and zero correlation to product usage isn’t a DevRel win.”

Tessa is right. Member count is noise. What matters is how many of those developers actually adopted your product and stayed.

But I’d push this one step further: community evangelism.

It’s hard to measure on Discord. But platforms like Discourse - used by OpenAI, MongoDB, Cursor, and Cloudflare - let you measure exactly that. Active users helping other users. Organic problem-solving in public. That’s a signal worth tracking.

The Player-Coach Model

If you manage a DevRel or developer marketing team, you’re not just managing. You’re shipping.

I’ve lived this reality for over 10 years in devtools, starting from day one of my career. For most devtools companies, the line between manager and individual contributor is gone. You’re part technical, part marketing, and expected to be both. Everybody ships. Some just have more impact on strategy and leadership.

The market actually needs a new term for this role, one that’s been evolving quietly for a while. I’ve written about it in one of my recent pieces - the Developer Marketing Engineer.

Validate Before You Scale

ICP is dead. Long live the ICP.

Positioning, messaging, competitive intelligence - all of that product marketing work matters as much as your blog posts, events, or Discord presence. Without it, you’re just optimizing the wrong metrics.

Dev-Led Product Growth Culture

I was one of the early Auth0 employees. When Okta acquired us, we were past a thousand people. I’ll call myself an Auth0 OG.

At some point, we landed on a structure that worked extremely well - for product feedback, building, GTM, and launches. We built a product feedback loop that ingested signal from DevRel, sales, and developer success. That data got decoupled, triaged, built on, and marketed by a cross-functional group: product, engineering, DevRel, sales, and product marketing. Everyone understood their function and domain from day one.

The takeaway isn’t just that DevRel should be close to product - it’s that you need to build a coherent growth engine that lets you act on feedback across all domains and drive revenue purposefully.

Ideal Customer Profile Development

ICP is dead. Long live the ICP. Again.

If you’re not deep into product marketing, or if you work at a devtool startup struggling with growth, ICP definition is probably a recurring pain point. It’s not easy.

What makes it harder is the number of leaders who treat it as a one-time exercise. “We’ve figured out our ICP. Now let’s get to the real work.”

That’s the wrong framing.

ICP is something you revisit. If you need a simple trigger for when: revisit it when growth starts declining, or when you’re building a new product or feature set within your existing product OS.

Map the Developer Journey: The Five Stages

Tessa nails the intro to this section. I’ve written about it in my Developer Led GTM piece. Each component of your product OS maps to a specific stage in the developer journey. You need to know what’s working and what isn’t.

Think of it this way:

Awareness → Interest → Building (Activation) → Purchase → Building (scaling) → Advocacy

And there are multiple interaction points at each stage.

All of it comes back to revenue. And when we think revenue, externally we think pricing. If it’s possible for your product, put a calculator on your pricing page. Let prospects play with the knobs. It just works for revenue.

Support as a Journey Accelerator

In the AI era, self-guided support options are table stakes - ideally surfaced inside your agents too.

If you’ve spent enough time in devtools, you know developer support is really about education and ticket deflection rate. That’s a revenue driver. But there’s something more valuable that often gets overlooked: the product feedback loop.

Whatever platforms and channels you use to ingest customer feedback - that’s the foundation. Extract it. Prioritize it. Ship from it. If you can build a streamlined process for doing that end-to-end, you’re ahead.

A pattern of repeated questions? That’s a product signal. A recurring struggle? That’s a content idea.

And customers want to know what happened to their feedback - the what, the why, the when. Developers will vent frustrations publicly. Keeping your developer success team sharp, professional, and protected from burnout is a separate conversation - but an important one.

Community-Centric Feedback Loops

Feedback forms are increasingly plastic. Most developers share opinions the way that feels natural to them: on X, Reddit, wherever the conversation is already happening.

That’s a double-edged sword. The tooling exists to scrape feedback from almost anywhere. But your users can’t see the full picture when it’s scattered across platforms.

At Auth0, we went through this ourselves. Early on, feedback mainly came through sales calls and a form nobody loved. When we got serious about building a proper feedback engine, Discourse became one of our core sources. Users could see what others requested, vote on priorities, and add context - all in public.

That transparency changed the dynamic.

The Product + DevRel Partnership

I’d extend this to an engineering-product-marketing-sales partnership. Let me explain why.

Being one of Auth0’s early employees meant contributing to how we built products from the very start - from feedback gathering through to launch. The operating model was simple in concept and thoughtful in execution: pure cross-functionality.

For every feature or product, there was a group that covered every domain - product, engineering, product marketing, DevRel, and sales. Not hand-offs. Not updates. Actual shared context from day one, so we could understand what to build, how to market it, how to sell it, and how to drive adoption.

Education Over Promotion

One thing worth adding: developer education works best when you’re honest about the competition.

Be explicit about when developers should use a competitor’s solution because it’s better for the job and when they should use yours. That kind of honesty builds credibility. Credibility drives adoption.

Beyond what Tessa covers on education formats: one thing that drove real revenue for a startup I worked at was engineering storytelling - sharing how we built our features and products, what decisions we made, and what we struggled with along the way. Developers read that. It converts.

Last but not least

First of all I would love to thank Tessa. I’ve never read such a long and thoughtful piece on DevRel and developer marketing in general.

I’m not sure if Internet simply deserves that.

All in all, the more experienced and opinionated the people working with you on all of the aspects Tessa described in her playbook, and the more opinionated your customers are, the better your outcomes.

That’s the most reliable path to driving revenue, growing, and staying default alive.

It doesn’t matter what devtools branch you operate in. Tools matter as much as people, processes, and systems.

Similar note had been sitting in my content calendar notes for PlanetScale entry for weeks, phrased differently, but pointing to the same thing.

Marketing through engineering.

An Engineering-First Interface

At its core, the PlanetScale website feels like a markdown file, which it isn’t but it deliberately resembles one. And that’s the point.

From a developer marketing perspective, this is an alignment play. The content is structured like documentation. There’s no visual overflow competing with the message.

Their audience knows markdown. Many of them prefer it. LLMs parse it cleanly. Search engines love its structure. There’s almost no marketing gloss layered on top.

And yet, it stands out.

Not because it’s flashy. Because it’s simple, different.

In a market where infrastructure companies chase increasingly polished, animated, design-forward experiences, PlanetScale leans into something much more grounded.

Unapologetically plain.

Homepage

The world’s fastest and most scalable cloud databases

Hero Section

The hero copy on PlanetScale is extremely direct. It immediately highlights the core value their products - Postgres and Vitess - compete on. Performance.

If you’ve ever worked in database marketing, you know how tricky this is. Performance is both the most obvious positioning angle and the most crowded one. Everyone claims to be fast. Everyone shows numbers. And on the other side, buyers are trying to translate that performance into cost savings, but also take into account other engineering factors.

So how do you win in a category where everyone says the same thing?

You don’t say more. You prove more.

PlanetScale’s hero routes you straight into validation:

• “We’re the fastest” → See the benchmarks

• Hardware-level performance claims → NVMe drives

• Curious how to try it? → Clear deployment options

It’s essentially a compressed quickstart for product exploration. There’s no elaborate narrative there. No abstract positioning language. Just a sequence of logical next steps:

Performance → Proof → Deployment

Customers

From a technical product marketing perspective, placing customer proof (aka social proof) immediately after the hero section is almost mandatory.

The psychological sequence is important. You go from technical claim through benchmark proof to eventually reach those who build with the product, which strenghtens confidence quickly.

As you scroll through the logos, you can access case studies. And here’s where it gets interesting. Most case studies in devtools are written by the vendor and hosted on the vendor’s website. That’s normal.

But some of those PlanetScale stories, from companies like Intercom, Depot and Supermemory, live on their sites instead of PlanetScale’s.

That changes the signal entirely.

It suggests that the customer didn’t just agree to be featured, they cared enough to invest their own time in explaining why the product matters to them which is a much stronger endorsement.

It’s not the case for every logo there, but when it happens, it elevates the entire proof layer from “look who uses us” to “look who is willing to publicly stand behind us”.

And not only in infrastructure, I guess that distinction matters.

Vitess, Postgres, Neki

This is where the second core element of PlanetScale’s developer marketing shows up - education.

After performance proof and social validation, the homepage transitions into product segmentation, but not in a sales-heavy way. Instead, you’re introduced to Vitess, Postgres and Neki.

Each section reads like a structured technical overview. It’s essentially a quick architecture walkthrough with clear paths to deeper documentation.

This is not feature stacking, which from a developer marketing perspective really matters.

Infrastructure products, especially databases, are never impulse decisions. They require understanding tradeoffs, deployment models, scaling behavior, operational implications and many more so the education there isn’t optional.

Performance

This section again (not sure if done on purpose) feels like an intentional expansion of what was introduced in the hero. Messaging amplification.

In the hero, performance is framed around Postgres - PlanetScale’s newer offering - with clear benchmarking links. That makes sense. New products need momentum and visibility.

Further down the page, performance appears again, this time tied to Vitess (MySQL), which predates their Postgres offering. That sequencing is simple yet interesting at the same time.

From a product perspective, it’s logical. You push the newest strategic product upfront to capture attention. But you reinforce it with the credibility of the system that’s been battle-tested and widely adopted.

New momentum built through old trust.

Instead of positioning products in isolation, PlanetScale uses performance as the unifying narrative across both Vitess and Postgres. It signals consistency regardless of the engine.

From a developer marketing standpoint it avoids fragmentation, internal competition between products and it builds a cohesive performance brand across the stack.

Uptime

When evaluating infrastructure, there are a few non-negotiables. Performance is usually first. Reliability is always second and often more important.

After establishing speed, PlanetScale shifts the conversation toward uptime. The reliability layer is built around three clear pillars:

• SLAs - explicit service commitments, including service credit structures

• Status transparency - historical uptime data

• Failure mitigation mechanisms - things like directing traffic to new read-only replicas, online cluster resizing, resharding, etc.

What’s important here is not just that these elements exist, every serious database vendor has some version of them. It’s how they’re presented.

There’s no dramatic storytelling about resilience. No abstract “enterprise-grade reliability” phrasing. Instead, you get concrete mechanisms for what happens when things go wrong.

Cost

Once performance is validated and reliability is established, the final filter is almost always cost. In infrastructure, performance isn’t just about speed - it’s about efficiency. And efficiency, ultimately, is about economics.

On PlanetScale’s website, this shows up in a simple but loaded sentence:

At PlanetScale we believe cost is a unit of scale.

If they’ve truly nailed their ICP, this line should resonate immediately. What it implies at a granular level is this - as your system grows, your cost per query decreases.

It reframes cost from being a constraint to being an outcome of good engineering. Instead of optimizing purely for lower bills, the positioning suggests that scaling correctly naturally improves your cost efficiency.

Security

The last piece of the db explore-test-decide-buy food chain - security. As you move through PlanetScale’s messaging, it becomes clear they’re not only targeting small teams experimenting with side projects (using their single node instances). The positioning consistently signals large workloads and in some cases it means enterprise scrutiny (SOC2, HIPAA, etc.)

Features

There’s one more section on the homepage - features. I’m not entirely sold on this one in terms of why it’s located at the bottom of the page and not built-into the Vitess, Postgres and Neki sections under customer case studies, as that section serves as a product page intro for me.

What you want to focus on here though, are obviously the core features of the db platform, integrations it offers (as everyone wants a system that fits into their already existing ecosystem) and probably support options, all of which are backed with links to more in-depth materials.

Bottom Page Navigation

The site ends with a structured footer navigation, still consistent with the markdown-inspired minimalism. In most cases, very few users intentionally land in the footer. You only get here if:

• You’ve scrolled deeply

• You’re searching for something specific

• Or the top navigation didn’t answer your question

The markdown format of this place make total sense, however there are a few sections here that confuse me from product marketing and PlanetScale’s education perspective. I’m gonna start with the second one - courses.

If you’re into databases, know what PlanetScale is (at least high-level), you know how much they’ve invested in developer education over the years, as one of their developer marketing pillars (shaped by legends like Ben Dicken, Aaron Francis).

I’m pretty sure they have their website analytics in place but I’m wondering why courses don’t live within resources in the top website navigation.

Another thing is the product section of the table. All its elements have been already mentioned in the top navigation. None of these apart from benchmark actually fits into product (rather solutions).

What’s great though, and it’s still not a common pattern in the devtools industry is events. When you love a specific product, it’s very likely that you’d like to interact with the people that build it, not only online but also IRL.

How are you supposed to make both ends meet to figure out what meetups / conferences they’ll be at if you haven’t bookmarked them each time you’ve seen them out there, dispersed all over X and Li posts sharing what events those folks plan to attend? Great option here (and it’s also in resources up there).

Platform

Let’s shift to the top navigation. The platform section is, in many ways, the most telling part of PlanetScale’s website. What’s so great about it? You gotta enjoy extremely simple yet thoughtful information architecture.

The section is organized in a simple, tree-like architecture. Each branch leads to a focused product page and each of those pages systematically answers the questions any serious database evaluation requires:

• What is it

• Core features (why)

• How does it work

• Customer stories

• Benchmarks

• Migration guides, quickstarts, docs

• Support

That’s all and at the same time, it’s everything.

One interesting detail is the way use cases are presented. You see sharding among enterprise and startups and you start wondering why they’re mixing technical jargon with business related terms. The thing is sharding can be the case for both and what’s great about it here is that when you know what sharding is (at least high-level) and you know you’re in need, then you go there. In another scenario you either head to enterprise / startup intentionally and later on learn about sharding (whether you need it or not) or go straight there cause your curiosity steers you in that place.

Pricing

If you’re selling infrastructure in 2026 and you don’t have a pricing calculator, you’re making life harder for everyone, including yourself.

Database buyers are not casual consumers. They are technical, analytical, and often under pressure, especially during migrations or outage-driven evaluations. In those moments, emotion is high, but the decision still needs to be rational.

A good database pricing page needs to strike a difficult balance between simplicity and the number of config options.

Infrastructure pricing is essentially pure math. Storage. Queries. Compute. Throughput. Replication.

The people evaluating it want to understand exactly how the numbers behave, especially compared to their current setup.

Documentation

We’re in the Mintlify era. Polished documentation tooling is widely available. Search is good. Layouts are clean. AI copilots are layered on top.

Which has led many teams to believe that docs are now a solved problem. They’re not. The tooling is solved. The information architecture isn’t.

When you land in PlanetScale documentation, nothing feels revolutionary at first glance.

Docs like any other, right? Not necessarily. There are still devtools companies that treat documentation as a disconnected island and from information architecture and navigation perspective force you out of their product OS, so you can eventually (again) come back from the Google search to the initial place you were on (docs). What I’m talking here about is this:

Within the navigation plane that sits on the left hand side and on the top of the page, you can basically:

• Browse through product-categorized docs that are neatly organized into sections

• Log in / sign up to PlanetScale

• Go to their website / blog / status page / benchmark page

• Book a meeting with sales

From a developer marketing standpoint, this matters as docs are pre-purchase evaluation tools, onboarding flows, and conversion surfaces all at once.

Thoughts

Some websites stand out cause there’s a lot happening there especially graphics and motion wise and it seems like there are more and more players that go this way to stand out. There are some core components that everyone out there does, cause they need to, including PlanetScale.

However there might be a new way. Marketing heavily grounded in engineering, communicated through extremely well executed form simplicity.

I’ve never worked in a traditional office. For the past decade, I’ve been in fully remote environments - highly autonomous from the earliest stage of my career and inherently asynchronous. Part of that was team seniority, the rest was geography.

There was no difference across the domains I worked in. Engineering, product marketing, community - asynchrony wasn’t a preference. It was the only way the work could happen.

The anecdote

There’s a practice from my early days at Auth0 that’s worth sharing and revisiting at the end of this piece. We had an unwritten rule: if you couldn’t make progress on a problem within roughly 30 minutes, you reached out to a teammate. If they couldn’t help, you escalated to a subject-matter expert.

Simple in theory. Harder in practice when your teammate was on the opposite side of the world and the next opportunity for help was several hours away.

The problem

It’s easy to assume the challenge in asynchronous work comes from the obvious variables:

• Different working hours

• Different schedules

• Different responsibilities across domains

But that’s not the root of the problem.

The real friction appears before any collaboration even begins. It starts the moment you sit down to define what you need to do. You open your task manager, try to understand the work, and establish the basic context required to move forward.

Without that clarity, everything downstream slows.

Context is king.

The work process

To make asynchronous work actually work, everything begins with one element: craftsmanship.

At its core, craftsmanship is about how people approach their work. Most think of work as the final output - a shipped feature, a marketing launch, a community initiative. Others expand that view to include the technical or creative process that leads to the result.

But there’s a third layer that becomes essential in asynchronous environments: the quality of communication, especially written one.

Those three elements essentially form the work process.

In async setups, writing isn’t a companion to the work. It is the work. It’s how context is created, transferred, and preserved. Without it, no process or output can scale across time zones, schedules, or domains. Not to mention, achieve highest possible quality.

Craftsmanship

Everything starts with quality. That’s why you hire people who approach their discipline as a craft. They hold a clear internal standard for what good work looks like, not just the final output, but the decisions, structure, and reasoning that lead to it. In this sense, product means the work itself, no matter the domain you operate in.

Craftsmen don’t wait for external approval. If something isn’t right, they refine it until it is. That intrinsic bar for quality gives them the ability to break complex work into smaller, understandable pieces, making the process transparent to others.

And because they hold themselves to high standards, they expect the same from the people they work with:

• High-fidelity transparency in how work is built

• Total ownership of outcomes

• Extreme attention to craft and detail

• Respect for the craft of others, across the entire process

These aren’t preferences. They are the prerequisites that make asynchronous work sustainable and the conditions that naturally solve the request asymmetry problem.

What makes asynchronous work really work

Asynchronous work functions when everyone provides a high-quality work process to others and expects the same in return. That reciprocity is what resolves the request asymmetry problem.

Regardless of who is doing work for whom, one element is always shared: context. Context sets expectations. It defines the work, the process behind it, and the communication required to move it forward.

Async work isn’t about creating the bare minimum of tasks in Linear. And it isn’t about doing the work for someone else. It’s about doing the context work yourself before asking for another person’s attention. The more clearly we specify what we need from each other, the more efficient and higher quality the execution becomes.

Craftsmen know the difference between “not enough” and “on point.” When everyone operates with that standard, asynchronous work stops being a constraint and becomes an accelerator.

The anecdote follow-up

When the core context is clear, technically and conceptually, you already have what you need to begin the work. You no longer depend on someone else to unblock you in the moment.

Remember the hours lost waiting for a teammate across the world to respond?

With the right context in place, that problem disappears.

At first glance, it’s easy to dismiss it as just another fancy name for sales. After all, we’ve had sales, sales engineering, demand generation, growth - pick your flavor. Titles change. Org charts get reshuffled.

For years, go-to-market motions relied on scale rather than precision. Broad outreach. Generic messaging. Large volumes, vague targeting. Every now and then something would land. Most of the time it wouldn’t and eventually, spam filters caught up.

At some point Clay flipped the model.

Instead of optimizing for volume, they built tooling around context engineering, deeply understanding who you’re reaching, why now, and what signals actually matter. That context then powers highly targeted outreach that feels less like a campaign and more like a well-timed conversation.

If you get your ICP right, which Clay helps with too, the impact on activation and conversion can be significant. And that’s before you even look at the rest of the use cases the platform enables.

Why Clay matters here

Recently I came across one of the recent post from about generic job titles and more importantly generic job descriptions.

You don’t even need to read the full piece to get the point.

PostHog needed to tweak the positioning and messaging of their product marketer listing, likely more than once (probably) as a result of interviewing candidates and realizing they weren’t hitting the ICP for the role.

What initially looked like a perfectly reasonable job tlisting turned out to be too broad. Shifting to a newer, more specific one made the role legible to the exact kind of people PostHog was looking for.

Not more people. The right people.

If you’ve spent any time around DevRel, developer marketing, or hybrid roles, this probably doesn’t sound surprising. These disciplines have always lived slightly outside traditional org charts and that ambiguity is often the point.

So how does this connect back to Clay?

The gap between developer marketer and technical product marketer

There’s a growing number of developer and technical product marketing roles out there, especially in devtools. You won’t find them neatly labeled on LinkedIn Jobs, but they exist, and more teams are quietly hiring for them.

The obvious question is: who actually applies for these roles?

Usually, it’s some mix of:

• Developers who pivoted into marketing: they understand the internals and now want to learn how to market them

• Marketers who suddenly started LLM-ing their way through everything: dangerous, but occasionally effective

• Developer relations folks: they’ve touched product, engineering, sales, and marketing already so why not add one more hat?

• Product marketing managers from technical companies: The kind who’ve gone from drag-and-drop UIs to database internals and had to recalibrate what “technical” really means

• Product people who’ve done a bit of both: enough engineering to build empathy, enough marketing to shape narratives

Every company will naturally optimize for a different mix, depending on its product, stage, and constraints.

What’s less clear and increasingly uncomfortable is:

What exactly is developer marketing and technical product marketing today?

The Developer Marketing Engineer

In the LLM era, the clean line between developer and technical product marketer is slowly disappearing. The name Developer Marketing Engineer tells you that this is a generalist role by design.

Imagine a person who:

• Codes

• Does product positioning and messaging work (and rework)

• Handles competitive intelligence

• Is able to run GTM campaigns and product launches end to end (strategy, planning, hands-on execution, success metrics setup and tracking)

• Does technical & non technical content engineering (newsletters, blogs, socials, quickstarts, guides, live demos, product go-through videos with voiceover, etc.)

• Runs growth experiments

• Does GTM engineering with tools like Clay

• Ghostwrites

• Handles all aspects of co-marketing with other players

And on top of that, have domain experience in the field that a specific company is interested in.

But just like with GTM Engineers, the role didn’t appear because someone invented a title. The title appeared because the work was already being done, and usually under a different name.

These people exist. They’re just rare. And they know it.

Before you go

Would you rather bet on a developer who learned marketing or a marketer who’s learning to become technical with the help of LLMs?

If you work in devtools, you’re constantly surrounded by new.

• New products

• New features

• New content

• New website redesigns

There are endless examples, and to be fair, this isn’t new. Devtools has always moved fast. What has changed is the pace and the volume. And I probably don’t need to explain why that acceleration happened.

What’s showing up more frequently now is a reversal in how things get built:
people prompt first, then think.

I once had a colleague in devtools tell me that if your website doesn’t have a ton of content, you look amateur and no one will trust your product.

That belief is so common nowadays.

The result is that it’s getting harder, every single day, for developers to answer two very basic questions:

• Is this product actually for me?

• What should I try to validate that it solves my problem?

Instead of clarity, we get volume.

On top of that, most of the narrative is relentlessly feature-led.

We built X so you don’t have to Y.
We added Z so you can finally do A.

These statements often touch the problem, but only at the surface level. Once you dig in, the content quickly shifts from why this matters to how great the feature is.

That’s where things fall apart.

Because the goal isn’t to make users admire your product.

Make users better at what they want to do not thinking what you want them to do.

Around the time I launched Teardowns, a section of this newsletter where I unpack the inner workings of leading devtools through a developer marketing and developer experience lens, I came across something that immediately caught my attention.

A post from Zachary Short, Buildkite’s Growth Marketing Manager, popped up in my LinkedIn feed. He shared that Buildkite had just gone through a major website redesign.

So I did what most developers (and dev marketers) would do: I opened the site.

And it stood out. Immediately.

Established markets and doing things differently

Whether you actively care about CI/CD or not, one thing is obvious: this is a mature market.

Most of the players are well known. Developers recognize the names, understand the trade-offs, and have likely used more than one of the tools already, at least from a technical perspective. It’s easy to look at a space like this and conclude that everything worth discovering has already been discovered.

That conclusion is almost always wrong.

From a developer marketing perspective, mature markets are often the best places to stand out. Not because you invent a new category, but because expectations are already set and breaking them thoughtfully gets noticed.

The key is how you do it.

You can do things differently, challenge conventions, and still earn attention.

but only if your marketing is grounded in engineering reality

Differentiation that isn’t anchored in how developers actually build, test, and ship software rarely survives first contact with a technical audience.

Buildkite’s Website Makeover

I’m gonna focus here entirely on the new experience and won’t be touching the classic one. Here’s what we’ll be exploring:

Upper Navigation Plane

The folks at Buildkite almost certainly have product analytics backing their decisions here. My guess is that a large share of visitors jump straight to docs or the command line–oriented parts of the site.

Still, I want to start at the very top.

The first thing that caught my attention, perhaps my developer marketing brain kicking in, was the [E] Exit to classic Buildkite option in the upper navigation.

When you design an experience like this, having an escape hatch is non-negotiable. Your audience is always a mix: new visitors, returning users, power users, and people who just want to get something done. Giving them control over how they engage is table stakes.

But this pattern immediately reminded me of Sentry’s website, where a similar idea is implemented quite differently.

On Sentry’s site, the toggle lives on the right-hand side and lets you switch between two clearly defined modes:

• Marketing mode (the default landing experience)

• A developer-first, interactive flow that walks you through the product via prompts and chat

Once you flip the switch, the marketing layer effectively disappears. What’s left is a guided, hands-on introduction to the product. No positioning statements, no feature grids, no fluff.

Same underlying idea. Very different execution.

How does it work for Buildkite?

When you land on Buildkite’s website, you’re introduced first to the new experience, not the classic, marketing-heavy one.

Instead, you get an interface that feels immediately familiar to DevOps engineers: command-line–centric, utilitarian, and focused on doing rather than explaining. It’s an engineering-first entry point, not a positioning narrative.

That choice matters.

Buildkite is effectively leading with an engineering-native experience rather than easing visitors in through marketing pages. That can be a dealbreaker in many categories, but if it’s intentional and backed by customer data, it’s a strong signal of confidence in both audience and product. From a developer education perspective, it’s also a meaningful move and I’ll come back to that later.

Looking at the rest of the upper navigation, the setup is clean and clearly product-led. You’re given the essentials:

• Help

• Docs

• Contact

• Sign up

• Log in

With the exception of Help, each of these links routes users back to the classic experience.

Given that this kind of hybrid website model is still relatively new for many devtools companies, information architecture becomes critical. When everything lives in a single row, two questions matter most:

• What deserves a place here?

• In what order?

Starting with Help makes complete sense. If someone feels lost, this is the fastest path to unblocking them. Docs come next, naturally anchoring the experience in education and self-serve discovery. After that, Sign up and Log in give users a clear next step, whether they’re new or returning.

The one item I’d question is Contact.

Without internal context it’s hard to judge, but in devtools, “Contact” is almost universally interpreted as sales. In my experience, placing it so prominently in an engineering-first navigation rarely drives meaningful conversions. I’d consider either moving it to the very end, just before the [E] Exit to classic Buildkite or removing it from this plane entirely.

The CLI - Copy & Animation

What you’re greeted with first is a simple, eye-catching animation. It adds just enough motion to draw attention without pulling focus away from what matters most.

From a developer marketing perspective, though, the real work happens in the copy. There are two sentences in particular that stand out and they do a lot of heavy lifting.

The first sentence is an exceptionally strong opener. Not because it’s clever or aspirational, but because it reflects the engineering mindset behind the product and the experience you’re interacting with.

Buildkite is explicitly telling you: don’t take our word for it, try it yourself.

What makes this powerful is that the environment where you’re encouraged to explore is a direct embodiment of that message. The copy doesn’t just describe the product; it’s validated immediately by the interface itself. That alignment between message and experience is hard to fake.

The second sentence that caught my attention reinforces this even further:

In developer marketing, copy usually falls into one of two camps:

• “We know all your problems and do the heavy lifting for you.”

  • Broad, reassuring, and optimized for teams that want abstraction and speed.

• “Here are the primitives, build exactly what you need.”

  • Specific, opinionated, and aimed at domain experts who value control and flexibility.

Buildkite clearly leans into the second approach.

If this copy is strongly informed by customer data, and it likely is, it signals a high level of maturity. It suggests confidence in the product’s engineering quality and an intentional nod toward an experienced audience that doesn’t want to be oversold or shielded from complexity.

This isn’t copy trying to convince beginners that CI is easy.

It’s copy telling experienced engineers: we trust you.

The CLI - Commands

This probably should have been the first section of the article, so let’s get into it.

Help

The command list is effectively your navigation system for the entire experience.

Commands marked with green arrows clearly indicate redirects to the classic experience. Below that, utility-style commands let you go deeper into the playground. Some customize the experience itself, while others surface additional product and company-related content:

Capabilities

Taken together, this behaves like a compressed product page. Instead of long-form explanations, you get short, direct links to the most relevant docs or classic counterparts. No fluff. Just enough context to decide where to go next.

Proof

Visually, the CLI-styled logos immediately grab attention. But the real value here is functional: externally linked resources like articles, webinars, case studies, and conference talks, all surfaced without breaking the flow.

What’s especially well done is how testimonials are handled. The copy is straightforward, product-led, and avoids the usual marketing theatrics. When you ask for more, you get substance, not slogans.

And then there’s this:

Nobody, especially experienced engineers, has ever complained about a good laugh paired with a free account to try things out. Humor here doesn’t cheapen the experience; it humanizes it.

Pricing

This one keeps it simple: you’re redirected to the pricing page. That makes sense, but it does make you wonder what a CLI-native pricing view could look like. A matrix- or table-style output feels like it would fit naturally here and still communicate value clearly.

Bottom Section

At the bottom of the experience, Buildkite surfaces a few operational metrics directly in the CLI.

You can see:

• The number of builds run in the last 24 hours

• The total number of builds since the platform launched

• The number of currently active pipelines

These numbers aren’t there to impress, they’re there to anchor the experience in reality.

There’s also a shortcut to check the platform status. Initially, I expected this to redirect me to a separate status page or an external service (something along the lines of status.io).

Instead, the status is rendered directly inside the CLI.

Standing out in the website crowd

Buildkite’s website genuinely stands out in a crowded devtools landscape.

Not because the visuals are bold or the interactions are novel, though both are well executed, but because the experience is built on the right foundations. The design and marketing choices consistently defer to engineering reality rather than trying to abstract it away.

That’s the part many devtools teams get wrong.

Buildkite doesn’t try to simplify CI for everyone. Instead, it leans into the workflows, mental models, and expectations of experienced engineers and builds a marketing experience that feels native to that audience.

In an established market, that’s often the strongest form of differentiation.

The crowd is real.
Standing out rarely comes from doing more.
It comes from doing things differently without losing your developers’ trust.

If the newsletter is called Developer Led and this piece is titled Developer Led GTM, it’s reasonable to assume I’m introducing a proprietary framework or some branded methodology.

I’m not.

My perspective comes from a different place. I started my career as a software engineer working in devtools. I haven’t been a full-time engineer for years, but I still write code every day (with and without AI). Most people in developer marketing or technical product marketing will tell you that you should, even if you didn’t start in engineering. The reason is simple:

You can’t build, market, or sell to developers without understanding how they think.

Over time I noticed a pattern in the teams and companies that consistently got developer-facing products right. They all had the same backbone:

(ex-)developers marketing and selling developer tools to developers.

Realizing this felt less like inventing a system and more like uncovering an obvious truth that had been sitting in plain sight.

I could have called this model developer-focused, but that doesn’t quite capture it.
Developer Led does.

The Product is Everything

My thinking around developer products shifted when I stopped treating “the product” as just the SDK, API, or managed platform. When most people hear devtool, they picture the technical surface: the endpoint, the library, the CLI. The thing developers use to build.

But that’s only one slice.

Your product is everything a developer touches or sees before they ever write a line of code.

Your website and every subpage. Your docs. Tutorials, samples, guides. Your SDKs and APIs. Social channels. Case studies. Release notes. Even the information architecture that connects it all.

If any part of that surface area is confusing, incomplete, or forces someone to leave your ecosystem to search elsewhere, that’s a product failure not a marketing one.

I think of it as the “product OS.” Once a developer enters, they should be able to navigate, explore, learn, build, and decide without friction. The packaging matters as much as the underlying capability. In many cases, more.

This perspective doesn’t match most GTM playbooks, and that’s intentional. The goal is to expand how we think about developer products and to give you a reason to reconsider how your own product, packaging, and go-to-market model fit together. In this one, your product OS is your GTM. You start thinking about things as a whole.

A Shared Model

Before going deeper, it’s helpful to establish the foundation for how developers move through a product. People in the devtools space like to call it a journey, and in this case the term fits.

Here’s the sequence I use:

Awareness → Interest → Building (Activation) → Purchase → Building → Advocacy

This isn’t a marketing funnel. It’s the path a developer with zero prior context must follow to become confident, ship something real, and eventually talk about the product publicly. Every part of your GTM strategy is anchored to how well you support this progression.

For this piece, I’m focusing entirely on the developer-first model. I’m not covering the developer-plus one here.

Developer Led GTM

Before diving in, zoom in on the diagram. Its structure carries most of the argument.

Over the years I’ve seen countless attempts to define the “right” model for developer-focused companies. Each proposes a universal structure, a perfect alignment of teams, functions, and responsibilities. But there is no one-size-fits-all template. At best, you find patterns that resonate and frameworks that help you think more clearly.

For me, the model consistently distills into three core components:

• Developer Relations

• Developer Experience

• Developer Marketing

This isn’t theory. It’s the product of a decade spent operating at the intersection of DevRel, product marketing, product management, and engineering, through both the wins and the failures. Could sales be a fourth pillar? Possibly. I haven’t operated inside that structure myself, so I’ve intentionally left it out. I’ll revisit it if experience ever proves it necessary.

Let’s break down what each component represents.

Developer Relations

People like to say that DevRel has already been fully defined, that by now, everything worth inventing has been invented. The same claim gets made about almost every field, and it’s always wrong. No discipline stops evolving, especially one as closely tied to engineering as DevRel.

The point isn’t to defend a specific definition. It’s to stay open to reframing it. If what follows challenges how you currently think about DevRel, that’s the intention. The goal is to broaden the context, not to preserve the status quo.

Developer Advocacy

At its core, Developer Advocacy is exactly what the name implies: advocating for developers. That begins with understanding the underlying needs behind the feedback they share, not just the literal request, but the problem it points to.

The role is to translate those needs accurately, internally and externally. Developers should know where their feedback goes, how it’s used, and when it influences the roadmap. That transparency creates trust, and trust encourages deeper, more meaningful feedback over time.

The principle is simple:
Represent developers’ interests in a way that directly shapes the product.

Developer Evangelism / Education

The purpose here is straightforward: help developers understand, adopt, and succeed with the product. Evangelism, stripped of its historical baggage, simply means sharing ideas, telling the story, and inspiring interest. Education builds on that by teaching the concepts, patterns, and technical foundations developers need to solve real problems.

The industry now uses “developer educator” more often than “evangelist,” but the underlying function hasn’t changed. Both exist to increase understanding, spark adoption, and expand the community of developers who know how to use the product well.

Developer Community

Community is ultimately built through consistent, meaningful interactions. Not relationships in the personal sense, but the professional ones that form when a developer feels supported, inspired, or unblocked by someone on your team. Most developers can recall a moment when an advocate, educator, or engineer from a company helped them solve a problem or showed them something new. Those moments compound. They create affinity and eventually, community.

The work spans a wide spectrum, from hands-on developer support and technical guidance, to highlighting what people are building, to AMAs and deeper conversations with the team, all the way to structured programs like champions or ambassadors.

The through line is simple:
Create spaces where developers can learn, share, build, and feel connected to the product and the people behind it.

Developer Experience

The term likely evolved from UX, adapted into the devtools space as products became more complex and the expectations of developers increased. Most people in the field have an intuitive sense of what DX means, but it’s worth articulating clearly.

Developer experience is about enabling developers to use the product correctly, efficiently, and ideally enjoyably. That experience starts long before anyone writes code. It begins with the first spark of interest, continues through learning and evaluation, and extends into purchase and building.

The goal is simple:
Optimize for developer clarity and developer joy across every part of the product surface.

Whether someone is interacting with a single component of your product OS or navigating across multiple parts of it, the experience should feel coherent, predictable, and effortless.

Developer Marketing

Despite how the diagram might initially read, Developer Marketing isn’t a promotional layer on top of the product.

It functions as the bridge between engineering and the developers who will ultimately use what you build. It is responsible for understanding the product deeply, translating its value clearly, and shaping the pathways through which developers discover, evaluate, and adopt it.

Developer Marketing is the force that gets a product to market and the discipline that ensures it stays relevant once it’s there.

The work spans multiple dimensions. It means crafting the narrative around why the product exists and the problems it solves. It means defining the entry points into the product OS, clarifying the mental models, and guiding developers toward the shortest path to “I understand this” and “I can use this.” It also means owning the signals that help a team know what’s working: documentation engagement, tutorial completion, SDK adoption, time-to-first-success.

At its best, Developer Marketing doesn’t feel like marketing. It feels like context: the explanations, examples, and guardrails that make a product approachable and usable. It aligns the internal story with the external one and gives developers the clarity they need to make a decision.

The goal is simple:
Connect product and developer in the most honest, efficient, and technically grounded way possible.

Components Choice

You may have noticed that the groups in this model share overlapping functions. That overlap is intentional. It doesn’t mean you can swap one component for another and expect identical outcomes. Sometimes that works, often it doesn’t. The execution, context, and maturity of the company make the difference.

So how do you decide which components to invest in, and when?

There’s no universal playbook. The right combination depends on factors that change from company to company: product maturity, business model, team structure, industry norms, and whether you’re operating like a startup or a large organization. The variables are too numerous and too dynamic for a static answer.

The only reliable approach is experimentation. Run small tests. Move quickly. Instrument your efforts so you can measure what improves the developer journey and what doesn’t. When something fails, pivot. When something works, repeat it until it no longer does.

Over time, you’ll identify patterns. The set of activities that consistently drive adoption, clarity, and activation for your product. But even then, the work doesn’t stop. The landscape keeps shifting, and the strategies that worked last year may lose their effectiveness without ongoing iteration.

The goal isn’t to find the perfect mix once.
It’s to continually refine the mix as the environment, product, and developers evolve.

The Principle

Developers rarely want a partial view of a solution. They want the full picture the context, the reasoning, the details that let them make informed decisions and build with confidence.

The takeaway is simple:
Upgrade your users, not just your product.

Give them the clarity, tools, and understanding needed to unlock the value you’ve created. When developers level up, the product does too.

Developer evangelist… who?

You already sort of know who Developer Evangelists are (or Developer Advocates, or DevRel Engineers, pick your fighter, we’ll argue about the titles next week).

But let’s be real for a second.

Here’s the simplest way to describe the job without making it weird:

When your company ships something new for developers, you’re the first one to touch it like you weren’t paid to.

• You build with it

• You break it

• You figure out what’s confusing before anyone else does

Then you write down what you learned, clearly, honestly and show developers how to build something real with it.

That’s it. No mystique. Just being the first external developer, except you work inside.

Build bridges

If you’re a Developer Evangelist or planning to become one, think of your job this way:

• Help people understand problems and solutions

• Connect people

• Connect businesses

• Help find even more resources

What’s next

Weekly Goodies drop this Saturday, obviously.

And next week, we’re taking things apart. Your DevRel engine, mine, everyone’s. Not to dunk on anything, but because different teams make different things work… or not.

So let’s have opinions. Let’s rethink. Let’s pivot when the data (or the vibes) tell us to.

See you then.

DISCLAIMER: Neither the writing style nor the tone of James Hawkins was used, and no PostHog shareholder value was harmed in the making of this post.

Before I dive in, I’d just like to acknowledge the dozens of easter eggs I’m definitely not going to find.

Motivation for this piece

This was meant to be the first post in my new sub-Substack series called X-Rays. Basically me overexposing devtools websites through dev marketing lens. One day I’ll turn it into actual (im)proper content. You choose whatever format works for your reading time.

But yeah… no new formats for now. My Substack is like four weeks old, lol.

PostHog’s Website TL;DR

Where you should head depending on who you are and whatever brought you here (no, I’m not recapping the whole site in this one paragraph):

• Dev implementing PostHog

• 16 minutes platform curiosity spree

• Just here for fun

• Want to look devtool-fancy

• Skimming products (technical or not, more or less doesn’t matter))

• Need to convince the finance overlord at your corp to pay for PostHog

• If you have no idea where your hedgehog is going

Where am I

Ever heard of Windows Millenium? It’s an OS, bro. PostHog’s new website is like that, except it hasn’t crashed for me yet.

Cool, but what dark magic is powering this thing behind the scenes?

If you have deeper, existential “how does this thing even work” questions, go ask Cory Watilo or Eli Kinsey. They built the thing.

If you just want the basics, click the hedgehog in the upper-left corner of the website. Yes, the hedgehog. Don’t overthink it.

Yes, you can move the files. Yes, there’s a screensaver. Yadda yadda.

But let’s head in a completely different direction before I get distracted again.

How to navigate this thing?

When I first landed here, I thought: Okay… where do I even start? This place is like nothing my overstimulated brain is used to. I can barely navigate normal devtool websites, how am I supposed to survive this?

Then I had an eureka moment.

I need to find my navigation plane for this thing.

Here’s what my brain did next:

• Desktop: folders, files, windows popping up

• Navbar: the “formal” route

We humans are great at chunking information to stay functional. And, as I later discovered, all these components actually connect to each other, which makes total sense for something that’s basically an OS.

Want windows popping up everywhere? Sure, go wild. Prefer order? Open everything in a new browser tab like a civilized person. How? Exactly the way you’ve been doing it your entire dev career.

The desktop

Welcome home. On PostHog’s website. Feel free to settle in. Throw some bookmarks around, open too many windows, reorganize files and folders like you’re customizing an OS you actually like.

home.mdx

The most crucial bit here (developer instincts never lie): hit “Get started.”

Not the “Get started - free” option - (wait, is my data physically stored under someone’s IKEA desk?).

I mean the important button. “Install with AI”

Don’t worry, you old retro code guy. You can do it in your good ol’ terminal, or from Cursor, Replit, Bolt, whichever makes you feel the least judged.

What else do I recommend in this file (after actually going through it myself)? The 16-minute PostHog platform demo.

If you’ve heard about PostHog and started poking around, you’ll probably like the next mini-section - Explore apps. Why? Because you can browse by company stage, which is way more useful than it sounds at first (it also shows up in the Product OS tab in the navbar)

Want to see how other devs like you use PostHog? Check out Who’s using PostHog?

There are so many devtools companies out there plastering big logos everywhere to build “social proof” and convince you to trust them.

But… are those companies actually using their product? Or is it just one rogue engineer messing with it after hours?

Here, the claim actually feels legit.

Oh, what’s that button up there?

What’s a more useful way to categorize your customers than with boxes like:

• Names you can easily mistype

• Names with 7 letters or less

• Everyone else (for now)

• Companies who should do case studies

• Real words

• Not real words

Duuude, they got me.

Scroll a bit and you get a few lines subtly explaining what’s actually powering PostHog’s Product OS and why you probably need it (yes, you guessed it; a customer data platform, but cooler)

Next up: how much you pay for all that jazz. Usage-based, transparent, and suspiciously “let us do the heavy lifting so you don’t blow up your infra” vibes.

Then comes a quick “why don’t you use PostHog AI?” section.
Convincing, but not pushy. Early persuasion done right.

You wrap up with a short bit about the company itself (not the product): culture, philosophy, and the kind of stuff that actually matters when you’re picking a stack (I already dove into that earlier)

You think that’s all for home.mdx?
Oh no. Absolutely not. There’s still more.

For example: UI adjustment options.
Why not play with them? Your inner 2008-era desktop customizer is begging you.

And of course… the Shameless CTA.
If you’re from the late 80s or early 90s, you’ll spot the CD reference instantly.
If not, don’t worry, half this blog can’t decide what’s serious anyway, so you’re in good company.

Just kidding… thank me later. You’re probably not seeing a better devtool deal today. It’s free, and somehow you can still get a discount. Or not. Who knows.

Oh, and one last thing: PostHog’s “Talk to Sales”- ahem, Talk to human CTA.

It’s short, practical, and surprisingly not cringe. I follow some of their sales folks on LinkedIn (the job marketplace / content farm hybrid), and they’re genuinely technically strong.

So no, they won’t bore you to death.

The rest of the stuff on the desktop

I started navigating from the desktop (not the navbar), and with this old–new mashup of a UI, you truly don’t know what you’re walking into.

But it turns out most of the desktop items link back to the navbar (and vice versa).

• home.mdx

• Why PostHog?

• Changelog

• Company handbook

• Store

• Work here

• Product OS

• Pricing

• customers.mdx

• demo.mov

• Docs

• Talk to a human

• Ask a question

• Sign up

Okay, secret time. I know precisely how this bi-directional info architecture came to life.

The graphic designer and frontend engineer were moments from declaring victory…
when someone from PostHog C-level (want to take a guess) teleported in, pointed at random pixels, requested last-minute changes, and summoned posthog-website-finalfinal.js into existence, now with fully bi-directional navigation.

Designers, frontend devs, and shareholder value: the holy trinity of chaos.

But wait

There’s one more thing you can’t get to from the navbar: Trash.

I tried deleting a few desktop files, but apparently PostHog thinks I shouldn’t be trusted with that level of power. Rude, but fair.

Alright, fine. Let’s dive in. Bleh.

You can’t access the ones in the archive, even though the titles are ridiculously tempting. So fine, let’s play with Recently deleted instead.

• Copy of whitepaper (2) - finalFINAL.docx.pdf

If there’s only one thing you explore on the new website… it’s this.

• quick calls script.txt

Okay… two cool things here.

Hover over the Share button. Click it.Boom: 90s sound nostalgia. The first time I did it, it played Cher. Then I clicked Share again and something totally different happened.
I have no idea why, but I’m not questioning it.

b r i l l i a n t.

All your social channels → covered.
All your writing tones → covered.
Local fax machines → somehow also covered.

Second thing: the in-depth comparison.

And then just click whatever orange button. Trust the process.

W O W. They’ve mastered the forbidden art of explaining what typical SaaS discovery feels like.

• employee feet pics

Not my vibe. Might be yours. Not judging.

• spicy.mov

Haven’t enjoyed those retro sounds in a while. Thanks, PostHog!

• Long Term Contract Template.docx

I don’t think they’re chasing the super-enterprise’y stuff. But might be wrong.

The navbar. The left side of it actually

• Product OS

So I started with this one, and because I’m a tech guy, my brain immediately went: hmm, what’s the structure of this thing?

My dev GTM brain kicked in. There’s so much here you can use and so much shareholder value you can accidentally drive up.

Then my developer-marketer brain turned on. Wait a minute… this information architecture is actually brilliant.

First, you give your NICP (not-so-ideal-customer-profile, should trade-mark that) the option to browse all your products, because they don’t know what anything is yet.

Then, for the more aware (or already active) users, you give them search.

Then you guide them into the most popular products - the ones that probably drive most of your revenue.

After they’ve looked at those, you nudge them toward the new stuff (ka-ching).

And finally, you do a similar thing again, but this time you show your product lineup sorted by category.

Isn’t that perfect for every audience, no matter their maturity with your product?

You can also browse it like a Windows File Explorer for PostHog’s products, which honestly feels way too on-brand.

Okay, back to business.

In simple terms: think of every page and sub-page in Product OS (no matter how you got there) as a product page written in a mix of technical and non-technical language - something both you (the dev) and your boss (not necessarily a dev) can understand and get…sold (yeah, I said it - stage of the funnel, bleh.)

You’ll see an example in the next section. And to answer your next question: yes, the docs are tied to it too.

Web Analytics - the most popular product

Now we’re talking. Slidedeck energy. Shareholder value in the air.

You know what my boss (he’s half-technical, half-not) is always looking for?
“Why this and not that?”

Feature comparison table? Just scroll down.

Case studies? He loves those and yes, you can download them right there too.

Transparent pricing so he can convince the ultimate money boss in the company?
Yep. Also down there.

Not enough? Dude… click the little PDF icon in the upper-right corner and grab yourself a good ol’ slide deck.

You covered? Great. What’s next?

(Oh and don’t forget to check the comments on each slide. Pure gold)

Demos? There you go. Video-style. Perfect. Don’t forget about that cool-lookin font for the slide title!

Any product use-cases out there? Look no further!

Appetite comes with eating. Now you’ve got something for your boss and something for yourself - a tech tutorial to implement whatever your boss just decided you’re doing. Two birds, one stone.

But that’s not all. Scroll down and you’ll get all the docs you need.
(Yes, they’re clickable. Yes, they actually remembered to add the links)

You’re almost there. And no, your situation isn’t unique. Don’t even try to convince yourself. You’ll probably need other products from them too.

Which leads us to the next section of the slidedeck:

Bingo!

They even have paint.js in there (is there such a thing?!).Get creative - why not?

And there’s a command line too.

Looking for help? Reach out to them - I’m sure they’ve got you covered (not sure about taste though… check the disclaimer at the bottom of the deck)

Now you probably want to explore more, so go ahead and bookmark this one.

I’m not telling you yet where you’ll find your bookmarks later…but I will. Down the road.

How about the rest of the product pages - ehem, slidedecks?

• What

• Customer stories from those who love the specific product

• Product features characteristics

• Demos

• FAQs

• Pricing

• PostHog vs (feature comparisons)

• Docs

• Integrations (with other PostHog products or external ones)

• Paint.js embedded into the slidedeck

Same structure. Across the board. Every product.

Look at you, already mastering the navigation.

Did the social media oracles warn you it wouldn’t be this simple? Oops.

Just dive into the features you care about - or click literally everything like I do, lol.

Pricing

Let’s talk some business.

• Plans & usage-based pricing

We start with the free tier. Dev-approved, universally loved, obviously.

Scroll down and you immediately get the two essentials: usage-based pricing and a pricing calculator (something for your dollar-approving final boss).

But dude… this is wild. You have to see this.

I maxed out their pricing, cranked every slider to the max, and found the final price.
Dude… something’s missing. WHERE is the “Contact Sales” button?!

And then the last bit: a feature comparison with everyone else.
Why is that in pricing? I have no idea, but I respect the chaos (sometimes).

Yeah, there are addons too. I’m not covering them. Go explore. Next!

• Founder stack

Basically they’re doing tech sales, devrel, advocacy for PostHog-as-an-all-in-one-platform - for startup founders - using product pages, docs, the blog, the startup program, and yes, even the merch store. All crammed into one step-by-step journey page.

• Startups

Nothing more, nothing less. PostHog’s Startup Program. The essentials are right underneath.

What’s next? Pricing philosophy, How we do “sales”, side project insurance, You’ll hate PostHog if... I covered all of those somewhere up there or below (not sure at this point). There are four more in here but Watch a demo and Talk to a human already got covered as well. So let’s focus on the final final two (yes you read that right final twice, like your finalfinal.pdf).

• Don’t get discount bamboozled

Every product out there has an artificially inflated price. It’s all part of the dance - you haggle, they pretend to be generous, everybody wins.

Does PostHog play that game?
Bro.
No.

They went full Extreme Discounts™ instead. Watch this. I’m sold.

What’s best, though? Here’s what you actually get discounts for:

Dude, their sales folks are absolute brainiacs. Call your Chief Sales Officer and tell them to hire these people - they’ve clearly got more jokers up their sleeves.

• Social validation for enterprise

Man, I’m really not into those shiny enterprise’y certificates and badges.
You’ll need another human to explain what any of it actually means.

Docs

You can search them in multiple ways (PostHog AI, the search bar, etc.). But at the highest level of their info architecture, the starting point is either this or that:

So yeah - pick whatever works for you.

By the time you open the docs, you more or less know what you’re after anyway. And once you’re in the product section you wanted, you get this neat, super navigable doc with stuff like:

• Features of the product you’re looking into

• Getting started instructions

• Code snippets in different languages (for some of the their products you would also have SDKs, support for different frameworks or even API references)

• Best practices & troubleshooting

• Tutorials, guides, FAQs

• Integrations info

• Glossaries of concepts and terms

• etc.

Looks like you’ve got everything you need in one place. And look! You can even set a bazillion James Hawkinses as your background image (that’s what you came here for, right?! )

And you can do all of this without even leaving the current window (usually).
Just use the upper-left corner to jump between product docs and then teleport yourself back to wherever you were before the inevitable docs rabbit hole sucked you in.

What else lives in the docs tab?
More tutorials (for when the product docs didn’t quite hit). Dashboard templates so you or your boss don’t have to rebuild dashboards from the Stone Age. And Tracks, which is basically PostHog Academy… kind of. Early days.

Community

There are a few interesting things here. Let’s dive in.

• PostHog newspaper

All the inside + outside news from PostHog: anniversaries, feature requests, changelog updates, blog posts, Slack lore, forum questions. Neat. Is there a media-company editor hiding behind this? Hmm..

• Forums

PostHog’s Q&A forum - developer success incarnate. You show up here when you’ve got a problem with their stack (or when you panic-google). Use the categories on the left. Thank me later.

• Merch Store

If you’ve read all this and still don’t want one of these bad boys, you’re joking.

Got ideas? No worries, bro - toss an issue on GitHub like a civilized dev. Voila.

Also, my personal favorites: data_funnel.thing, lawnmower.thing, codebase.txt, PostHog duct tape.

• Events

A map of worldwide events where you can chat with the PostHog team (I think. Probably. Maybe.)

• Cool tech jobs

Thinking about working for a cool company (maybe PostHog)? This is the ultimate job board. LinkedIn Pro can’t compete.

• Newsletter

What are you even doing here if you’re not subscribed yet?!

• Blog

I know, I know. There was the newsletter, then the newspaper, and now there’s the blog. I’m too dumb for this. You figure it out yourself, okay?

• Product engineers hub

Lessons learned and publicly dropped by PostHog’s product engineers? Yes, please.

• Founders hub

It’s on the right side of the screenshot. You’ll figure it out.

Company

Hmm, looks promising. Let’s dive into it.

• About

  

  About is… well, about right. You get the jazz. Now, what are the things you absolutely can’t miss?

  • 15 reasons why PostHog might be wrong for you

    

  • Protection against viral usage spikes

If I had to summarize this page: transparency everywhere. Product, business, people.
Alright, next!

• customers.mdx

A list of customers with potential case studies, notes, and the PostHog product(s) they use. If your boss loves comparing “how other companies do it,” send him this way.

• Blog

We’ve already talked about that.

• Handbook

It’s basically the public backstage pass to how PostHog works - people, team, processes, religion, all that jazz. If you’re only going to read one thing, pick The Book of PostHog.

• Roadmap

Easy. It’s what they’re gonna build next - straight from public pull requests + votes.
Honestly… fair enough.

• Changelog

The key thing here: PostHog doesn’t ship monthly or on a light-year schedule.
They ship in small, fast chunks.

• Media

Not sure they even need this. James basically covers the entire internet on his own, lol.

• People

A bunch of graphics and tiny blurbs about everyone behind PostHog. It’s not a yearbook… but it’s basically a yearbook.

• Small teams

You can see what’s the size of each team with hedgehogs unit and what percentage of them think pineapple belongs on pizza. Also, almost forgot, you can check their team goals there too.

That’s basically it. ClickHouse team? My favorite. Who doesn’t love ClickHouse?!

• Careers

That’s where you apply, I guess…but might be wrong…

• Like and subscribe

Links to their socials - so smash that subscribe button, bro! That’s how the YouTubers shout it nowadays, right?

• More

Starting from the bottom: system status. The standard “is everything on fire?” page every devtools site has. Next. Keyboard shortcuts. Let’s stop here for a minute.

Plenty of nice things here, but one you cannot skip: Open display options.

C’mon. James Hawkins as the cursor and hedgehogs in cubicles. If that doesn’t sway the guy below toward PostHog, nothing will.

Alright, next one. Sexy legal documents. I’m into it. HIPAA. SOC. DPA Generator - could be useful, doesn’t have to be. Your call. Depending what you do on a daily basis.

Okay, Privacy policy. Yes, it’s for lawyers, but if you’re not one, don’t worry, it’s still oddly enjoyable. Same deal with the Terms.

What’s that Things that spark joy folder.

• Hedgehog mode

Crashed the game. Totally worth it though!

• HogWars

Can’t play those arcade games, sorry!

• Dictator or tech bro?

  

  Dude, I’m not touching this one. It’s basically the internet’s most re-taken quiz at this point.

• Photobooth

  

It’s the wedding thing. But PostHog-style.

• HogPaint

I wish it actually helped with taste, despite what it claims down there.

• Coloring book.pdf

Have a kiddo? Print them one!

• Post-It note training

I know what you’re thinking: you already have more certificates on your to-do list than you have free weekends.

I’d leave this beast for later too… but watch the video, and when you finally pass the training, flex it on LinkedIn. Of course.

• 404 page

This one looks familiar.

• DeskHog

It’s out of stock but you better check that out! You haven’t seen a better piece of hardware on the World Wide Web.

The sidebar. The right side of it actually

This thing is really simple. It’s your admin plane.

Think of it as the bottom-left Start button in Windows Millennium - admin-ops edition.

Here’s what you can actually do there with PostHog:

• Create your PostHog account

• Use the search bar to find anything PostHog-related

• Chat with the PostHog AI chatbot

And yes, the chatbot is actually trained properly and actually useful. I asked it about a problem, and it pulled up a GitHub issue and community forum threads with similar problem.

It’s here to help, not to chit-chat. Look how fast he changed the subject in our lovely convo.

If you’re drowning in windows already, the bookmarks manager (discovered it finally) is your lifeboat. Check the cool little option down there. Trust me.

Or simply go to your account dashboard. That’s it. Sweet and simple.

What now

Exploring PostHog’s website is like playing GTA: San Andreas. You’re doing the missions but also constantly hunting for easter eggs. (Ekhm, side quests)

And I know exactly what you’re thinking at this point:

“What’s the conversion rate on this thing?”

Dude.
Are you James Hawkins or what?

Devtools Onboarding Credo

1. Make them feel welcomed and comfortable, but not like they’ve joined a cult (yet).

2. Give simple, specific steps to get started. No 50-step “quick starts.”

3. Information overload kills curiosity faster than a 404.

4. Interact only if needed. Be available, not clingy. Let them breathe.

5. Your tone is your brand. If it feels like a robot wrote it, they’ll assume one did.

Building developer participation

You nailed onboarding. The dev’s happy. You’re happy. They’re building stuff and even bragging about it.

Perfect. Now what?

Now you level them up.

Recognition. Access. Cool toys. Maybe a hoodie they’ll actually wear.

Because every developer wants the same thing: to feel like they’re part of the guild, not just another signup.

Last words with mission-critical tips

Reply fast.
Check in once they’re rolling, not to sell, but to spark.
And never mistake quiet for disinterest.
They always watch, read, listen (even if they don’t).

The origins

It’s somewhat tied to another piece I wrote recently - The ongoing quest for hidden gems in developer marketing and devrel. Barely scratching the surface there, but it’s just a start. There’s so much good stuff out there that it’s honestly hard to keep up.

The value of those resources is, of course, subjective. What one person finds incredibly useful, someone else might scroll right past and that’s never going to change.

Then there’s the whole other challenge of actually finding those pieces organically (algos are not always great at recommending the right stuff).

At the end of the day, we’re all constantly learning. We read, listen, and watch a ton of content every week and every once in a while, something clicks. An idea, an inspiration, some lessons learnt.

The idea

Sweet and simple.

Weekly Goodies

Short, under-two-minute reads highlighting the best Dev Marketing and DevRel insights I’ve come across and went through end-to-end recently.

I search and keep track of them so you don’t have to.

The format

Check the section below, but technically (unless there’s a shared reason):

• <resource_type> <resource_title> - <author>

  • <reason_why_it_lands_in_weekly_goodies>

The last part is the important one. Like I mentioned above, the value of these resources is always subjective. I just want to give a short reason why each one stood out and why it ended up here.

This week Weekly Goodies

• [Book] Picks and Shovels: Marketing to Developers During the AI Gold Rush - Prashant Sridharan

• [Blog Series] DevRel Guide to Business - Matty Stratton

Why both of those land in this week’s issue?

Honestly, because they both present true end-to-end system thinking. There aren’t many resources out there that walk you through things hands-on and strategically at the same time, connecting multiple problem domains, and sharing what works (and what doesn’t) in the developer marketing and DevRel world.

There are systems and layers to this game.

Each of these resources is different in scope and content focus, but both deliver real, actionable insight.

Prashant is currently Head of Product Marketing at Supabase, and Matty leads Developer Advocacy and Docs at TigerData (the team behind TimescaleDB). Those titles alone don’t need to guarantee they get it, but once you go through their content, it’s more than clear that they’ve learned their ropes and know a thing or two (or actually a ton).

Weekly Goodies Archive

Ever been in that situation where you’re chatting with your best buddy, want to recommend something great, and suddenly remember this amazing thing you read recently, but can’t recall what it was?

What if that happens after reading Weekly Goodies? Don’t worry, I’ve got you.

• Weekly Goodies Section: helpful, but yeah, not an ultimate solution. I just want to give you a few anchor points, not lock you into one.

• developer-led/links GitHub repo: you’re welcome

Keep up learning and have a nice weekend everyone! 🤜🏻 🤛🏽

Where to start

The same as with Discourse and Slack, you’ll want to start by answering a few key questions. The kind that help you figure out what to track and why. Here are some examples to get you thinking:

• What kind of people are joining your server, and where are they coming from?

• How are they finding your community and what’s their onboarding experience like?

• What helps them quickly understand why your community is worth their time, and what keeps them around for the long haul?

• What are members actually doing once they’re in?

• Where are the main conversations happening?

• Are you attracting high-intent members (vs. random passersby)?

Ultimately, your goal is to keep activating and delivering value to as many members as possible consistently. That’s what a strong dev community is built on.

And this is where Server Insights start to earn their place.

Tooling Intro

Once your community hits 500 members, you unlock a hidden Discord feature, that I’ve just mentioned. Server Insights.

The goal of this tool is simple: help you understand your community through data and direct your efforts toward what actually helps it grow.

But what can you actually track?

Server Insights Essentials

Quite a few things, actually. Let’s start with the big ones, then we’ll move to the bare essentials.

IMPORTANT ONES

• Growth & Activation

  • New Members

  • Total membership over time

  • Server leaves over time

  • How many new members successfully activate on their first day

• Engagement

  • Total Messages Sent

• Audience

  • How long have they been a member of the server

BARE ESSENTIALS

• Communicators: server members that has talked on the server (posting in text channels or talking in Voice channels) commonly known as your active users (in Discord’s terms: sent at least one message or viewed at least three channels)

• New Member Retention: percentage of new members that return to your server after a week

Referrers - Dev Community Gold

Server Invite Links. This is the one you’ll want to pay close attention to. It gives you a clear view of your most popular invite links and top referrers. That, in turn, helps you see who’s actually fueling your growth so you can double down on what’s working.

You can find more about invites here. There’s plenty of room to get creative with this. Think about building a light referral or recommendation system around it. And hey, maybe throw in a bit of company swag for your top referrers while you’re at it.

What about data retention

When it comes to how far back you can look, Discord’s data availability breaks down like this:

• For non-Partner and Verified servers: 120 days back

• For Partner and Verified servers: back to the point at which your server was Verified or Partnered

What’s next

We’ve spent some time digging into the developer community side of things, now it’s time to switch gears. Next week, we’ll dive into some developer marketing and developer experience topics (including hedgehogs).

But before that…

This Saturday, I’m opening a new section in my newsletter called Weekly Goodies - short, under-two-minute reads covering the best dev marketing and DevRel insights we’ve come across that week.

Stay tuned 🫡

Subscribe now

If you’ve ever tried to make sense of what’s happening inside your Slack community, you’ve probably realized one thing fast: Slack wasn’t built with community analytics in mind. It’s great for conversations, sure. It’s where devs hang out, swap ideas, and occasionally (okay, often) drop the perfect meme. But when you need to actually quantify all that buzz, good luck.

Unlike Discourse, where metrics are baked right in, or Discord, which we’re gonna cover next week, Slack makes you dig.

So why do so many developer communities still choose Slack? Because it nails what devs care about most, which is simplicity, flexibility, and integrations. It’s where people already are during their workday. The challenge isn’t getting them to talk. It’s understanding what all that talking means.

In this one, we’ll break down what’s actually measurable in Slack, what should be measured, and how to bridge that gap. Whether you’re running a 100-member workspace or a 10,000-member one, we’ll help you find signal in the chatter (and maybe even justify keeping that pricey Slack plan to your boss).

Prerequisites

I don’t like using too many words to convey crucial concepts. If you’re running a Slack-based community and want to get a real sense of where it stands, there are three main things you should know:

• Admin Analytics Dashboard

• Admin Analytics API

• Message Activity Analytics

… depending how deep you wanna dig.

Quick ops note: what you actually get access to depends on your pricing tier. As of now, here’s how it breaks down:

• Pro tier: gives you access to the Admin Analytics Dashboard, which is solid if you just want quick visibility. But if you’re looking to automate things or pull metrics into another reporting tool, this isn’t the one as you’ll need to manually visit the dashboard every time or download a .CSV file. Which brings me to the next tier.

• Business+ tier: his is where you unlock all the goodies. You get everything from the Pro plan, plus Message Activity Analytics and the Admin Analytics API, which lets you automate monthly reports (more on that below).

Analytics Landscape

No matter which platform’s analytics we’re talking about, they all come with a long list of metrics to track. The real trick, though, is figuring out which ones actually matter to you and deciding which are worth keeping an eye on.

Slack is no exception. You can find the full list of available metrics (there are 81 of them!) along with explanations of what each one means here. But let’s zoom in on what’s truly worth your attention.

At the end of the day, here you’ll probably care most about two big categories: brand awareness and activation. And here’s what Slack has to offer (already pre-cherry-picked):

• Brand Awareness Metrics

  • Membership

    • Total members

• Activation Metrics

  • Membership

    • Monthly active members

  • Public & Private

    • Where people are reading

    • Where messages are sent

  • Messages and Files

    • Messages sent

  • Channels

    • Members who posted

    • Messages posted by members

Of course, you’ll always need to course-correct based on your specific goals, but the set above should cover most of what you need.

How to go about the tech around it

It all depends on what you already have in place, but generally, there are three main approaches. The intention is the same across all of them:

Understand what’s going on with their community and based on that build value for their members and their company

The three approaches are:

• The New Guy: you’re fairly new to the game and just want to get a handle on what’s going on, without diving too deep into the tech side. In that case, you’ll be fine with occasional visits to the Slack Admin Analytics Dashboard, downloading the data as a .CSV, and manually importing it into a BI tool of your choice when you need to analyze some data snapshots

• The Mature Community Techie: you’ve been around long enough to know what matters. You can code, and you already have a reporting stack you want Slack to feed into. For you, it’s all about the API as you want to automate data pulls and pipe them into whatever tools you’re using (Airtable, Notion, or your own data warehouse setup maybe).

• The Curious Community Builder: you’re not deep into code (yet), but you’ve got that experimental streak and know your way around AI tools. You fire up v0, throw in a few credits, and prompt your way to glory:

  “Build me a dashboard that displays my monthly Slack admin analytics metrics from my real workspace.”

In the latter two approaches you’ll just need two things basically:

SLACK_TEAM_ID: you can find it here
SLACK_BOT_TOKEN: you'll get it once you create your Slack app, (you’ll just need to specify the right scopes for accessing resources)

And voilà, you’ve (almost) nailed your Slack community understanding and reporting game!

What’s next

That’s a tough one as my brain explodes with new ideas almost every day. But jokes aside, next week we’ll wrap up this mini-series on community platform analytics with a look at Discord.

After that, we’ll dive into the world of developer marketing for a bit. I’m also toying with the idea of launching a shorter weekly writing format, something quick, useful, and easy to digest.

Stay tuned! 🫡