That feature nobody asked for? It's quietly costing you.

Feature bloat rarely looks dramatic in a sprint review. It looks responsible: “customers might need this.” The ticket is small. The designer already mocked a toggle. Engineering says two days. Someone mentions a competitor. The room nods. The feature ships. Months later, adoption sits near zero, onboarding takes longer, and nobody can explain what the product is for without opening a slide deck. Might is an expensive word.

I have watched this pattern across early-stage products in AI, hospitality, and consumer tools. The team is rarely careless. They are trying to be helpful. Helpfulness without a job-to-be-done is how products become museums of unfinished intentions. If you are deciding what to build next quarter-or what to cut-this is the discipline I use at nau.

Why “just one more feature” feels rational

Founders add features for understandable reasons. A prospect asks for something on a sales call. A board member compares you to Linear or Notion. Analytics show a drop-off and the instinct is to add a step, not remove friction. Competitors announce something shiny. Each reason feels local and urgent. The cost is global and delayed.

Y Combinator’s library on product and growth repeatedly returns to a related idea: focus is a strategy, not a personality trait. You can read that framing in the Y Combinator Library. The same lesson shows up in product-market fit work: clarity beats coverage. I wrote about that failure mode in why great products fail before product-market fit.

What unused features actually cost

The invoice for feature bloat does not arrive in one line item. It arrives as slower learning, messier positioning, and a product that is harder to sell-even when the core is strong.

1. Longer time-to-value

Every extra control, tab, or empty state competes for attention in the first session. New users do not arrive with your mental model. They arrive with a job and limited patience. When the interface offers six paths and only one delivers the outcome you promised on the homepage, activation drops. Stripe and Figma win partly because the first useful action is obvious. Your unused feature may be hiding that action behind a denser nav.

2. Weaker information architecture and SEO

Marketing pages multiply to justify modules. Navigation grows. Search engines and humans both struggle to understand what the site is about. Google’s guidance on helpful, people-first content rewards clarity of purpose-see Google Search Central. A product that tries to be everything becomes hard to rank for anything specific.

3. Harder sales conversations

When the product does twelve things poorly and two things well, sales defaults to a tour. Tours are not persuasion. Persuasion is “for this customer, we remove this cost.” Feature sprawl turns demos into inventory lists. Buyers leave impressed and undecided-the most expensive emotional state in B2B.

4. Engineering drag on every release

Dead features still have regression risk. They still break in edge browsers. They still need feature flags and migration notes. Teams start shipping slower because the blast radius grew. You did not buy optionality. You bought permanent tax.

5. Diluted brand promise

Every feature is a vote for what your product is. Cast enough vague votes and customers cannot repeat your promise. That is a clarity problem dressed as a roadmap problem-related to your product’s clarity problem.

A short story: the dashboard that ate the company

Imagine a fictional startup, Ledgerly-an invoicing tool for freelancers. Core job: get paid faster. After three months of decent retention, a few agencies ask for “team permissions,” “white-label PDFs,” and “multi-currency tax packs.” None of those requests come from the ICP that is already paying. The team ships all three in a quarter. Homepage now leads with “built for teams.” Freelancers bounce. Agencies still want Salesforce-level depth. Support tickets shift from “how do I get paid” to “why can’t my contractor see X.” The product did not get worse at invoicing. It got worse at being about invoicing.

Contrast that with how Linear kept issue tracking sharp, or how early Stripe refused to become “every financial product.” Focus is not anti-ambition. It is sequenced ambition. Airbnb’s early product discipline-host trust and booking clarity before feature theatre-is a useful reminder that growth often follows a narrower promise, not a wider one. I tear down related homepage clarity in the Airbnb homepage teardown.

The feature focus filter

Before anything enters the build queue, I run five questions. If any answer is mushy, the feature waits-or dies. This pairs with how I decide whether a product is worth building, applied at feature scale.

1. Job: Which specific progress does this create for a named ICP-not a persona poster?
2. Evidence: What behaviour, quote, or retention signal proves the job is urgent now?
3. Outcome metric: What measurable change do we expect in 14 days after launch?
4. Smallest ship: What is the thinnest experience that creates that outcome?
5. Kill criteria: What adoption or quality threshold triggers sunset, not “more polish”?

Jobs-to-be-done thinking helps here. The Interaction Design Foundation has accessible primers on JTBD and user-centred framing. You do not need academic purity. You need a sentence a sceptical founder would respect: “Freelancers who invoice weekly will create and send an invoice in under three minutes, and we will measure first-invoice completion within 14 days.”

