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, building tools, and now shaping that work into Cortex22: an AI implementation studio for companies that need operational outcomes, not another layer of tools.
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 2026 building Cortex22 around that shift—turning AI from experiments and licenses into practical systems embedded where real work happens.
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. Cortex22 is where I turn the useful parts into implementation work; the writing now lives in its Thinking section.