Product theory.
A letter.

When I say "people first," I mean it two ways — and I mean both of them equally.

The first is obvious but still gets forgotten constantly: we are building for people. Real humans with real problems, real frustrations, real lives. The job of a product person is not to ship features. It is to solve problems. And you cannot solve a problem you haven't truly understood. That means getting close to your users — not just reading their data, but listening to their words, watching their behavior, and sitting with the friction they feel every day.

The second meaning is less talked about but just as important: the team building the product is the product. How we work together, how safe people feel to disagree, how much psychological safety exists in the room — all of that shows up in what we ship. A team that can't have a difficult conversation without it feeling like a confrontation will never build something truly great. Creating that environment is not a soft skill. It is the job.

I learned this by watching others get it wrong.

I've seen product leaders who position themselves at the center of everything — the decision maker, the visionary, the loudest voice in the room. And I've watched what happens to the teams around them. Engineers stop pushing back. Designers stop taking risks. Everyone waits to hear what the PM thinks before they share what they actually think.

That is not product leadership. That is a bottleneck with a title.

Leading from behind means creating the conditions for your team to do their best work. It means asking better questions instead of giving better answers. It means making it safe to say "I think we're wrong about this" — and then actually listening when someone does. It means your fingerprints are on the outcome, not the process.

The best product decisions I've been part of didn't come from me. They came from a room full of brilliant people who felt safe enough to think out loud.

This is the tension at the heart of product work and I don't think enough people talk about it honestly.

There is a fine line between conviction and stubbornness. Between pivoting and flailing. Between staying the course and refusing to see what the data is telling you. I've seen PMs who couldn't commit — who second-guessed every decision, reoped every roadmap item, kept the team in permanent uncertainty. And I've seen PMs who couldn't pivot — who fell in love with their original plan and ignored every signal that it wasn't working.

Neither builds great product.

The discipline I've built is this: when we decide, we decide. The team deserves to move with confidence, not hesitation. But I keep a quiet eye on the signals — user behavior, team friction, market shifts — and I stay genuinely open to the possibility that we're wrong. Not anxiously. Not performatively. Just honestly.

Agile isn't a methodology to me. It's a mindset. Deliver. Adapt. Repeat. Not because the framework says so — because the work demands it.

I share what's working. I own what isn't. I bring everyone along for the ride — not just when the story has a good ending.

This is not just a value. It's a practice. It means writing the retrospective even when the launch didn't go the way we planned. It means saying "I got that wrong" in the same meeting where you're asking the team to trust the next call. It means transparency as a default, not a reward for good news.

The teams that have taught me the most were the ones where learning happened in the open. Where mistakes became shared knowledge instead of buried history. Where "I don't know" was the start of a conversation, not the end of one.

That is the kind of product culture I try to build everywhere I go.