Stop building solutions in search of a problem.
Every product team says they start with the problem. Then a customer asks for a feature, a competitor ships something shiny, sales needs an answer, and suddenly everyone is racing toward a solution they have not fully understood.
The Problem-First Method is a practical guide for founders, product managers, builders, and teams who want to avoid that trap. Drawing from real mistakes and lessons from building Ambiki, Kevin Dias shows how smart teams drift into building the wrong things, why feature requests often hide deeper problems, and how to slow down just enough to make better decisions.
Through stories of Autopay, SMS reminders, AI chatbots, Google Glass, Juicero, and more, the book introduces simple tools like the Feature Alignment Document, discovery questions, stakeholder mapping, and a 10-question validation checklist.
This is not a book about moving slowly. It is a book about making sure your speed has direction.
Because the most expensive feature you will ever build is the one that solves a problem nobody has.
Stop building solutions in search of a problem.
Every product team says they start with the problem. Then a customer asks for a feature, a competitor ships something shiny, sales needs an answer, and suddenly everyone is racing toward a solution they have not fully understood.
The Problem-First Method is a practical guide for founders, product managers, builders, and teams who want to avoid that trap. Drawing from real mistakes and lessons from building Ambiki, Kevin Dias shows how smart teams drift into building the wrong things, why feature requests often hide deeper problems, and how to slow down just enough to make better decisions.
Through stories of Autopay, SMS reminders, AI chatbots, Google Glass, Juicero, and more, the book introduces simple tools like the Feature Alignment Document, discovery questions, stakeholder mapping, and a 10-question validation checklist.
This is not a book about moving slowly. It is a book about making sure your speed has direction.
Because the most expensive feature you will ever build is the one that solves a problem nobody has.
It started on a sales video call, the kind Iâd sat through dozens of times. A speech therapy practice owner leaned forward, eyes narrowing in that way that meant I was about to lose the deal.
âDo you have Autopay?â
I froze.
This was 2023, and Ambiki was just beginning to claw its way into the crowded EMR market. We werenât SimplePractice. We werenât Fusion. We were the underdogâa startup appealing to pediatric therapy practices tired of duct-taped spreadsheets and software that looked like it hadnât been touched since 1999. Every sale mattered.
And here was the question again. Not about our teletherapy platform. Not about our scheduling tools. Not even about the documentation workflows saving therapists hours each week. No. It was Autopay.
Our competitor had it. We didnât.
I nodded, trying to sound calm. âWe can build that,â I said. Inside, though, I felt like a kid bluffing through algebra homework, hoping the teacher wouldnât notice.
That was my mistake.
Because once you say we can build that, the trap is set. We mobilized the team. We wrote the Feature Alignment Document. We convinced ourselves it was airtight:
- Solo practices could automatically run credit cards after each session.
- Larger ones could do monthly billing.
- Some wanted copays only.
- Others wanted a Frankenstein mix of âcopays now, everything else later.â
It felt like progress. We even patted ourselves on the back for writing what we called a âproblem statement.â But in hindsight it wasnât a problem statement at allâit was more like a hostage note written by a solution demanding justification. Worse, it was a salad bowl of mismatched problems that shouldâve been separated and addressed one by one.
To get to Autopay, we first shipped a groundwork feature that let practices consolidate a patientâs sessions into one monthly invoice. These were speech and occupational therapy patients typically seen once or twice a week. Parents and practices wanted one easy bill to pay each month instead of eight or ten.
And then we shipped it.
I braced for fireworks. Surely the bigger practicesâthe ones we were chasing hardestâwould throw confetti and tell us weâd changed their lives.
Instead? Silence. A few tried it, then slipped away the way people do when they realize theyâve joined the wrong conference call.
When we asked why, the answer was devastating in its simplicity:
âWe like being in control.â
These werenât businesses built around swipe-and-go transactions. They were therapy practices navigating complex insurance flows, parents who sometimes needed a few extra days to pay, and staff who knew their patients by name. Locking everything into an automated schedule felt like putting their relationships at risk.
Thatâs when I realized we had confused their problem with our competitorâs solution. The real pain wasnât lack of Autopay. It was the time and energy wasted chasing balances, reconciling accounts, and processing payments one by one. They wanted efficiency, but not a straitjacket.
It hit me: we werenât building for them. We were building for our insecurity.
We saw our competitorâs feature, felt exposed, and grabbed the nearest hammer.
But Ambiki wasnât meant to be a SimplePractice clone. They served solo practitioners. We served multi-provider practices. Their problem wasnât our problem. Still, âcompetitor has itâ looked so convincing that it gave us permission to stop thinking and start building.
And thatâs the trap.
By the time we realized our mistake, weâd spent three months building a feature that never gained adoption. Three months we couldâve spent solving the actual problem: streamlining payment workflows. Better batch processing. Clearer aging reports.
None of those wouldâve sounded as impressive in a sales call. But all of them wouldâve saved our customers timeâwhich was the real pain all along.
The hardest realization came later: weâd had the answer in our support tickets the whole time. Complaints about âtoo many clicks to process paymentsâ and âcanât see who owes what at a glanceâ never felt urgent enough to matter. They felt like polish. They didnât look like strategy.
âCompetitor has Autopayâ sounded like strategy.
What Iâve learned since is that this is how the trap works. Teams get pulled toward the loud thing instead of the true thing.
Competitors are loud. Feature requests are loud. Solutions are loud. Real problems are often quiet. And if youâre not careful, youâll spend all your time chasing the noise.
Weâre not the only ones whoâve fallen for it.
In The Problem-First Method: A Framework for Innovative Product Builders, Kevin Dias makes an argument that sounds obvious until you realize how often it gets ignored: start with the problem, stay with the problem, and resist the pull toward a solution before you understand what you are actually solving. Dias is the builder behind Ambiki, a pediatric therapy EMR, and he uses that experience as the backbone of the book. He is upfront about not having a billion-dollar exit or a Silicon Valley reputation, and that honesty works in his favor. This is a book written from the trail rather than the summit, and it reads like advice from someone who has made the mistakes himself.
The structure is one of the book's biggest strengths. Dias divides the material into four parts that move from diagnosis to mindset to framework to application. He opens with "The Autopay Mistake," a story about building a feature simply because a competitor had it, and that single example sets up the entire book. Instead of lecturing readers about discipline, he shows what happens when discipline disappears. By the time he names the patterns, such as "Feature Parity Theater," readers already recognize them because they have watched him fall into the trap firsthand.
The practical tools are where the book earns its keep. The Feature Alignment Document, the 10-Question Problem Validation Checklist, and the Five Whys are not abstract concepts. They are usable artifacts with templates included in the appendix. Dias also resists the temptation to oversell. He calls the book a reset rather than a revolution, and that framing is accurate. The ideas are not new, but his contribution is helping builders notice the exact moment they stop being problem-focused, which is harder than it sounds.
Dias writes clearly and tells a good story. The iPod chapter is a standout, and his willingness to use his own failures keeps the book grounded and credible. His voice is conversational without slipping into filler.
If the book has a weakness, it is that many of the examples come from a single company in a niche software vertical. Readers outside SaaS may have to work a little harder to translate the lessons to their own field, though the underlying principles still apply.
The Problem-First Method is a sharp and useful book for product managers, founders, and anyone who decides what gets built. Dias has written something most product builders will recognize themselves in, and that recognition is exactly what makes it worth reading.