How Sophisticated Customers Push Product Teams to Skip the Problem Step

A few months ago, a support ticket landed in our queue at Ambiki that made me pause. It wasn’t from a developer. It wasn’t from an IT department. It was from a clinician. The request was surprisingly specific. They weren’t just asking us to improve payments. They were suggesting a particular implementation path involving Stripe Connect.

A decade ago, most customer conversations did not sound like that. Customers would say things like:

• “Our billing process is frustrating.”
• “We waste too much time chasing payments.”
• “Parents get confused about what they owe.”

Today, customers often arrive with the solution already attached:

• “Can you add autopay?”
• “Can we export this to Excel?”
• “Can you build SMS reminders?”
• “Can you integrate with this API?”

In many ways, this is wonderful. Customers are more informed than ever. They understand software better. They know what is possible. They can compare products, research APIs, generate workflow diagrams with AI, and come to a product conversation sounding more technically fluent than many junior PMs.

But there is a hidden danger in that sophistication. The more solution-fluent customers become, the easier it is for product teams to silently skip the problem step. And I know this because we have done it.

The autopay mistake

A few years ago, I was on a sales call with a practice owner. Ambiki, a practice management product for pediatric speech therapy private practices, was still fighting for credibility in a crowded EMR market. Then came the question: “Do you have autopay?”

I froze. A competitor had it. We didn’t. The prospect clearly expected it. And in that moment, my brain did what many product brains do under pressure: it jumped straight from request to roadmap. We built toward autopay.

We convinced ourselves we had a problem statement. Something like: “Practices need automated payment collection.” That sounds reasonable until you look closely. It is not really a problem statement. It is a solution wearing a problem costume.

The real problem was not “lack of autopay.” The real problem was that billing teams were spending too much time chasing balances, processing payments one by one, and trying to understand who owed what. They wanted efficiency, but they also wanted control. That distinction mattered.

For solo practitioners, autopay can be perfect. Charge the card after the session. Done. But many of our customers are multi-provider pediatric therapy practices dealing with insurance, private pay balances, payment plans, delayed reimbursements, and parents who sometimes need flexibility. For them, rigid automation felt risky. As one customer put it, very simply:

We like being in control.

That sentence should have been in the problem statement. Instead of asking, “How do we build autopay?” we should have asked:

• “What makes payment collection painful today?”
• “What do billing staff need to control manually?”
• “When does automation help, and when does it create risk?”
• “What does the customer currently do to work around this?”

If we had started there, we probably would have prioritized batch payment workflows, clearer aging reports, one-click payment reminders, and better exception handling before building anything that looked like traditional autopay. The problem was sitting in our support tickets the whole time. We just listened to the loud solution instead of the quiet pain.

The new trap: solution fluency looks like clarity

A support ticket that says: “Can you integrate Stripe Connect without using the invoices API as it costs us more?” feels more actionable than: “Managing provider payments is frustrating.” It sounds researched. It sounds intelligent. It sounds like someone has already done discovery upstream.

But technical specificity is not the same thing as problem clarity. The customer may have researched the implementation before they fully understood the root issue. They may have asked an AI tool what the answer should be. They may be describing the workflow they saw in another product. They may be solving for one edge case inside their own organization.

Tool 1: Strip out the solution language

One practical exercise we use is simple: take the customer request and remove every word that names a feature, technology, implementation, or UI pattern. Words like SMS, dashboard, API, export, automation, button, real-time, AI, integration, dropdown, Stripe, Excel.

Those words are not useless. They are clues. But they are rarely the problem. Here is how this looks with real product-style requests.

The rewritten version may still lead to the original solution. SMS might be the right answer. A unique ID might be the right answer. More colors might be the right answer. But now you are choosing the solution because it fits the problem, not because the request arrived pre-packaged.

AI is part of the reason customer requests are becoming more solution-fluent. Product teams can use it in the opposite direction. Here is a prompt you can use with support tickets, sales notes, or interview transcripts:

Then paste the ticket. The important part is not the AI output. The important part is the discipline it creates. It forces the team to separate what the customer asked for, what pain might be underneath, what evidence we actually have, and what we still need to learn. That separation is where good product judgment starts.

The SMS example: when a problem statement smuggles in the solution

We had a version of this happen internally with SMS appointment reminders. The first draft of the product document said something close to: “Ambiki users are unable to provide appointment reminders to their patients via SMS delivery. This is impacting attendance and leading to increases in no-show appointments.”

At first glance, that sounds like a problem statement. It mentions attendance. It mentions no-shows. It sounds customer-focused. But the phrase “unable to provide appointment reminders via SMS delivery” gives the game away. That is not the problem. That is the missing feature.

The real work started when we removed “SMS” from the problem statement. Then we had to ask better questions:

• Why are appointments being missed?
• Are reminders not being received?
• Are parents ignoring email?
• Do staff know who has confirmed?
• Do they need two-way communication?
• Is this about attendance, communication preference, confirmation visibility, or staff follow-up?

When we talked to customers, the problem became more nuanced. Some parents gave “junk email” during intake and only checked it once to set up the portal. Some practices got faster responses through text than phone calls. Some customers cared less about the reminder itself and more about knowing whether a family had confirmed or cancelled. Others needed message customization in English and Spanish.

That changed the product conversation. The problem was not “we need SMS.” The problem was attendance reliability and response visibility. SMS was one possible tool inside a broader communication workflow. That distinction matters because a team building “SMS” will ship a checkbox. A team solving “attendance reliability” might build reminders, confirmation tracking, opt-out visibility, customizable messages, dashboards for staff follow-up, and escalation rules. Same starting request. Very different product.

