I’m a product leader who has spent two decades building things across startups, gaming, enterprise software, and consulting. The common thread: I’m drawn to the gap between how organizations say they work and how they actually work.

I work in enterprise software, where I sit between customers and product teams. My job is to understand what large organizations actually struggle with when adopting complex platforms and translate that into product strategy. That means running advisory programs, synthesizing patterns from hundreds of customer conversations, and making sure the signal reaches the people making roadmap decisions. Before that I worked in gaming, built products from zero to one as an early startup employee, and consulted for founders trying to figure out what they were really selling.

What I think about

The best products don’t announce themselves. They solve problems in ways that make you wonder how you managed without them. Getting there requires understanding the system around the product: the incentives, the politics, the gap between what customers ask for and what they need.

I write about that gap. Most of my posts start from the same instinct: something looks like it should work, but doesn’t. OKR systems that hit every target while the business stagnates. Prioritization frameworks that everyone agrees with and nobody follows. AI adoption strategies built on demos instead of workflows. The interesting question is usually not “what went wrong” but what game were people actually playing?

I think in systems. I look for historical patterns that explain current ones. I believe intellectual honesty is a competitive advantage and that most organizations are bad at it. And I believe the hidden skills of product management are sensing what others miss and making sense of what it means.

What I’ve learned

A few things I’ve come to believe after twenty years of building products:

The best product decisions come from connecting customer understanding to strategy. Not surveys. Not NPS. Actual patterns in what people do, mapped against what the business needs to be true. I’ve spent most of my career building the systems that make that connection possible.

The most undervalued skill in product is translation. Customers describe symptoms. Engineers want specifications. Leadership wants strategy. The work is turning one into the others without losing the signal.

I’ve built products at every stage, from first commit to mature platform, and the thing that transfers across all of them is comfort with ambiguity. The “we don’t know if this works yet” phase is where the interesting decisions happen.

This blog

I write for product leaders, builders, and technologists who want frameworks for thinking, not templates for acting. The best response to a post is a specific counterargument. The second best is “this changed how I think about X.”

If you want to talk about product, systems, AI, or anything I’ve written about, reach out. I’m always up for a conversation with someone who’s thinking hard about the same problems.