An Interview with Kevin Dias: Author of The Problem-First Method

Kevin Dias is the founder and CEO of Ambiki, a healthcare technology company serving pediatric therapy organizations. A self-taught software developer and former CTO, he has spent more than a decade building products, leading teams, and helping organizations improve complex clinical and financial workflows. His unconventional career has taken him from investment banking to teaching English in Japan to founding a U.S.-focused software company from rural Tochigi. He is the author of The Problem-First Method: A Framework for Innovative Product Builders.

Tell us about your book.

The Problem-First Method: A Framework for Innovative Product Builders is a practical, story-driven guide for product managers, founders, engineers, designers, and leaders who are responsible for deciding what gets built.

The book explores a common but costly problem: teams often believe they are customer-focused while quietly drifting into solution-first thinking. A customer asks for autopay, an executive wants AI, a competitor launches a new feature, and the team begins building before fully understanding the underlying problem. The result is often wasted time, unnecessary complexity, and polished products that customers do not actually need.

Drawing on my experience building Ambiki, a healthcare software company, as well as case studies involving Google Glass, Juicero, the iPod, Spotify, and Air Canada’s chatbot, the book shows how smart teams end up solving the wrong problems. It also introduces practical tools – including the Feature Alignment Document, the Five Whys, stakeholder constraint mapping, and a 10-Question Problem Validation Checklist – to help teams make better decisions before committing significant time and resources.

The central message is simple: building faster is not the same as creating value. This is especially important in the age of AI, when teams can move from idea to working software faster than ever. The competitive advantage will increasingly belong to the teams that are best at choosing the right problems – not simply producing solutions more quickly.

The book is candid rather than academic. I share mistakes I personally made, features that failed, and moments when competitive pressure or enthusiasm pushed us in the wrong direction. The goal is not to present a perfect formula, but to give readers a repeatable discipline for asking better questions, recognizing when they have drifted, and building fewer things that matter more.

Why did you want to write a book?

I wanted to write the book for two reasons.

Professionally, I kept seeing the same pattern repeat: smart, capable teams would say they were focused on customer problems, but under pressure they would jump straight to features, competitor comparisons, or whatever solution felt most urgent. I had made that mistake myself more than once. Writing the book gave me a way to examine those failures honestly, identify the patterns behind them, and turn what I had learned into a practical framework that other product builders could use.

Personally, I also wanted to preserve these lessons for my children. Much of what we learn through building companies, leading teams, and making mistakes exists only in conversations and memory. I wanted to create something lasting that explained not only what I had learned, but how I had learned it – including the failures, doubts, and wrong turns.

I did not write the book because I believe I have product development completely figured out. I wrote it because I have made enough mistakes to recognize the traps, and I wanted to help other founders, product managers, engineers, and leaders recognize them sooner than I did.

Why did you choose to self-publish?

I chose to self-publish because I wanted control over the entire life of the book – its positioning, design, pricing, distribution, and how quickly I could respond to readers and opportunities.

Traditional publishing can offer valuable reach and credibility, but it also moves slowly and often requires authors to give up flexibility. Because I was not already a well-known author with a large platform, I felt I would still be responsible for much of the marketing while having less control over the product itself.

Self-publishing also allowed me to experiment with ideas that would be difficult through a traditional model. For example, readers who purchase directly receive three additional ebook copies they can share with colleagues or friends. That makes the book easier to use with teams, book clubs, and professional-development groups.

Most importantly, self-publishing let me build a direct relationship with readers. I can hear what resonates, update the supporting materials, create new bundles, and continue improving how the book is used without waiting for a publisher’s schedule or approval.

The decision itself also reflects the book’s message: start with the problem you are trying to solve rather than automatically choosing the most conventional solution. My goal was to get a useful book into the hands of product builders while preserving the flexibility to keep learning and iterating. Self-publishing was the best fit for that goal.

What tips can you give other authors looking to self-publish?

My biggest advice is to start preparing for the launch much earlier than you think – especially when it comes to Advance Review Copies, or ARCs.

I was so focused on writing, editing, cover design, formatting, print proofs, metadata, and distribution that I underestimated how much time reviewers need. I only began serious ARC outreach after the book had already launched, which meant many of the strongest editorial reviews arrived months later. In hindsight, the lesson seems obvious: identify reviewers, bloggers, podcasters, and early readers well before publication, and give them plenty of time to read the book.

I would also encourage authors to learn from people who have already been through the process. Self-publishing requires you to become a writer, publisher, marketer, distributor, and publicist – often all at once. You will not know everything, so ask questions, study successful independent authors, and build your launch plan earlier than feels necessary.

