Value beats features.
Developers care about what a product or feature enables them to do. I want them to understand why they should care. What becomes easier, faster, or possible that wasn't before.
Thinking Through Technology
I've spent a lot of my career making sense of complicated technology. Then figuring out how to make it make sense to someone else.
These are a few things I keep coming back to.
The same technology can tell different stories.
The work is finding the right one to tell.
Understanding a technology means getting into the details. Explaining it means knowing which of those details matter.
A good technical product shouldn't have to lose its depth to be approachable. The challenge is figuring out which parts matter to which people, and finding a way into the story.
There's a shape to it, even if I don't think of it as a "process" necessarily.
I start with the problem, not the feature. What's annoying, what's slow, what's confusing about the way things work today. Then I think about who feels that. A developer, an architect, an engineering manager, an executive all look at the same product differently, and I'm interested in what changes depending on who's in the driver's seat.
From there I ask how someone's day is different after using it. Not what it can do, but what someone can now do because it exists. And if I can't explain that to someone outside of engineering, I probably haven't understood it well enough myself.
The four questions, if you're keeping score:
01
What frustrating thing becomes easier?
02
Who feels that pain?
03
How is someone's day different after using it?
04
Can I explain it to someone outside of engineering?
A feature is a starting point. The story is somewhere past it.
Feature
Role-based access controls for project resources.
↓
What it changes
Teams can collaborate confidently without worrying about giving everyone full access.
The same pattern shows up everywhere.
Automated API key rotation
That is not enough. I'd want to understand what changes for the team maintaining those keys.
→Better security without another maintenance task.
Vector search with configurable embeddings
→Developers find what they need instead of fighting search.
Real-time event streaming with automatic retries
→Applications stay responsive, even during traffic spikes.
Nothing here erases the technical detail. It just points it at something that matters.
Things I've Learned
Documentation is marketing.
A tutorial shouldn't be seen as just a set of instructions. It's an opportunity to tell someone what is important and how it can benefit them.
Good demos tell stories.
I like demos that let someone envision themselves solving a real problem. The technology is important. But there's usually a story underneath it.
Questions reveal friction.
If I keep hearing the same question from customers, from developers, or from sales, I want to dig into that. It usually means something isn't clear. Maybe the documentation needs work. Maybe the messaging does. Or maybe the friction is in the product itself.
Where I'd Start
Everything above starts with listening, not writing.
If I joined a new company tomorrow, I'd spend less time writing and more time listening.
I'd want to understand what developers love, what confuses them, what Sales hears every week, and what Product wishes customers understood better.
I'd sit in on calls. I'd read support questions. I'd watch people use the product.
Then I'd start connecting the dots.
Still Figuring It Out
I don't think there's a perfect formula for great product marketing. Every product, team, and customer is different.
These are simply the ideas I keep coming back to because they've served me well across developer relations, open source, technical enablement, and telling the story of a product well.
I'm sure they'll continue to evolve. I hope they do.