A support ticket comes in. A sales call stalls because a prospect couldn’t find something during the demo. A customer success manager forwards the same complaint for the third time this quarter. The team’s instinct is almost always the same: build a feature that makes the complaint go away.
Sometimes that’s correct. Often it isn’t. The feature ships, the complaint quiets down for a few weeks, and then a slightly different version of the same complaint resurfaces somewhere else in the product. The team builds another feature. The cycle repeats, and the product accumulates settings, toggles, and secondary flows that nobody quite remembers the reasoning for.
This is the moment worth pausing on — not “should we build this feature,” but a more useful question: are we missing a capability, or are we compensating for an experience that no longer works?
A Feature Request Is Evidence, Not a Solution
A request tells you what a user tried to do and couldn’t. It rarely tells you why the product made that hard in the first place.
Take a common example: users ask for a bulk-export button. On the surface, that’s a missing capability — add the button, ship the feature, close the ticket. But the same request can just as easily point somewhere else entirely. Maybe users can’t find the data they need without exporting it first, because the in-product views don’t support the comparison they’re trying to make. Maybe the export option already exists, buried three menus deep, and the request is really a discoverability problem. Maybe the request is a workaround for a task the product was never structured to support well.
The point isn’t that feature requests are unreliable. It’s that they describe a symptom, and a symptom can sit on top of very different root causes — a distinction covered in more depth in how UX complexity gets diagnosed. Once a team has done that diagnostic work, a second question follows immediately: what scale of change does the actual root cause call for?
When a Feature Is Actually the Right Call
None of this is an argument against building features. Most product growth still happens through features, and a lot of the time, a targeted addition is exactly the right response.
A feature tends to be the right call when the gap is a genuine missing capability rather than friction around an existing one — when the surrounding workflow already works, and users simply lack one piece of functionality inside it. It’s also the right call when the problem is contained to a single screen or a single step, with no evidence that it’s compensating for a structural issue elsewhere in the product. And it’s the right call when adding it actually reduces the number of steps a user has to take, rather than introducing a new setting, mode, or decision point layered on top of what’s already there.
If a product team can point to a workflow that works well end to end, aside from one missing capability, that’s a strong signal the fix belongs at the feature level. The mistake isn’t building features — it’s building them as a substitute for looking at the workflow they sit inside.
When the Problem Is Bigger Than a Feature
The signals move in the other direction when the friction shows up in more than one place. A few patterns are worth watching for.
The same underlying friction appears across multiple screens or workflows, not just one. Users have built workarounds — spreadsheets, manual steps, duplicate data entry — because the product doesn’t support how they actually work. Each new feature seems to add another layer of complexity instead of resolving what came before it, and the product increasingly needs more explanation, onboarding, or support just to be used correctly. Fixing one screen creates side effects on another, which is usually a sign that the underlying structure, not the individual screen, is the actual constraint.
None of these signals is proof on its own. A single workaround might just mean one feature is missing. But when several of these patterns show up together around the same workflow, they stop looking like isolated requests and start looking like a structural problem — one that a feature, by design, can’t reach.
The Feature vs. Redesign Decision Framework
Putting this together, the decision comes down to a small number of dimensions rather than a gut call.
Problem scope. Is the friction contained to one screen or interaction, or does it recur across multiple connected workflows? Local problems point toward a feature; recurring problems point toward redesign.
Root cause vs. symptom. Is the request solving a genuinely missing capability, or is it compensating for friction that already exists somewhere upstream? If the request only exists because an earlier step in the workflow is broken, adding it treats the symptom.
Structural fit. Can the current information architecture, navigation, and interaction model actually support the experience the user needs — or would the feature have to fight the existing structure to work well?
Complexity trajectory. Will this addition reduce the number of decisions and steps a user faces, or will it add one more setting, mode, or branch to an already dense product?
Dependency. Would building this feature properly require touching the screens around it anyway? If so, the “feature” is really a redesign wearing a smaller name.
Read together, a local problem with a clear structural fit usually calls for a targeted feature. A systemic problem that recurs across workflows, with users already working around the product, usually calls for redesign. Most real situations sit somewhere between those two poles, which is exactly why the next section matters.
Before and After: One Workflow, Two Responses
The following is an illustrative SaaS scenario, not a verified YesOrYes case study, used to make the decision concrete.
Before. A B2B SaaS product lets account managers review customer usage data before renewal calls. The goal is simple: understand how a customer has been using the product over the last quarter. In practice, getting there takes several steps — open the customer record, switch to a separate analytics tab, manually set a date range, cross-reference a second report for feature-level usage, and often export both into a spreadsheet to actually compare them side by side. Account managers have started keeping their own tracking sheets outside the product because the in-app version takes too long to assemble before every call.
The feature response. The team hears the recurring complaint and adds a “Quick Export” button to the analytics tab, so the two reports can be exported together in one click instead of two. It genuinely saves a few clicks. But account managers are still leaving the product to do the actual comparison, still keeping their own spreadsheets, and the underlying task — seeing usage and engagement together, in context, before a call — still isn’t supported inside the product itself.
The redesign response. Instead of adding another export option, the team rebuilds the customer record view itself, so usage and feature-level engagement appear together on one screen, scoped to the relevant time period by default. The separate analytics tab, the manual date-range step, and the second report disappear as separate destinations — they become one view. Account managers no longer need an external spreadsheet, not because exporting got faster, but because the task the spreadsheet existed to solve is now handled inside the product.
The feature made an existing workaround marginally faster. The redesign removed the reason the workaround existed.
The Middle Ground: Targeted Redesign
It’s tempting to read the framework above as a binary — ship a feature, or redesign the whole product. In practice, neither extreme is usually right.
Most real interventions land in between: redesigning one workflow rather than the entire product, restructuring a single navigation pattern, reworking the one journey that’s generating the most friction, or shipping a feature alongside a redesign of the screen it lives on so the two don’t work against each other. A full product redesign is rarely the answer to a problem that’s actually contained to renewals, onboarding, or reporting. The scale of the fix should match the scale of the evidence — no more, no less.
When to Bring in a Product Design Partner
Some version of this decision comes up naturally inside most product teams. It usually becomes harder to resolve internally when the team disagrees about where the root cause actually sits, when the problem touches multiple product areas owned by different squads, when the backlog is accumulating patches faster than it’s resolving complaints, or when the scope of a potential redesign is genuinely unclear and needs research or workflow mapping before anyone can commit to a plan.
That’s typically where outside UX and product design support is useful — not to declare that a redesign is necessary, but to map the workflows, test the assumptions, and help a team see clearly whether they’re looking at a feature gap or a structural one. YesOrYes works with SaaS teams on exactly this kind of evaluation, from UX audits and workflow mapping through to full product redesign, when the evidence points that way.
Conclusion
The useful question was never “feature or redesign.” It’s “what level of intervention does this problem actually require?”
A feature should close a genuine capability gap. A redesign should address an experience that no longer holds up at its current structural level — one where users are working around the product rather than through it. The goal isn’t fewer features and it isn’t redesign for its own sake. It’s a product where every addition makes the experience better, instead of quietly compensating for a problem that was never actually fixed.
