Stop Building Features Nobody Hired You For

Feature bloat doesn't usually start with bad intentions. It starts with a good reason that can't survive daylight. A competitor shipped something. Sales needs a checkbox to land a deal. An exec has a big idea. A loud customer wants a workflow. An analyst report says "table stakes." Each request sounds rational on its own. Stack enough of them, and you've built a Frankenapp: a product that got bigger without getting more useful.

This pattern gets even easier to justify when you’re in the AI gold rush race. A competitor adds a copilot. Sales wants an AI checkbox. An exec wants an agentic vision. A customer asks for automation. An analyst says AI is table stakes. Each request sounds rational on its own. Stack enough of them, and you end up with a product that looks cutting edge while becoming useless.

That's the trap: the path to a bloated roadmap is paved with logic.

Not good logic. Not job logic. But logic that sounds defensible in a meeting.

Every article in this category starts from this problem — because it's the root of every other roadmap problem. How do you prioritize when everything sounds reasonable? How do you sequence what gets built first? How do you audit what's already there? How do you write sprint goals that mean something? How do you structure a roadmap that resists bloat instead of inviting it?

None of those questions have useful answers until you've answered the one this article addresses: what job did the user hire you for, and is the roadmap serving it?

And the cost isn't just engineering time or UI clutter. The cost is that your product stops being a dependable way for a user to make progress. It becomes an unpredictable pile of capabilities that somebody, at some point, argued for.

This is what it looks like when you confuse "more capability" with "more progress." They are not the same thing. Capability is what the product can do. Progress is what the user can reliably get done in their real situation, under their real constraints, with their real stakes.

You can increase capability and reduce progress at the same time. Teams do it every day. AI makes this easier to miss because the capability can look so impressive. A product can generate, summarize, recommend, automate, and answer while still making the user’s actual job harder to start, harder to trust, harder to repeat, or harder to defend. The roadmap may look more advanced. The user may feel less sure what to do next.

The tell: your roadmap arguments don't mention the job

Here's a quick diagnostic. Listen to how a feature gets justified.

If the argument for a roadmap item sounds like any of these, you're already in the danger zone:

"We need it because our competitor has it."

"We need it because it's table stakes."

"We need it because one enterprise prospect requires it."

"We need it because users asked for it."

"We need it because the exec team wants a bigger vision."

"We need it because analysts expect it."

"We need it because everyone is adding AI.”

None of those statements are inherently wrong. But none of them answer the only question that matters: What job progress does this enable?

Not "what does it do." Not "what market category does it signal." Not "will it help sales." Progress. For a user. In a situation. Where something is at stake.

If you can't explain a feature as a step in a job story — what moment it serves, what stuckness it relieves, what risk it reduces, what outcome it makes more likely, what intent it helps the user act on — then the feature isn't anchored to the thing that keeps products hired.

It's anchored to your fear of being left behind.

How the Franken-app gets born (and why it feels "inevitable")

Franken-apps aren't created by one bad decision. They're created by a pattern of decisions that all look "reasonable," because the product no longer has a strong center of gravity.

When the job is clear, new work gets pulled into a coherent shape. You can look at an idea and immediately ask: does this make the core job easier to start, easier to complete, easier to repeat, easier to defend, easier to succeed at?

That question is especially useful with AI because it forces the team to move past the surface of the capability. The issue is not whether AI can do the thing. The issue is whether doing that thing helps the user make progress in the moment that matters.

When the job is fuzzy, everything floats. Any feature can claim relevance. Any stakeholder can make a case. The roadmap becomes a negotiation between forces that aren't the user.

That's when your product starts to grow extra organs. A settings layer for the enterprise deal. A dashboard because the competitor has dashboards. An AI assistant because everyone has one. A workflow builder because power users asked. A template gallery because onboarding needs help. A notification center because engagement is down. And eventually, a "new experience" tab because the old one got too confusing to evolve.

The AI assistant is one of the most tempting versions of this right now because it can feel like a universal answer. It can sit on top of anything. It can appear useful in a demo. It can make the product feel more modern. But if it is not tied to a specific job, it becomes another feature weighing your product down: technically alive, strategically confusing, and frustrating to users.

Individually, each piece can be justified. Collectively, they create an experience that is hard to learn, hard to return to, and hard to trust.

And trust is the requirement underlying adoption: if users can't predict what will happen when they act, they move slower. If they move slower, they get less value. If they get less value, you get fired.

Your cluttered interface is actively recruiting for your competition.

The feature parity trap: copying surfaces instead of winning outcomes

Competitive benchmarking tends to produce a specific kind of bloat: features built to match, not features built to win.

Teams treat "parity" like strategy. But parity is just the absence of an objection. It's not a reason to choose you. It's not a reason to stay. What actually creates competitive advantage is job completion superiority — when users can reliably make progress with you in the moments that matter.

And make no mistake: chasing AI parity is no different. Adding a copilot because a competitor has one does not mean you understand what your users are trying to delegate, where they need judgment, what they need to verify, or what would make the product safer and more useful over time. You may have copied the surface while missing the outcome.

So when someone says "we need X because competitor Y has it," the useful response isn't "yes" or "no." It's:

