Book Review: The Problem-First Method by Kevin Dias

The Problem-First Method by Kevin Dias opens with a move so confident it nearly disarms criticism on contact: Kevin Dias admits, in his introduction, that the book isn’t revolutionary. Problem-first thinking, he notes, has been around since ancient tribes weighed the pros and cons of inventing fire. The irony he’s chasing isn’t that the idea is new — it’s that despite being obvious, almost every team still skips past the problem and falls in love with the solution.

Then, in a flourish that tells you exactly what kind of writer he is, he applies his own method to the book itself and asks: what problem is this book solving? His answer becomes the spine of everything that follows. Customers no longer arrive with pains and frustrations; they arrive armed with solutions — “Do you have Autopay?”, “When is SMS coming?”, “Do you integrate with Slack?” — and that sophistication tempts builders to treat the feature request as the problem and start shipping before they’ve understood anything at all.

The book is organized into four parts — The Trap, The Mindset, The Framework, and Building with Discipline — and its greatest strength is that Dias earns every abstraction with a scar. He is the founder behind Ambiki, an electronic medical records platform for pediatric therapy practices, and the anchoring story of the entire book is his own most expensive mistake. On a 2023 sales call, a speech-therapy practice owner leaned in and asked whether the product had Autopay. A competitor, SimplePractice, had it; Ambiki didn’t. Dias heard himself say “we can build that” — and, as he puts it, the trap was set.

The team mobilized, wrote a Feature Alignment Document, convinced themselves it was airtight, and shipped a groundwork feature consolidating sessions into a single monthly invoice. He braced for confetti. He got silence. When they finally asked why, the answer was devastating in its simplicity: “We like being in control.” These were practices navigating complex insurance flows and parents who occasionally needed a few extra days to pay; automation felt like risking the relationships their business was built on. Three months gone. The real pain — the wasted time chasing balances and reconciling accounts — had been sitting in the support tickets the whole time, dismissed as “polish” because, in Dias’s sharpest formulation, competitors are loud, feature requests are loud, solutions are loud, and real problems are quiet. They hadn’t been building for their customers. They’d been building for their own insecurity.

That honesty is the book’s signature. Part I widens the lens with cautionary tales beyond Dias’s own walls — Juicero, Google Glass, the Air Canada chatbot that invented a refund policy in court — to show that smart people fall into the same traps repeatedly. Part II (“The Mindset”) sharpens the diagnostic instinct, and its centerpiece is “The Three Disguises,” Dias’s taxonomy of how solution-chasing sneaks past careful teams wearing the costume of good product management. The first and most common, “Feature Parity Theater,” sounds like market awareness (“our competitor just launched it; it’s becoming table stakes; we’re losing deals”) but is, in his words, abdication. The recurring “faster horses, not cars” warning runs underneath it all: if you build only what customers can already imagine, you’ll never invent the future, you’ll just become a copycat.

Where many books in this genre stop at philosophy, Part III hands over actual tools, and Part IV stress-tests them in the field. Dias gives readers the Feature Alignment Document (pointedly “not another PRD”), a 10-Question Problem Validation Checklist, a “Problem Atlas,” and a chapter on the Five Whys subtitled, correctly, “Why Your First Answer Is Usually Wrong.”

That Five Whys chapter is a small masterclass: a $12K account churns after ghosting the implementation lead, the obvious read is a trial-conversion and contracting problem, the obvious fix is to force annual contracts and kill the self-serve Stripe signup — and Dias’s nagging refusal to accept the first tidy answer, prompted by a suspiciously empty support history, models the discipline the whole book is selling. Best of all, these aren’t just described; the appendices include working templates for the FAD, the validation checklist, the Problem Atlas, and a Five Whys worksheet, which makes the book genuinely usable rather than merely persuasive.

The later case studies are where the book’s emotional intelligence shows. “The Discount Code We Didn’t Build” is the standout — a marketing colleague asks, a month before a major conference, whether the product supports discount codes, and Dias narrates the three seconds of internal monologue (“that’s just a Stripe integration, we could knock it out in a week”) before catching the real motive underneath: he wanted to prove Ambiki was a “real” company, and real companies have discount codes. It wasn’t about solving a problem; it was about protecting his identity as a competent builder. Naming ego as the engine of feature creep — “not should I build this, just how” — is one of the most useful insights in the book precisely because it implicates the reader’s self-image rather than their process.

If there’s a limitation, it’s one the book cheerfully concedes: the core idea is not new, and seasoned product managers will recognize the landmarks (jobs-to-be-done, the faster-horses parable, root-cause analysis). Readers hoping for a silver bullet won’t find one, by design — Dias promises a mirror, not a revolution, and the epilogue doubles down on this with admirable humility, insisting that problem-first thinking is a practice and not a destination, that the moment where it becomes automatic never arrived for him, and that he still catches himself three steps into a solution and has to back up.

The book is also most immediately at home in B2B SaaS; its examples live in that world, though the underlying discipline transfers cleanly to anyone who builds things for other people. None of this dulls its edge. The writing is crisp and funny, the structure is purposeful, the frameworks are practical, and the through-line — slow down, stay with the problem longer than feels comfortable, and measure success by what your customers can finally stop worrying about — is delivered by someone who has paid for the lesson in real shipped failures and is generous enough to show you the receipts.

Rating: ★★★★½

Verdict: The Problem-First Method by Kevin Dias is a sharp, funny, and unusually honest product-building book that turns its author’s own costly mistakes into a genuinely useful discipline. It doesn’t claim to reinvent the wheel — it claims to stop you from building one nobody asked for — and on that promise it more than delivers. For founders, PMs, designers, and engineers tired of shipping features that get launched and quietly ignored, this is close to essential.