Have you ever noticed that the “problem” and the fix often show up in the same sentence? I notice this constantly: someone states a problem, and a solution is already stapled to it before anyone’s had time to actually think about the problem itself. It sounds like clarity. Usually it’s the opposite, it’s a decision nobody’s made yet, hiding behind something that sounds like a fact.
I remember one time we had big customers sending in the same request, over and over: they wanted an approval step before a record gets pushed into Salesforce. The request came up enough times, worded almost identically, that it started to feel like an obvious gap.
The team scoped it as a real workflow feature: an approval queue, reviewer roles, notifications when something’s waiting, a way to approve or reject before the record syncs. It touched the rules engine, permissions, and the Salesforce sync logic all at once, so it’s not quick.
It goes live and surprise, usage is almost nothing. A handful of admins turned it on, set up one approval step, and never touched it again. Meanwhile, the same customers were still complaining, just about something slightly different now.
What changed?
I finally sat in on a couple of support calls instead of reading the ticket summaries. It turned out almost nobody actually wanted a human reviewing every form submission before it hit Salesforce (that would have slowed their sales team down, not helped them).
What they actually wanted was to stop garbage leads from polluting their CRM: test submissions, obvious spam, the same person filling out the form four times because the confirmation message was unclear. “We need an approval step” was the closest thing they had to describe “stop letting junk into Salesforce,” because from where they sat, a human check was the only way they could picture solving it.
They needed a duplicate detection and basic spam filtering on the form itself, sitting in front of the Salesforce sync, not a human approval layer behind it.
That could have been built in a couple of weeks using validation logic that already existed in the rules engine.
Instead, the team spent a much longer stretch building an entire approval workflow that solved a problem almost nobody actually had, because the word customers used, “approval”, got treated as the problem itself, instead of a rough attempt to describe something else.
Why Product Teams Build the Wrong Feature (Even When They Listen to Customers)
It’s not that people are careless. It’s that sitting with an unanswered question is uncomfortable, and a request that arrives with a ready-made feature name attached makes that discomfort disappear immediately.
Compare these two things a PM could say after hearing the same customer feedback:
1. “Customers keep saying ‘approval step,’ and we don’t actually know what problem sits underneath that phrase yet.”
AND
2. “Customers want an approval step before Salesforce sync. LET’S SCOPE IT!”
The first is more honest, and it means more work before anyone writes a spec. Going back to actual calls, reading between the lines of what customers said, sitting with not knowing for a while.
The second comes with a feature name, a rough sense of scope, and the feeling that something is already being done.
Most people, in most meetings, reach for the second option. Not because they’re lazy, but because a named feature is genuinely easier to act on than an unnamed need, and nobody gets credit for saying “we’re still not sure” in a roadmap review.
This Isn’t Just a Product Management Problem
Once you start noticing this, you see it everywhere, not just in product meetings. “Sales are down, we need a discount campaign.” “Employees are unhappy, we need a ping pong table.” “Engagement is dropping, we need push notifications.” In every one of these, the solution is doing the talking, and the problem is just there to give it permission.
The pattern is easiest to catch in hindsight, which is exactly why it’s worth catching earlier. Nobody on that team thought they were skipping a step when they scoped the approval feature. They thought they had a clear, well-validated request, repeated by multiple customers in almost the same words. It’s only obvious in retrospect that nobody had actually opened up the word “approval” to see what was inside it. It just got accepted because it arrived already shaped like something buildable.
Why the “5 Whys” Method Doesn’t Always Find the Root Cause
You’ve probably heard the advice to keep asking “why” until you get to a root cause. It’s reasonable advice, but it only works if people in the room are actually willing to be surprised by the answer.
Ask “why do customers want an approval step” to a team that’s already scoping the feature, and you’ll get an answer that loops right back to the feature. “Why do they want it?” “Because they want to review submissions before they sync.” That’s not a root cause, it’s the request, restated.
The real test isn’t the number of questions you ask. It’s whether the answer could have gone somewhere you didn’t expect. If every “why” leads exactly where the team already assumed it would, nobody’s finding anything new, they’re just repeating a story they’d already settled on.
How to Find the Real Problem Behind a Feature Request
You don’t need a new process for this, just one habit: when a problem and its fix show up in the same sentence, physically separate them and see what’s left standing.
Take the fix out of “customers want an approval step,” and what’s actually left is much thinner: “bad data is getting into Salesforce.” That version survives on its own. It’s vague, but it’s real, and it points toward something worth investigating instead of something worth building outright.
This isn’t about distrusting every proposed solution. Plenty of the solutions people bring to a meeting are correct, and moving fast on a good idea is fine. It’s specifically about the moment when a solution is doing two jobs at once, being both the fix and the reason the fix is needed, because that’s usually the moment nobody actually checked what was going on.
In the approval workflow example, the giveaway was sitting right in the support tickets the whole time. Customers had used phrases like “we’re getting junk leads” and “someone keeps testing the form live” long before anyone used the word “approval.”
Nobody had gone back through those tickets looking for the actual complaint underneath the feature request, because the request itself, “approval step”, had already answered the question for everyone.
Once you’re looking for the fix-as-problem pattern, going back to raw tickets or call recordings instead of trusting the summary someone else already wrote is often the fastest way to catch it.
Product Problem Statements: Common Questions
Is it wrong to bring a possible solution to a problem meeting?
No, as long as you say that’s what you’re doing. “Here’s the problem, and here’s one idea, but I haven’t checked if it’s right” is honest. The issue is when the solution gets presented as settled and the “problem” only exists to justify it.
How do I bring this up without sounding like I’m just slowing things down?
Ask something specific instead of something general. Not “are we sure this is the real problem,” which sounds like doubt for its own sake, but “what did we actually see that pointed us here” or “what happens if we’re wrong about this.” A specific question either gets a specific answer, or it makes it obvious that one doesn’t exist yet. Either way, that’s useful.
What if there really isn’t time to dig into it before building something?
Then say that plainly, as a decision, instead of hiding it inside a fake problem statement. “We don’t have time to check this, we’re taking a bet” is a completely reasonable thing to say under pressure. It’s a different thing entirely from pretending the bet is a sure thing. The problem isn’t taking the shortcut, it’s not admitting you took one.
AI Lets You Ship Faster But It Can’t Replace Real User Conversations
This whole pattern gets more dangerous now that AI tools let teams ship in days what used to take much longer. Speed used to be the thing that forced a pause, building something took long enough that someone usually asked “wait, are we sure about this” somewhere along the way, just because the cost of being wrong was high enough to notice.
That natural checkpoint is mostly gone. You can go from a request in a support ticket to a working feature in a fraction of the time, and that’s genuinely good, until it means nobody stopped to check whether the request was actually pointing at the real problem.
There’s a specific version of this worth calling out directly: using AI to do the digging instead of talking to real users.
It’s tempting to ask an AI tool to search for what customers in your space typically want, summarize common pain points, or generate a plausible-sounding root cause, and treat that as if it were research.
It isn’t. That kind of output is built from general patterns across the internet, not from what your specific customers actually said, in their own words, about your specific product. It can sound confident and reasonable and still have nothing to do with what’s really going on with the people using your Salesforce integration.
AI is genuinely useful here, just not as a replacement for the conversation.
It’s good at helping you go through a pile of support tickets faster, spot phrases that repeat, or draft the questions you should ask on your next call. What it can’t do is have the call for you. The fix for a request like “we need an approval step” was never going to show up in a search result, it showed up because someone actually listened to how customers described the problem, in their own words, on a real call. Shipping faster only helps if what you’re shipping is aimed at something real, and the only way to know that is still to ask the people it’s for.
Why this is worth the extra time
Stopping to ask “wait, what’s the actual problem here” costs you something in the moment. It slows a meeting down. It turns something that felt ready to build into an open question nobody has a quick answer to. To someone eager to ship, it can look like friction for its own sake.
It isn’t. It’s the difference between spending an hour digging through tickets, and spending months building the wrong thing. That’s the actual trade, every time this comes up, whether anyone names it out loud or not.