• "What job progress does that feature enable for their users?"
• "And is that progress part of the job our users hired us for?"
• "If yes, are we losing because we lack the capability — or because we lack the outcome?"

Because features can be copied. A superior job outcome is harder to copy. Most parity features are the opposite. They're easy to copy and rarely deliver differentiated progress. They mostly add weight.

The enterprise checkbox feature: when one deal rewrites the product

The second big bloat engine is the "one deal" feature.

It's always urgent. It always comes with a revenue number. It always gets framed as "blocking." And it's often something like advanced permissions, audit logs, custom roles, SCIM/SSO variants, configurability layers, approval workflows, governance surfaces, or reporting built for procurement.

Sometimes these capabilities genuinely support a job your product should serve. Sometimes they're mainly serving the buyer's job: reduce perceived risk, satisfy compliance, avoid blame.

That job is real. But if you treat it as the same job as your core user's job, you'll drag the experience toward procurement theater. You'll force every user to pay the complexity tax for a requirement that only exists in a narrow buying context.

Now you've created a weird product: powerful enough to be intimidating, but not coherent enough to be lovable. That's how a product loses the thing it can't afford to lose –  repeated everyday progress for the core job.

"Users asked for it" is evidence of pain, not a build order

User requests are one of the most reliable ways to bloat a roadmap — because they come wrapped in empathy. You don't want to be the team that ignores users.

But users don't ask for features in a vacuum. They ask for features in the middle of trying to make progress. And designing the solution isn't their job, it's yours.

So a request is not a solution. It's a clue. It's a flare fired from a struggle point.

If you treat every request as a spec, you’ll build a product that is great at supporting users' workarounds, instead of eliminating the need for workarounds.

The faster way to surface what's actually going on is to ask to see the artifacts — the spreadsheets, the docs, the Slack threads, the screenshots living next to your product. That's where you see where the product stopped helping and where the user had to patch the gap.

Then you can answer the real question: what job progress were they trying to make when they asked for this?

If you can tie the request to job progress, you're in business. If you can't, you're about to ship weight.

The hidden cost: complexity doesn't just slow users down — it creates anxiety

Feature bloat isn't neutral. It changes the emotional texture of the experience. More features means more states, more choices, more ways to do the same thing, more uncertainty about what happens next, more "did I do it right?"

And when the stakes are real — as they usually are in professional software — uncertainty becomes anxiety.

Two kinds of anxiety often look identical in funnels: anxiety because the product is hard to use, and anxiety because the product isn't for the user's version of the job. Both create hesitation. Both create drop-off. The wrong response is to add more features to "cover" more cases.

That's how products become broad and brittle, with a thousand capabilities and no confidence.

If you want adoption, you don't just design for capability. You design for defendability. Can the user explain what happened, why it happened, and trust it in front of others? Frankenapps are notoriously un-defendable because the product's behavior becomes too sprawling to hold in your head.

The audit: make every feature earn its place against the Job

The way out of roadmap bloat is a sharper strategy filter. A roadmap item doesn't earn its place by being requested, exciting, or easy to ship. It earns its place by helping users make progress in the job they hired you for.

So run a feature audit that forces clarity.

Start by naming the core job in plain language. Not your category. Not your persona. The situation-triggered progress. The thing that, when it goes well, makes users feel relief and momentum, and when it goes poorly, makes them panic, scramble, or get blamed.

Then, feature by feature, ask: Does this materially improve the user's ability to make progress on that job?

If yes, keep it, sharpen it, and make sure it's easy to find at the moment the user needs it — not buried three clicks deep.

If no, name what it actually serves. Maybe it serves a different job, which might be legitimate. Maybe it serves sales, procurement, or internal status reporting. Maybe it exists for competitive screenshot parity. Maybe it exists because someone said "we can't tell them no." Whatever the reason, name it.

Naming is the whole game. Unnamed jobs become silent drivers of complexity. Named jobs become deliberate strategy.

Once you can name what a feature is really for, you can make an explicit decision: Are we choosing to serve that job as part of our product's identity?

If yes, commit. Design it as a coherent path, not a bolt-on. If no, stop pretending. Deprecate, hide, unbundle, or at least stop investing. Because "we'll keep it just in case" is how you end up carrying dead weight forever.

A focused product isn't smaller. It's more effective.

"But if we cut features, won't we lose customers?" Sometimes you'll lose customers who hired you for a different job you never meant to serve. That can be painful. It can also be clarifying.

Because the alternative is worse, as in, keeping a product bloated enough to satisfy edge-case demands, until the core user can't get clean progress without wading through someone else's requirements.

And that's how you lose the customers you actually needed.

The goal isn't minimalism for its own sake. The goal is usefulness per unit of complexity. A product should feel like it's on the user's side: it understands the job, reduces the struggle, makes the next move obvious, and helps the user keep momentum.

A Frankenapp doesn't feel like that. It feels like a committee.

So the next time a "reasonable" feature request lands in your roadmap, don't ask whether it's good. Ask whether it's hired.

Because if nobody hired you for it, building it won't make you more competitive.

It will just make you heavier.