The Obvious Solution Trap
Why the first answer that comes to mind is sometimes the most expensive one to keep choosing.
I came across a post recently from Sameer Sultan, an Associate PM at Duolingo, where he shared lessons from his first 365 days on the job. Most of it was practical, honest, and well-observed. But one point in particular stopped me mid-scroll.
He wrote — and I’m paraphrasing here — that one of the hardest things to unlearn as a new PM was the reflex of reaching for obvious solutions. The quick copy tweak. The extra hook. The small, safe bet that ships fast and looks productive. He called it creative short-sightedness: spending time on five smaller changes when one medium change would have achieved the same impact and been more rewarding to work on.
Then he added something that stuck with me: to this day, he still has to remind himself to question his assumptions.
What Is the Obvious Solution Trap?
The obvious solution trap is what happens when experience starts working against you.
Early in a product career, you build pattern recognition. You learn that low conversion rates often point to weak copy. That onboarding drop-off often signals a missing hook. That engagement dips often call for a notification. These patterns are real. They come from seeing similar problems across similar products, and they are not wrong.
The problem is that patterns, over time, become reflexes. And reflexes bypass the very thinking that made those patterns useful in the first place.
So instead of asking what is actually happening here, you start asking which pattern fits. Instead of sitting with the problem long enough to understand it, you scan it quickly and reach for the nearest tool that has worked before.
The obvious solution is obvious precisely because it has worked somewhere before. That is also why it is dangerous: it feels correct even when the situation is different.
The result is a backlog full of small, safe bets that individually feel productive and collectively underdeliver. Five copy tests that move the needle 2% each, when the real opportunity was rethinking the page entirely. Three notification experiments on a product that users are churning from because the core value is not compelling enough.
You are solving for the symptom, not the condition.
Teresa Torres Had a Name for This
Reading Sameer’s post sent me back to something Teresa Torres writes about in Continuous Discovery Habits, a book that has probably shaped how more product teams think about discovery than any other in recent years.
Torres identifies a related pattern she calls “solutions in disguise.” Her argument is that what looks like an opportunity is often already a solution someone has decided on. A stakeholder says “we need a mobile app.” A customer says “can you add a filter to this table?” These sound like needs. But they are actually proposed solutions to problems that have not been clearly stated yet.
Torres writes that an opportunity should represent a customer need, pain point, or desire, not a solution. If what you have identified has only one possible solution, it is probably a solution in disguise.
This is the trap operating one level earlier. Before you even get to your backlog, the input you are working from has already been pre-packaged as a solution. And if nobody pauses to unwrap it, the team ships confidently in the wrong direction.
Sameer’s lesson and Torres’s framework are describing the same misdiagnosis from two different angles. One is about the solutions product managers default to. The other is about the opportunities that were never really opportunities to begin with. Together, they point to a discipline that product work demands but rarely teaches explicitly: the ability to slow down before the answer arrives.
As someone earlier in my product career, I find this pairing genuinely useful. Not because it tells me what to do, but because it gives me a way to notice when I am skipping a step I should not be skipping.
Where This Shows Up in Practice
Here are four scenarios where the obvious solution trap tends to bite hardest.
1. The Copy Reflex
A sign-up page has a low conversion rate. The fast move is to rewrite the headline, sharpen the CTA, and run an A/B test. This is so common it has become the default.
But low conversion on a sign-up page can mean many things. Users arriving with the wrong expectation of what the product does. The wrong audience being targeted upstream. A trust gap, not a copy gap. A value proposition that is technically clear but not compelling to this specific user.
Better copy on the same page might move you from 4% to 4.8%. Fixing the upstream expectation problem might move you from 4% to 9%. One of these is a tweak. The other is a product insight.
2. The Notification Spiral
Retention is dropping. The instinctive response is to add a push notification, or make the existing one more urgent or more personalized. It ships in a sprint. It registers as a win in the standup.
But if users are churning because the core habit loop is not rewarding enough, because the product is not pulling them back on its own, notifications are just noise with a countdown. You can optimize the notification until it is perfectly timed and beautifully written, and it will still not solve the underlying problem. It will just delay churn by a few days.
The question worth asking is not how do we remind users to come back, but why are they not coming back on their own? That question is harder. It is also the one that leads somewhere.
3. The Onboarding Hook Reflex
New users are not reaching the moment where the product clicks for them. The quick response is a tooltip, a welcome modal, a checklist, a guided tour. These are low-effort, low-risk, and they make the team look active.
But sometimes the aha moment is simply too far into the product. The user has to set up too much, input too much, wait too long before they get to the thing that makes the product worth using. In that case, no amount of onboarding decoration will fix it. The work is pulling that moment earlier in the journey, which is a harder, messier, more architectural project. But it is the one that compounds.
4. The Feature Band-Aid
A feature is underperforming. Usage is low, feedback is lukewarm, the metric is not moving. Rather than asking whether the feature solves the right problem or is placed correctly in the user journey, the team adds a tooltip, a filter, a contextual prompt. The feature gets a second chance.
Six months later, after three rounds of small improvements and still no meaningful signal, the feature is quietly deprecated. The time spent on those small bets could have been used to either kill the feature early and redirect the resources, or rethink it more fundamentally from the start.
Small bets on the wrong thing are not low-risk. They are slow-burning, expensive commitments to the wrong direction.
Why the Habit Is So Hard to Break
Understanding the trap is one thing. Sameer said he still has to actively fight it and that is the more instructive part of the story. Here is why it persists even in experienced, self-aware product people.
• Velocity pressure. Small changes ship fast. In environments that reward throughput, there is an implicit incentive to keep tickets moving. Sitting with a problem long enough to understand it deeply does not always look like work from the outside.
• Risk aversion. A medium-sized bet requires more conviction, more alignment, more time to design and validate. A copy test is safe. The downside is contained. The obvious solution is also the comfortable one.
• Metric proximity. Small changes often move the metric you are watching in the short term. This makes them feel successful even when they are not addressing the underlying dynamic. The metrics are right; the diagnosis is wrong.
• Availability bias. The solutions you have seen work before are the ones you reach for first. If notification experiments drove retention at your last company, you will look for notification problems at your next one, even when the product context is completely different.
The Thinking Habit That Helps
The antidote is not to stop proposing solutions. It is to delay them long enough to ask better questions.
Torres offers a structural tool for this in the Opportunity Solution Tree. Before mapping solutions, her framework asks teams to first define the desired outcome, then map the opportunity space fully, asking what customer needs, pain points, and desires stand between the current state and that outcome. Solutions come last, and only after the team has genuinely explored what is actually going on.
You do not have to use the full framework to borrow the instinct. A few questions that are worth building into how you approach problems:
• Where does this problem actually start? Not where it surfaces, but where it originates. Low conversion on a sign-up page often starts on the landing page, or in the ad targeting, or in how the product is being talked about. The place the metric breaks is rarely the place the problem begins.
• What would a 10x improvement require? Not whether you are going to build it, just what it would take. That question almost always reveals that the obvious solution would get you to 1.2x, and that there is a harder path worth thinking about.
• If I shipped my current five ideas, what would the combined impact be? And is there one thing that would get me there? This is the Duolingo PM’s exact test, and it is a clarifying one. It forces you to think about your bets in aggregate, not in isolation.
• Am I solving for the symptom or the condition? The symptom is what shows up in the metric. The condition is what is actually happening in the user’s experience. These are not always the same thing, and which one you are solving for determines how far your solution can go.
Product Is Hard
I am still early in figuring a lot of this out. But what I took from Sameer’s post, and from going back to Torres’s work, is that this is not something you graduate from. The pull toward the obvious solution does not go away with experience. If anything, experience makes the pull stronger, because the patterns become faster and more automatic.
What changes, I think, is the awareness of it. The ability to notice when you are about to default, and to ask one more question before you do.
Sameer is an Associate PM at one of the world’s best product companies, and he still has to remind himself. That is not a warning. It is actually reassuring. It means the discipline is the practice, not the destination.
That is the real discipline of product. Not knowing which solution to ship. Knowing when to slow down before you do.
Product is hard not because the answers are complicated. It is hard because the right questions are easy to skip.
Final Thought
Obvious solutions aren’t wrong.
They’re just incomplete.
And if you rely on them too often, you risk building products that are constantly improving… but rarely evolving.
If this resonated, share it with a PM who needs to hear it — or with yourself, three sprints from now, when the copy test feels very tempting.