Adoption windows beat roadmap optimism

I prefer a 14-day adoption window for most early features. Not because learning finishes in two weeks, but because silence is a signal. If almost nobody finds, tries, or returns to the feature, polishing it is usually vanity. Sunset or hide it. Prefer deleting and clarifying over adding and hoping. First Round Review has published repeatedly on focus and product judgment; start at First Round Review when you need founder-level case studies on prioritisation under pressure.

How to audit what you already shipped

If the roadmap already looks like a junk drawer, run a ruthless inventory. This is related to the diagnostic order in every startup looks like a marketing problem until you dig deeper: comprehension and activation before more surface area.

1. List every user-facing capability in one spreadsheet: name, owner, last meaningful usage, support volume.
2. Tag each as Core (drives the main job), Adjacent (helps a minority of the ICP), or Orphan (built for a deal, a whim, or a ghost).
3. For Orphans: hide, merge, or delete within a fixed window. Do not “revisit next quarter” without a date.
4. For Adjacent: keep only if it does not slow Core time-to-value.
5. Rewrite navigation and marketing so Core is unmistakable.

Nielsen Norman Group’s research on information scent and cognitive load is useful when you redesign IA after a cut-browse NN/g. Users do not thank you for options they never needed. They thank you for finding the outcome faster.

Try this: a 90-minute feature focus session

Use this exercise with your founder, PM, and one engineer who lives in the support tickets.

1. Write the product’s one-sentence job for the primary ICP on a whiteboard. No commas that smuggle in extra audiences.
2. List the last eight shipped features. Score each 0-2 for: used in first session, used weekly by retained users, mentioned unprompted in sales or support.
3. Anything scoring 0-1 across the board is a candidate for sunset or deep hide.
4. Pick one candidate. Write the Feature Focus Filter answers. If you cannot, schedule deletion-not a redesign.
5. Agree the next two builds only if they improve Core time-to-value or remove a measured belief gap.

If the session turns political, that is data. Feature ownership without outcome ownership is how companies accumulate polite debt. For a wider first-week diagnostic when priorities feel scrambled, see what I’d do if I joined your startup tomorrow.

What good restraint looks like in public products

Apple’s hardware and software often win by saying no to configurations that would please a loud minority. Notion stayed expandable without making every template a default obligation in the first session. Figma’s early collaborative editing was a sharp bet, not a kitchen sink. None of these companies are feature-free. They are feature-sequenced. The difference is whether new surface area serves a clear job for a clear customer-or soothes internal anxiety.

Harvard Business Review’s writing on strategy as choice-what you will not do-is older than most SaaS categories and still sharper than most roadmap rituals. Start at HBR if you need language for saying no in the boardroom without sounding stubborn.

Every feature is a vote for what your product is. Cast fewer votes, more intentionally.

Connecting features to the website and first run

Features do not live only in the app. They leak into homepage claims, pricing tables, and onboarding checklists. If marketing promises a capability that 2% of users ever touch, you train buyers to expect a different product. That is how beautiful sites still fail to convert-covered in why beautiful websites don’t always convert. Align the public story to Core. Let Adjacent live behind progressive disclosure.

Accessibility and performance suffer under sprawl too. More components mean more states to make keyboard-friendly and fast. The WCAG guidelines and web.dev vitals are not separate from product strategy; they are reminders that every extra surface has a human cost.

What to do this week

• Write one Core job sentence and pin it where roadmap debates happen.
• Kill or hide one Orphan feature with a dated plan.
• Add kill criteria to every in-flight ticket before more build hours.
• Align homepage and onboarding to Core only-no orphan promises.
• Review activation for the cohort that never touches secondary modules.

A final filter before the next sprint planning

Print this and keep it next to the backlog. If a ticket cannot survive it, it does not belong in the sprint-however small it looks on paper.

• We can name the ICP who needs this without saying “also useful for…”.
• We can point to evidence newer than a single anecdote from last quarter.
• We know the metric that would make us proud-and the metric that would make us delete it.
• We have checked that shipping it will not slow Core time-to-value.
• We are willing to hide it if adoption fails, not quietly leave it in the nav forever.

Restraint is not scarcity theatre. It is respect for attention-theirs and yours. Build less that matters more. The market rarely asks for a bigger product. It asks for a clearer one. When you need a partner to run that filter with you-not another brainstorm sticky-bring the roadmap and the support themes. The cuts are usually obvious once the Core job is written in ink.