How to Choose Between Rebuilding a Product and Repositioning It

A product's numbers start to slip. The team runs through the usual responses: a new feature, a redesign sprint, a fresh coat of paint on the onboarding. Sometimes these work. More often, they treat the surface while the actual problem sits somewhere underneath, still compounding. The real question, the one that tends to get deferred because it is uncomfortable, is whether the product needs to change at a structural level or whether it is fundamentally sound and just being described to the wrong people in the wrong way.

The instinct to keep building is almost always the wrong response to a product whose core journey is broken.

We have been in this situation with clients who arrived certain they knew the answer. One wanted to keep adding features to an auction game while retention numbers were quietly collapsing. Another had built onboarding verification into a dating app with great care, then let the messaging feature go largely undiscovered. In both cases, the instinct was to keep building, and in both cases, the root problem was something else entirely.

This article is a framework for making that call with more rigour. It covers how to read retention data properly, how to distinguish a technical problem from an experience problem from a positioning problem, and how to prioritise once you have a diagnosis. The three paths, rebuilding, redesigning, or repositioning, are not equally available to every product, and choosing the wrong one wastes time that declining engagement does not leave you.

Why Declining Engagement Is Not a Single Problem

The number that gets people's attention is usually a single metric. Session length is down. Day-7 retention has dropped. Daily active users have plateaued. The immediate assumption is that something has gone wrong in the product, and the immediate response is to fix it. But that logic skips a step, because "something has gone wrong" could mean three completely different things depending on where the problem actually sits.

The product could be technically broken, with bugs, slow load times, or broken flows that make it hard to use. The experience could be poorly designed, with users hitting friction before they reach the part that makes the product worthwhile. Or the product could work perfectly and still be losing ground because the people it is being shown to do not recognise it as relevant to them. Each of these requires a different response, and applying the right fix to the wrong diagnosis costs time and often money.

Declining engagement is also not always a crisis. A product that served a particular season of a user's life will naturally shed those users as circumstances change. The question is whether the numbers are telling you that the product has a structural problem, or simply that it has reached the edge of a particular audience. Confusing the two is how teams end up repositioning products that needed a rebuild, or rebuilding products that just needed to be explained differently.

Before You Decide: What Your Retention Data Is Actually Telling You

Retention data is easy to misread, and the most common misreading is to treat a single number as the whole story. Session length, for instance, can be high for entirely different reasons. A user staying for fifteen minutes might be deeply engaged with useful content. They might also be confused, stuck in a loop, or held in place by gamification mechanics that have nothing to do with the product's core value.

Stickiness vs genuine resonance

The meaningful question is whether the user is staying because the product is working for them, or whether they are staying despite the product working against them. These look identical in aggregate session data and completely different when you look at what those users actually do during the session, what they return for, and whether they recommend the product to anyone.

The retention number to focus on is including whether users come back, and crucially, when they stop coming back and what they had and had not done by that point. A user who churns before reaching the core feature is a different signal from a user who reaches it, uses it repeatedly, and then leaves. The first suggests the path to value is broken. The second suggests the value itself has limits. Both show up as churn in a headline retention figure.

Map your churn against feature exposure. Users who left before reaching your core feature are a different problem from users who reached it and still left. Treating both groups the same produces interventions that work for neither.

Mistaking Investor Confidence for Product Health

Funding rounds create a particular kind of distortion. When investors commit capital, the team takes it as validation, and in some ways it is. But investor confidence reflects a belief about where the product could go, not a measurement of where users are right now. These are not the same thing, and treating them as equivalent leaves product health unexamined precisely when scrutiny matters most.

We encountered this directly on a project where the period between funding rounds had been used as a signal that the product was performing adequately. The actual user retention picture had not been looked at with any rigour. After that, we made the decision to implement much better tracking of user retention and to proactively ask users how things were going, rather than using capital raised as a proxy for product readiness. That shift changed what we were able to see, and changed what decisions were available to us.

Investor confidence reflects a belief about where the product could go, not a measurement of where users are right now.

This pattern is more common than it sounds. A product that has raised successfully tends to attract internal optimism, which can suppress the conversations that would surface a problem early. The team focuses on the next milestone rather than on the current user experience. By the time the retention numbers become impossible to ignore, the product has often compounded the problem through months of feature additions that were never the right treatment.

The correction is to establish user retention tracking as a continuous process rather than a pre-funding exercise. Not because it is good practice in the abstract, but because it gives you the data you need to make the rebuild versus reposition decision before the window for either starts to close.

The Three Paths: Rebuild, Redesign, or Reposition

When a product is in trouble, the instinctive response is to reach for redesign by default. It is visible, deliverable, and produces something that looks like progress. But redesign is only the right answer when the problem is in the experience layer. If the problem is in the architecture or in the market framing, redesign does not touch it.

The three paths serve three different diagnoses, and the choice between them follows from understanding which layer the problem sits in.

