Press

Customers are experts in their pain, not in your product. What they ask for is a clue, not a spec.

In this conversation with Timothy Hughes on #TimTalk, I talk about how to tell what customers actually need — not just what they say they want. We discuss why feature requests are usually symptoms of a deeper problem, how to ask the questions that surface the real workflow and constraints behind a request, and why taking requests at face value leads teams to build the wrong thing with great confidence.

That is the core of The Problem-First Method: stay curious a little longer, dig beneath the stated solution, and make sure you understand the problem well enough that the right answer becomes obvious.

How do you build trust in a team where colleagues may never share the same office?

In this second conversation with Niels Brabandt on The Leadership Podcast, I talk about leading a fully distributed team from Japan, with teammates across the United States and several other countries. Trust starts with hiring for autonomy and strong written communication, but it cannot stop there — we discuss team working agreements, asynchronous communication, visible decision-making, predictable meeting rhythms, and psychological safety without micromanagement.

The same discipline runs through The Problem-First Method: make your thinking visible, connect flexibility to accountability, and know which decisions are one-way doors and which are two-way doors — so the team can move fast where it is safe to, and slow down where it matters.

Don’t fall in love with solutions. Fall in love with understanding the problem deeply enough that the right solution becomes obvious.

In this conversation with Dr. Richard Shuster on The Daily Helping, I talk about why teams so often rush into building solutions before they fully understand the problem — and how customer requests, investor pressure, competitor moves, and now AI all make it easier to build quickly, but not always wisely.

We discuss the ideas behind The Problem-First Method: slowing down, asking better questions, removing solution language from early planning, and building from a clearer understanding of what actually needs to be solved. Whether you are building software, managing a team, or navigating everyday challenges at home, thoughtful problem-solving starts with curiosity, not assumptions.

AI is moving fast, but in therapy, the real opportunity is not replacing the therapist. It is removing the friction around the therapist.

In this conversation, I talk about why the human side of care still matters most: judgment, empathy, creativity, trust, and the ability to understand what is really happening with a child and family. AI can help with documentation, planning, admin work, and pattern recognition, but it should support the clinician’s work, not pretend to be the clinician.

That idea connects closely to The Problem-First Method: useful technology starts by understanding the real problem. Not the shiny solution. Not the trend. Not the feature everyone is talking about. The real problem.

Better products rarely come from better guesses. They come from better questions.

In this conversation with Chris Whitaker on The Wireless Way, I talk about the core idea behind The Problem-First Method: before we rush toward solutions, features, roadmaps, or shiny new technology, we need to slow down long enough to understand the real problem.

We discuss problem-first vs. solution-first thinking, the Feature Alignment Document, the Five Whys, AI’s role in product development, and how teams can avoid building the wrong thing faster. The lesson is simple, but easy to forget: clarity at the problem level saves pain at the product level.

Smart teams do not usually build the wrong thing because they are careless. They build the wrong thing because they move too quickly from pain to solution.

In this conversation with Niels Brabandt, I talk about why organizations so often skip the hard part: clarifying the real problem before committing to a plan, feature, strategy, or product direction. We discuss leadership, decision-making, team alignment, and the danger of confusing activity with progress.

That is the heart of The Problem-First Method: before you ask, “What should we build?” ask, “What problem are we actually solving?”

A book usually starts long before the first sentence is written.

In this author interview, I talk about the experiences that shaped The Problem-First Method: building Ambiki, working in pediatric therapy technology, learning from mistakes, and realizing how often teams rush toward solutions before they understand the actual problem.

The conversation is partly about the book, but it is also about the work behind the book: building software, serving a niche customer base, asking better questions, and learning that the most useful ideas usually come from staying close to the real-world pain.

The best products often come from living with the problem long enough that you can no longer ignore it.

In this conversation on the WillPower Podcast, I talk about the path from CTO to founder, and why I built Ambiki after seeing how difficult it was to scale a pediatric therapy organization with tools that were never really designed for pediatric speech, occupational, and physical therapy practices.

We discuss the operational chaos behind therapy work, the gaps in traditional EMRs, what it means to build a healthcare startup from Japan, and why the right technology should give clinicians more time and energy for the people who matter most: their patients.

That is also the heart of The Problem-First Method: the best ideas do not start with a feature. They start with a problem you understand deeply enough to build for.

Sometimes the best product ideas come from getting close enough to a problem that the old way starts to feel impossible to accept.

In this AMA Podcast conversation, I talk about building Ambiki from Japan and the work behind creating better tools for pediatric speech, occupational, and physical therapy practices. We discuss entrepreneurship, healthcare technology, and what it means to build software for a field where the stakes are not just operational, but deeply human.

That connects directly to The Problem-First Method: before you build, you have to understand the people, the workflow, the constraints, and the real pain underneath the request. The better you understand the problem, the more useful the solution can become.

Healthcare technology should not make meaningful work harder.

In this conversation on the Inspired Choice Podcast, I talk about pediatric therapy, therapist burnout, and why Ambiki was built with a therapist-first design approach. We discuss the operational complexity behind clinics, the pressure on clinicians and staff, and why better software should reduce friction instead of adding another layer of work.

That connects directly to The Problem-First Method: useful tools come from understanding the real workflow, the real constraints, and the real people behind the problem. The goal is not to build more features. The goal is to build something that makes the work more sustainable, more clear, and more human.