How to Diagnose Whether Your Product's Problem Is Positioning or Experience

A product can struggle for two very different reasons, and treating the wrong one wastes months of effort. The first is a positioning problem: the right people aren't finding the product, or the people who do find it don't understand what it's for. The second is an experience problem: people arrive with the right expectations but the product itself gets in the way. Both produce the same surface symptoms. Downloads plateau. Retention drops. User feedback comes back vague and frustrated. The danger is that teams often jump straight to redesigning the interface when the real problem sits somewhere else entirely.

We spend a lot of time at WAA helping product teams work out which of these two problems they actually have, because the diagnostic question matters more than the fix. Redesigning a product that has a positioning problem won't help. Rewriting all your marketing copy won't save a product that genuinely confuses people once they're inside it. The two problems require completely different responses, and the path to understanding which one you're dealing with starts not with a design sprint or a campaign review, but with a clearer look at what the data and user behaviour are actually telling you.

Two Different Diagnoses, One Struggling Product

Positioning problems live before the product. They exist in the gap between what you say about your product and what a potential user understands it to be. If people arrive with wildly mismatched expectations, if they sign up expecting one thing and immediately feel deceived or confused, that's a positioning problem. The product hasn't failed them. The communication around it has.

Experience problems live inside the product. They show up after someone has arrived with broadly the right expectations, tried to do something, and found the journey harder than it should be. Error rates climb. People drop off mid-flow. Support tickets describe the same confusion in different words. The product is working as built, but the build doesn't match how people think.

The tricky part is that both can look identical from a distance. A product with poor positioning will show high early drop-off and low return visits. So will a product with a broken onboarding flow. Without digging into where exactly people leave, and what they say when asked, you won't know which problem you have. And if you don't know, you'll guess, and guessing is expensive.

Why Teams Confuse the Two

Product teams tend to default to experience fixes because they feel more controllable. Changing a button label or simplifying a form is faster than rethinking your entire value proposition. But speed of action isn't the same as accuracy of diagnosis. The most common mistake we see is teams iterating endlessly on product flows while the real problem is that the wrong audience is arriving in the first place.

The Decision Tree: Mapping Symptoms to Root Causes

A useful way to start the diagnosis is to think in terms of where in the journey the problem appears. If you map the user journey as a sequence of moments, from first awareness through to repeated use, you can usually pinpoint whether the friction sits before or after someone is genuinely inside the product.

Start by asking where people leave. If the bulk of abandonment happens before someone has meaningfully engaged with a single feature, that points toward positioning. They arrived, felt confused about what to do or why they were there, and left. If the drop-off happens during specific flows, at particular screens, or during tasks that require real interaction, that points toward experience. They understood the product well enough to try it, but the product made the attempt difficult.

• High bounce before first meaningful action: possible positioning problem
• Drop-off during onboarding flows: possible experience problem
• Repeated errors on specific screens: possible experience problem
• Low return visits with no clear in-product failure point: possible positioning problem
• User feedback that describes confusion about purpose: positioning problem
• User feedback that describes confusion about how to complete a task: experience problem

None of these signals are definitive on their own. They are starting points for a more structured conversation about what the data is and isn't telling you.

The Value of Qualitative Cross-Referencing

Analytics alone rarely give you the full answer. Drop-off at a particular point in the flow tells you something happened there, but not why. Pairing that quantitative signal with qualitative research, whether that's user interviews, session recordings, or short exit surveys, gives you the context to interpret the numbers honestly rather than optimistically.

Recognising a Positioning Problem

The clearest signal of a positioning problem is when users can't explain what a product does after they've used it. If someone spends five minutes in your product and walks away unable to describe what problem it solved or who it's for, the product hasn't communicated its own purpose. That's a positioning failure, and no amount of interface refinement will fix it.

Another telling signal is mismatch between the people you're attracting and the people the product was built for. This shows up in feedback that feels weirdly off-target, complaints about missing features that were never meant to be there, or requests that reveal the user expected something fundamentally different. When the feedback consistently describes a product you didn't build, your positioning has attracted the wrong audience.

There's also a subtler version of positioning failure that involves the emotional register of your communication. A fitness app aimed at people returning to exercise after a long break carries a very different emotional weight than one aimed at competitive athletes. If the tone, language, and visual framing of your marketing signals the wrong emotional context, users arrive in the wrong frame of mind and the product feels wrong even when nothing in it is broken.

We think of positioning as the promise the product makes before someone touches it. When that promise is accurate, users arrive ready to engage. When it's vague or misleading, they arrive suspicious or confused, and suspicion is very hard to design your way out of once someone is already inside the product.

Talk to users who churned early and ask them to describe what they thought the product would do before they signed up. The gap between their expectation and the reality is your positioning problem, stated plainly.

Recognising an Experience Problem