The decision requires diagnosis before it requires a plan. Teams that skip diagnosis and move directly to a chosen path tend to compound the original problem. A product in genuine architectural decline will not be saved by better onboarding copy. A product with broken flows will not improve because the team found a sharper tagline.

When the Problem Is Technical: Diagnosing a Rebuild

A rebuild is warranted when the architecture of a product is preventing it from doing what users need, and when the gap between what the product currently does and what it needs to do cannot be closed by changes to the experience layer. This is distinct from technical debt, which accumulates in most products over time and does not always require a full rebuild to manage.

Signs the foundations need replacing

The signals for a rebuild tend to be consistent. The product is slow in ways that cannot be resolved without changing how it is built. New features take a disproportionate amount of engineering time because the underlying architecture was not designed to accommodate them. The product fails in edge cases that represent a significant portion of the actual user base. Or the technology the product was built on has moved far enough that maintaining it is more costly than rebuilding on a current foundation.

Research from McKinsey's 2023 technology disruption research found that 78% of SaaS products that entered sustained decline between 2018 and 2023 were displaced by products built on a newer architectural foundation, rather than by a better implementation of the same approach. The pattern suggests that when a product loses ground to competitors, the most common structural failure is not in the experience layer but in the foundations below it.

A rebuild is not the same as a rewrite of every line of code. The question is whether the current structure is capable of supporting the product that users need, or whether the structure itself is creating the limitation.

When the Problem Is Experience: Diagnosing a Redesign

A redesign is the right path when the value proposition is sound, when users understand what the product does and want to use it, but friction or confusion is preventing them from reaching the part that makes it worthwhile. The product works, but the experience is getting in the way of people finding out that it works.

The clearest signal for a redesign is churn that happens before users reach the core feature. If a meaningful proportion of users are leaving without having experienced what the product is built around, the issue is almost certainly in the path to that experience, not in the experience itself. Improving flows, reducing cognitive load, and making the value more immediately apparent are all experience-layer interventions that belong to a redesign.

When redesign is not enough

Redesign does not help when the team has pivoted the product repeatedly without improving retention. If users are churning after reaching the core feature, the feature itself may not be delivering the value the team believes it delivers. And if the market has moved on from the problem the product was built to solve, no amount of flow improvement will change that.

A redesign candidate is a product where users can articulate what it does and express interest in it, but the numbers do not reflect that interest. The gap between stated intent and actual behaviour is the experience layer doing something wrong.

Run five user sessions and ask participants to reach the product's core feature without any guidance. Where they pause, backtrack, or ask a question is where the experience is breaking down. That map tells you more than a month of analytics.

Feature Parity Is Not Enough: Why Context and Emotion Determine Adoption

A common assumption behind redesign and rebuild decisions is that matching or exceeding a competitor's feature set will recover lost ground. If they have it and we have it too, the argument goes, users will distribute between us based on price or habit. This is a reasonable-sounding position that research consistently contradicts.

Feature parity does not determine adoption. What determines adoption is whether users, in their specific emotional state, at the specific moment they reach the product, feel that it is for them. A feature that works well in a calm, desktop environment does not automatically work in the same way on a phone during a commute. The same functionality presented to someone who is anxious about a deadline lands differently than it does to someone browsing with no urgency. Context and emotional state are functional considerations built into the feature itself, specifically, the conditions under which the feature either works or does not.

This is why a product can carry better features than its competitors and still lose. The question is not what the product can do, but whether users experience it as relevant and trustworthy in the moment they encounter it. A feature that a user cannot quickly understand as useful to their current situation will be ignored regardless of how sophisticated it is.

Understanding the emotional context of use is design work, not marketing work, and it belongs in the diagnosis phase rather than as a post-hoc refinement once the rebuild or redesign is already scoped.

When the Problem Is Positioning: Diagnosing a Repositioning

A repositioning is the right path when the product itself is working, technically and experientially, but it is not landing with the people who would benefit most from it. The product does what it says it does, users who reach it tend to stay, but the broader market does not recognise it as relevant to them. The problem is in how the product is framed and who it is being shown to.

Positioning failures are often invisible from the inside. The team knows the product well and understands its value, and that familiarity can make it hard to see that the description of the product does not translate to someone arriving without context. Only 10% of product marketers report consistent executive sponsorship for the upstream decisions that determine whether positioning still works, according to Fluvio's research on the PMM revenue gap, which suggests that positioning decisions often get made without the scrutiny they require.

The diagnostic signal for a repositioning is strong retention among a subset of users combined with weak acquisition and high early drop-off. The users who find the product compelling tend to stick. The problem is that most people are leaving before they have enough understanding to find it compelling. That is a framing problem, and adding features or rebuilding the architecture does not address it.

If your best users are a specific type of person who discovered the product by accident, that is a positioning signal. Their profile tells you where to point the product, and their language for describing it tells you how.

The Core Journey Test: What the Auction Game Got Wrong