Tool 2: Play “Solution or Problem?” with your team

One of the fastest ways to train product judgment is to make this a recurring team exercise. At Ambiki, we use a simple game: Solution or Problem? Bring five real customer requests from support, sales, or customer success. For each one, ask the team: Is this a problem statement or a solution statement? Then work through four questions:

• What do we actually know?
• What are we assuming?
• What problem might be underneath?
• What neutral follow-up questions should we ask?

Here is an example.

In {competitor's product}, you can add a new patient directly from the schedule. Can you do that too?

Most teams immediately start imagining a button. But slow down. What do we actually know? Staff sometimes need to add a patient while scheduling. What do we not know? Whether the pain is speed, call length, duplicate entry, abandoned bookings, or context switching. Better follow-up questions:

• “Can you walk me through the last time this slowed you down?”
• “What were you doing when you realized the patient was not already in the system?”
• “What happens if the process takes too long?”
• “Are you usually on the phone with a parent when this happens?”
• “What would make that moment feel smooth?”

The customer’s suggested solution may be exactly right. Maybe the answer is a shortcut from the schedule. But now the team understands why it matters. That makes the eventual design better.

Tool 3: Use a mini-FAD before anything reaches development

We use a Feature Alignment Document, or FAD, before meaningful product work moves into development. It is not a PRD. A PRD often tells the team what to build. A FAD forces the team to ask why the thing should exist at all. The lightweight version can be very simple:

• Problem. What real pain are we solving, for which specific user?
• Evidence. How do we know this problem is real? Support tickets, interviews, usage data, churn risk, manual workarounds?
• Current workaround. What are customers doing today instead?
• Appetite. How much time are we willing to spend solving this?
• No-gos. What are we explicitly not solving in this version?
• Success metric. What change in customer behavior or outcome tells us the problem is solved?

The no-gos section is more important than it looks. For SMS, a no-go might be: “We are solving appointment attendance and confirmation visibility, not general marketing messages.” That single sentence can save weeks of scope creep. For autopay, a no-go might have been: “We will not remove billing staff control over when and how balances are collected.” That would have forced us to design around the real constraint.

Respect customer expertise without surrendering product judgment

The point is not that customers are wrong. In fact, the most sophisticated customers are often the most valuable sources of insight. They understand their workflows deeply. They know where time is wasted. They know which workarounds are embarrassing. They know which problems keep resurfacing.

But they are also human. They anchor on tools they have seen before. They optimize for their local workflow. They describe symptoms as solutions. They use the vocabulary available to them. And increasingly, AI gives them even more solution vocabulary. That means product teams need a new reflex. When a customer says: “We need an API,” do not start with endpoints. Start with:

• Are they trying to connect tools, or escape from them?
• Where is the manual work happening?
• What are they copying and pasting?
• What would become unnecessary if this worked perfectly?

We had a prospect once send us a list of systems they wanted connected: Zoom, Notion, other tools, various education systems. It sounded like an API conversation. But when we dug in, the pain was not really “lack of APIs.” The pain was tool chaos. Therapists were jumping between systems, copying notes, managing links, and trying not to expose student information. What they wanted was not necessarily more integrations. They wanted fewer places to think. That is a different problem. And it leads to a very different product strategy.

The practical shift: from intake to translation

Most product teams already have some kind of intake process. A customer asks for something. It gets logged. Someone tags it. It goes into a backlog. The change I recommend is small but powerful: do not log the request only as a feature. Log two things:

• Customer’s words:“Can we add SMS reminders?”
• Product translation:“Families are missing appointments, and staff lack reliable visibility into who has confirmed, cancelled, or needs follow-up.”

Then attach the open questions. This creates a habit. Support still feels heard because the request is captured. Sales still has language to bring back to the customer. Product gets the raw request and the interpreted problem. Engineering sees the reason behind the work, not just the checkbox.

Over time, this builds a much healthier backlog. Instead of a graveyard of disconnected feature requests, you start to see clusters of pain. That is where roadmap strategy comes from.

A few questions to ask before building the customer’s solution

When a sophisticated request lands, try these before committing:

• “Can you walk me through the last time this caused trouble?”
• “What were you trying to do right before you realized you needed this?”
• “What happens today if you do not have this?”
• “How often does this come up?”
• “Who feels the pain most?”
• “What do you do today to work around it?”
• “What would improve if this problem disappeared?”
• “What would get worse if we implemented the solution exactly as requested?”

That last question is underrated. Every solution has a cost. Autopay can reduce manual work but reduce control. Real-time dashboards can increase confidence but create performance and data-trust issues. APIs can create flexibility but add implementation burden for customers who may not have technical teams. SMS can improve response rates but introduce consent, cost, deliverability, and workflow complexity. The customer’s solution may still be right. But product teams must understand the trade-off before inheriting it.

The product skill of the AI era

I used to think the hard part of product work was getting customers to articulate what they needed. Now I think the hard part is different. Customers are getting better at articulating what they think should be built. AI will accelerate that. Customers will show up with proposed workflows, mockups, API recommendations, vendor comparisons, and pseudo-requirements documents. Some of that will be incredibly useful. Some of it will be dangerously convincing.

The product skill that matters most is not rejecting those ideas. It is translating them. From solution to pain. From feature to workflow. From request to evidence. From “Can you build this?” to “What problem made this request feel necessary?”