Last month, two teammates at Ambiki sat me down.
Not a standup. Not a 1:1. A proper "we need to talk" message. A literal intervention.
I'd been creating PRs at a pace that would've been unthinkable a year ago. Prototypes in an afternoon. Features roughed in overnight. AI had become an extension of my hands, and it felt incredible.
Except, and this is the part they were generous enough to say out loud, I had stopped doing the thing I'd spent years telling everyone else to do.
I had stopped starting with the problem.
I was building fast. Confidently. In the wrong direction.
The irony wasn't lost on any of us. I was weeks away from launching a book called The Problem-First Method, a book whose entire thesis is that skipping the problem is the most expensive shortcut in product. And there I was, seduced by my own velocity.
This book is more relevant today than the day I started writing it.
Because the cost of creating has collapsed. What used to take a quarter now takes a weekend. AI has made the building part of product development nearly free.
But the cost of building the wrong thing hasn't moved an inch.
It's still paid in customer trust. In team morale. In the opportunity cost of what we didn't build instead. In the quiet Jenga tower of complexity we stack into our products while swearing we're "moving fast."
Speed doesn't absolve you of direction. It just gets you lost faster.
If we can build almost anything, how do we decide what deserves to be built at all?
That's what this book tries to answer.
The Problem-First Method is available today. It's for founders, PMs, and builders who've felt the dopamine hit of a shipped feature, followed by the quiet horror of watching it go unused.
It's the book I needed five years ago. It's the book I needed last month. It's the book I'll probably still need six months from now.