The story so far
Twenty years building software. One consistent thread: I build things that help people build things.
I spent eight years writing code before I realized the best code doesn't matter
Not that technical craft is unimportant. The opposite—you can't build good products without understanding how things actually work. The constraints, the trade-offs, why estimates are always wrong.
But I kept watching teams ship elegant solutions to problems nobody had. Brilliant engineers building features that sat unused. The gap wasn't technical. It was understanding.
"So I crossed over. Not because I stopped caring about architecture, but because I cared more about impact."
The product years: learning what actually moves the needle
I spent a decade leading product teams through the full lifecycle—discovery, launch, growth, the messy middle where most products die.
The first lesson hit hard: good process doesn't save bad strategy. You can run perfect sprints and still build the wrong thing. What matters is having the right information at the right time, and the clarity to act on it.
So I started building intelligence systems. Not dashboards people ignore. Ways to surface the signals that actually matter—what jobs customers are hiring your product to do, where they're getting stuck, what opportunities you're missing because you're too busy shipping.
But the real win was watching teams stop guessing. When you have real intelligence about customer jobs, you don't need the loudest opinion in the room to win. You need the best evidence.
Then AI dissolved the boundary
For the past two years, I've been running my own practice—advising companies on product strategy, mentoring PMs, building tools. The work changed when AI stopped being a buzzword and started being a lever.
Here's what's different now: The gap between "what should we build?" and "let's ship it" is narrowing. PRDs become functioning code. Engineers become product thinkers. Product managers become system architects.
What does the human do when AI handles the execution?
So far, the answer seems to be judgment, taste, and system design. Strategy, not task management. The PM becomes an architect. The engineer becomes a product thinker. The walls between the disciplines are coming down.
I'm spending 2025-2026 running projects to understand this shift—testing workflows, building tools, sharing what breaks and what works.
What I believe
Intelligence beats intuition
The best product decisions come from understanding customer jobs deeply, not from having the most senior title in the room.
Discovery before solution
Most teams rush to build. The best teams spend longer understanding the problem. Counterintuitively, they ship faster because they build the right thing the first time.
Systems over processes
Don't just adopt frameworks. Build capabilities that compound—research repositories, decision logs, feedback loops that get smarter over time.
Evidence over hierarchy
Data beats title. Always. But "data" doesn't mean dashboards. It means the specific evidence that would change your mind about a decision.
These principles work whether you're writing code, managing roadmaps, or designing agentic workflows. I've tested them through two decades of shipping software that people actually use.
I'm not claiming to have all the answers
The landscape is shifting too fast for certainty. But I'm figuring it out in public, sharing what I learn at The Boundary, and inviting others to explore with me.