At the same time, do not let the fear of doing something imperfectly stop you from publishing. Some parts of the process only make sense after you have experienced them firsthand. You are going to make mistakes, miss opportunities, and occasionally step on a rake you did not see coming. The important thing is to learn, adjust, and keep going.

Finally, think beyond launch week. I wrote The Problem-First Method to be useful for years, not to chase a short-lived trend. A slow, steady stream of reviews, articles, recommendations, and readers can be more valuable than one large burst of attention followed by silence.

So my main advice would be:

Start ARC outreach early.
Give reviewers more time than you think they need.
Learn from experienced independent authors.
Treat marketing as part of publishing, not something that begins afterward.
But do not wait until you understand everything before releasing the book.

What was your steepest learning curve during the publishing process?

The hardest part has been discoverability. Creating a good book is largely within the author’s control; convincing the right readers that it is worth their time requires credibility, repetition, relationships, and patience. I also learned that publishing the book is not the finish line. It is the point when the longer work of building awareness and trust begins.

In a way, that experience reinforced the book’s own message. It would have been easy to imitate every tactic used by other authors, but I had to keep returning to the underlying problem: how do I help the specific people who would benefit from this book find it, trust it, and share it with their teams?

How do you deal with writer’s block?

Exercise is the most reliable way for me to get my creative juices flowing.

If I am stuck, I will usually go for a run, ride my bike, or do something physical that gets me away from the screen. Once my body is moving, my mind tends to loosen up, and ideas that felt blocked often start connecting on their own.

I also lower the standard for the first draft. If I sit down expecting polished writing, I can get stuck trying to perfect the opening sentence. So I start with the story, scene, or example I know best and allow myself to write it badly.

Talking the idea out loud helps too. Sometimes I explain the point as if I am answering a podcast question, then use that as the raw material for the written version.

Most importantly, I return to the problem the piece is meant to solve. Writer’s block often happens when I am trying to sound clever instead of trying to be useful. Exercise helps clear the noise, and once I remember what the reader needs, the next sentence usually comes more easily.

Tell us about the genre you wrote in, and why you chose to write this sort of book.

The Problem-First Method is a business and product-management book, but it is also partly a professional memoir. It combines practical frameworks with stories from my own experience building software, leading teams, and making product decisions under pressure.

I chose this genre because I did not want to write a dry textbook or a collection of abstract management theories. Product development is messy, and the lessons tend to become clearer when readers can see how a decision actually unfolded – what we believed, where we went wrong, and what the mistake cost us.

The book includes tools such as the Feature Alignment Document and the 10-Question Problem Validation Checklist, but the stories give those tools context. Readers see the framework applied to real situations involving customer requests, competitive pressure, failed features, difficult trade-offs, and products such as Google Glass, Juicero, Spotify, and the iPod.

I also wanted to write the kind of business book I enjoy reading: practical enough to use, honest enough to trust, and entertaining enough that it does not feel like homework. My goal was for readers to come away with a clearer way to make product decisions, but also with stories and examples they would remember the next time someone says, “Our competitor has it, so we need it too.”

What is the most expensive mistake a product team can make?

The most expensive mistake is not building a feature poorly – it is building the wrong feature well. A team can spend months designing, coding, testing, and launching something that works exactly as intended but solves a problem customers do not care about. Poor execution can usually be improved, but solving the wrong problem wastes time, creates complexity, and takes attention away from work that could have created real value. That is why the most important product decisions often happen before anyone writes a line of code.

Why is problem-first thinking even more important in the age of AI?

AI has dramatically reduced the time and cost required to turn an idea into a working product. That is powerful, but it also means teams can now travel much farther in the wrong direction before realizing they misunderstood the problem. The bottleneck is shifting from execution to judgment: knowing which problems are real, which are worth solving, and which proposed solutions are simply fashionable. AI can help us build almost anything faster, but it cannot decide what is worth building unless we first give it the right problem.
If you want to write your own question and answer, do so here.

What did you learn on your journey as an author?

I learned that writing a book is less about recording what you know and more about discovering what you actually believe.

Many ideas that felt clear in my head became much harder to defend once I had to explain them on the page. Writing forced me to examine my assumptions, revisit mistakes, and separate lessons that were genuinely useful from stories I simply enjoyed telling.

I also learned that readers connect with honesty more than authority. The strongest parts of the book were not the moments when I appeared to have the answer, but the moments when I admitted that I had built the wrong thing, ignored an uncomfortable signal, or learned something later than I should have.

Finally, I learned that a book is never truly finished. It improves through editing, feedback, criticism, and repeated attempts to make an idea simpler without making it shallow. That process closely resembled building a product: start with a problem, create something useful, listen carefully, and keep refining it.