Experience problems tend to announce themselves through error rates and drop-off points. When users are making repeated mistakes on the same screen, or abandoning the same flow at the same step, the product is asking something of them that they don't fully understand. The issue is rarely that the user is careless. The issue is that the product hasn't given them enough context to act confidently.

High error rates are worth taking seriously as a diagnostic signal. If a meaningful proportion of users make the same mistake repeatedly, that's the product failing to communicate what it needs from them, not users failing to pay attention. Cognitive overload often sits behind this: too much information presented at once, too many choices on a single screen, or instructions that assume more prior knowledge than the user has.

One of Simon's key observations at WAA is that when someone says a product doesn't feel intuitive, they are almost never talking about the interface itself. They are talking about how the product makes them feel.

When a product doesn't feel intuitive, users are describing an emotional and cognitive experience, not a layout problem.

Drop-off during onboarding is another common marker. Asking for too much information early in a user's relationship with a product pushes people to abandon the process rather than continue. That's a design decision with real behavioural consequences, and it shows up clearly in the analytics if you know to look for it.

Look at where users make errors and where they drop off in flows, and ask whether you've given them everything they need to act at that moment. Often the answer is no, and the fix is about reducing what you're asking for rather than redesigning the entire screen.

The Right Research Method for Each Diagnosis

Once you have a hypothesis about which problem you're dealing with, the research method you choose needs to match it. Using the wrong research approach for the problem you think you have is one of the most common ways product teams waste time.

For positioning problems, the most useful research tends to happen before someone is inside the product. First-impression testing, where you show a new user the product's landing page or onboarding screens and ask them to describe what they understand about it, tells you quickly whether the communication is landing. Comparing what users say they expected with what the product actually offers surfaces the gap with very little ambiguity.

When Stakeholder Instinct Gets in the Way

A complication arises when the source of a positioning or experience concern is internal rather than external. People who know a product deeply will experience it very differently from someone arriving for the first time. A team that has lived inside a product for 18 months will find flows intuitive that a new user would find completely opaque. This insider bias is one of the most reliable ways that product teams misdiagnose their own problems. What feels obvious internally may not register at all externally, and separating those two perspectives is where structured user research earns its value.

For experience problems, moderated usability sessions are often the most productive route. Watching someone try to complete a real task inside the product, without guidance, reveals where they hesitate, where they make assumptions, and where the design fails to match their mental model. Combined with analytics data showing drop-off and error rates, usability research gives you a detailed picture of where the experience breaks and why.

Before running any user research, establish what you're testing and what decisions the findings will inform. Research without a clear question produces interesting observations that don't translate into action.

The Sports Coaching Platform in Practice

To make this more concrete, consider a sports coaching platform built for grassroots football clubs. The product aggregates session planning, player progress tracking, and parent communication into a single place. After launch, engagement is lower than expected. Coaches use the session planning feature but barely touch the communication tools. The team assumes the communication feature has a UX problem and starts planning a redesign.

But when they actually talk to coaches, a different picture emerges. Coaches understand the communication feature perfectly well. They don't use it because their clubs already use a messaging app that parents are comfortable with, and asking parents to migrate to a new platform feels like more trouble than it's worth. The feature itself works fine. The product's positioning implied it would replace existing tools entirely, but coaches don't want a replacement. They want something that fits alongside what they already use.

This is a positioning problem dressed up as an experience problem. The team was about to spend several weeks redesigning a feature that users understood perfectly well. The actual fix sits in how the product describes itself and what it promises to replace, not in the interface of the communication tool.

This kind of mismatch, between what the team believes the problem is and what users are actually experiencing, is remarkably common. The discipline of separating the diagnosis from the fix, and making sure the research method matches the hypothesis, is what stops teams from investing time and resource in the wrong direction.

Conclusion

A struggling product rarely tells you clearly what's wrong with it. The same symptoms appear whether the problem sits in how the product is positioned or in how the experience holds up once someone is inside it. The discipline of distinguishing between the two is what determines whether the effort you put into fixing things actually moves anything forward.

The starting point is always the same: map where in the journey the friction appears, look honestly at what your analytics are and aren't telling you, and resist the temptation to treat vague feedback as confirmation of whatever you already suspected. Insider bias is real and it distorts diagnosis consistently. The people closest to a product are the least well-placed to judge how it lands for someone encountering it for the first time.

Once you have a clearer hypothesis, choose your research method to match it. First-impression testing and messaging clarity work for positioning questions. Moderated usability sessions and error rate analysis work for experience questions. Using the right method for the right problem is what turns a hunch into a diagnosis you can actually act on.

The broader point is that getting this right is a precondition for everything else. Fixing the wrong problem with skill and care still produces the wrong outcome. The diagnostic step is the work, not a preamble to it. If you're not sure which problem your product has, that uncertainty is itself the most useful place to start.

Start the conversation about your product's diagnosis

Frequently Asked Questions