Notes • Thinking Through Technology

My job isn't to simplify technology.

It's to tell the right story.

I don't actually want to simplify the technology. But what I want to do is understand it well enough to explain it. 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.

Whenever I'm learning something new, I tend to come back to the same four questions.

01

What frustrating thing becomes easier?

I start with the problem, not the feature itself. What's annoying, or what's slow. What is confusing or just painful today.

02

Who actually feels that pain?

Is it a developer, an architect, an engineering manager, an executive.. they all look at the same product very differently. I'm interested in what changes depending on who's in the driver's seat.

03

How is someone's day different after using it?

Features describe capabilities. Outcomes describe value.
I want to know what can someone do differently because this exists.

04

Can I explain it to someone outside of engineering?

If I can't explain the idea to someone outside of engineering, I probably haven't understood it well enough myself.

Features are usually the starting point, not the story.

Before

More feauture focused: Role-based access controls for project resources.

↓

After

More outcome focused: 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.

The goal isn't to hide the technical detail. It's to connect it to something that matters.

Things I've Learned

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.

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.

Customer questions are useful signals.

If I keep hearing the same question from customers, or developers, or sales, that's an indicator that this probably needs attention. There is something to act on. Sometimes the answer is better documentation, or clearer messaging, or it might even be a problem with the product.

Where I'd Start

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.