We worked on an art-based auction game with real money prizes that launched with solid retention, running in the mid-sixties to low seventies percentage range. Over time, the quantity of available games started to decline. Usage became sporadic rather than regular, and retention dropped to around 30 to 35 percent.

The team's instinct was to add features. New mechanics, new engagement hooks, new reasons for users to open the product. We raised the concern that this was the wrong treatment, because the problem was not that the product lacked features. The problem was that the core experience, playing a game, was no longer reliably available. Users could not do the thing they had come for. But the client's preference was to keep building, and the feature additions went ahead.

It was only when retention reached the 30 to 35 percent range and held there that the team refocused on the core user journey, specifically on ensuring enough games were available consistently. When the supply problem was addressed, retention moved back to the mid-sixties to low seventies. It took time to rebuild, because trust that has eroded through a period of poor experience does not recover immediately.

The lesson from this project is not subtle. When users are churning before reaching the core feature, adding features around that feature compounds the problem. It creates a more complicated product for users to navigate on their way to something that still is not there. The core journey test asks one question: can a user reach the thing the product is built around, reliably, without friction? If the answer is no, that is where the work belongs.

Applying the Decision Framework: Diagnostic Questions for Each Path

A diagnosis is only as good as the questions that produce it. Before committing to a rebuild, a redesign, or a repositioning, the team needs to work through a structured set of questions for each path and let the answers indicate direction.

Questions for a potential rebuild

1. Is the product slow or unreliable in ways that cannot be resolved without architectural changes?
2. Is engineering velocity decreasing as the product grows, suggesting the foundations are not scaling?
3. Have competitors moved to a newer architectural approach that is enabling them to deliver things this product cannot?
4. Is the cost of maintaining the current codebase growing faster than the product is growing?

Questions for a potential redesign

1. Are users churning before they reach the core feature?
2. Can users articulate what the product does and express genuine interest in it?
3. Does qualitative research show friction, confusion, or hesitation in the flows leading to the core experience?
4. Have teams avoided pivoting the core value proposition, and is there retention data showing the value works when users reach it?

Questions for a potential repositioning

• Is retention strong among a specific user subset but weak across the broader audience?
• Are acquisition numbers low relative to product quality?
• Do users who leave cite confusion about relevance rather than a bad experience?
• Has the target audience shifted since the product was originally positioned?

How to Prioritise Once You Have a Diagnosis

A diagnosis tells you what type of problem you have. It does not automatically tell you what to do first. Most products in decline have some combination of technical, experience, and positioning issues, and the decision about where to start depends on what is blocking users from experiencing the product's core value at all.

The prioritisation framework we use works through a sequence of considerations. First, establish what the diagnosis has surfaced and separate the issues by type. Second, map each issue against the user journey and identify which ones are preventing users from reaching the core feature at all. Third, assess the business value and effort of each intervention. Fourth, apply an effort versus impact view to determine what gets addressed first, what comes later, and what gets dropped.

The sequence matters because a team that addresses a positioning problem before fixing a broken core journey is bringing more users into a product that will still disappoint them. A team that rebuilds a technical foundation before clarifying the experience layer may end up rebuilding the same confusing flows on better infrastructure. The order of operations follows from understanding which problem is upstream of the others.

A product entering genuine decline also has a time constraint. Revenue CAGR figures from Bain and Company's product lifecycle research suggest that the rate of decline in a declining product often accelerates rather than stabilises, which means the window for each path narrows over time. A repositioning takes weeks. A redesign takes months. A rebuild takes longer still. Starting with the diagnosis that requires the most time when a faster intervention was available is its own form of the wrong decision.

Before scoping any intervention, write down the one thing that, if fixed, would most change the number you are trying to move. If the team cannot agree on that one thing, the diagnosis is not complete yet.

Conclusion

The rebuild versus reposition question is genuinely difficult, and the difficulty is rarely in choosing between two clear options. It is usually in accepting that the path the team wants to take is not the path the diagnosis points to. Teams want to build. Investors want to see momentum. Neither of those forces pushes naturally toward the slower, more uncomfortable work of understanding exactly where a product has gone wrong before deciding what to do about it.

What we have found, across the auction game project and others, is that the products which recover do so because someone was willing to ask the question the numbers were actually asking, rather than the question the team preferred to answer. The auction game recovered when it addressed its core journey. The dating app's coherence problems came from a discovery process that covered onboarding in detail but left messaging largely unexamined, allowing the very behaviours the onboarding was designed to prevent. In both cases, the right intervention was available earlier than it was applied.

The framework here does not make the decision for you. It gives you the diagnostic structure to make it with more confidence and less guesswork. Understand what layer the problem sits in. Ask the right questions for each path. Let the answers indicate direction rather than starting with a direction and working backwards. That sequence is less comfortable and more useful than the instinct to keep building through uncertainty.

Let's talk about what your product data is telling you.

Frequently Asked Questions