The features you should never have built are the ones whose ongoing obligations outweigh the customer problem they solve. They consume engineering capacity, complicate the product, and create promises the business has to keep. A feature can work exactly as specified and still be a bad decision.
That is the part a roadmap rarely shows.
A roadmap shows what the company intends to add. It usually says much less about what the company will have to support, explain, secure, sell, and eventually retire because of those additions.
I have built six companies and worked as a founder, CEO, CTO, and CPO. When I look at a feature, I look at it from all of those positions. The engineering question is whether we can deliver it. The product question is whether someone will use it. The company question is whether we want the business that comes with it.
That last question can change the answer to the first two.
Feature bloat starts before the interface gets crowded
Feature bloat is the accumulation of capabilities that add more complexity than useful value. You can have it with a clean interface and a short feature list.
A product with three capabilities can already be stretched across three buyers, three sales motions, and three incompatible expectations. A product with fifty capabilities can be coherent if they support the same valuable job.
The count is a poor diagnosis. Look at the obligations.
Take a hypothetical reporting feature. The request sounds modest: let customers build their own dashboards. But the real commitment may include a reporting language, permission rules, export formats, support for broken queries, and explanations for why two reports disagree.
You thought you approved a screen. You may have approved a second product.
Marty Cagan’s four product risks distinguish customer value, usability, technical feasibility, and business viability. That final category matters here: customer demand does not automatically mean a solution fits your business.
My extension is to make the continuing obligation explicit before the decision disappears into the backlog.
Five features that deserve a harder conversation
The feature attached to an unqualified deal
A prospect asks for something, sales estimates the contract value, and the request jumps the queue.
Before prioritizing it, establish what the feature actually changes. Is it the final purchasing blocker? Has the buyer confirmed budget and the decision process? Does the prospect fit the customer segment you intend to serve? Would several similar customers benefit?
A request can be sincere without being a commitment to buy.
I would rather hear that a qualified buyer will run a defined purchasing step once a specific requirement is met than that a large company seemed excited on a call. Neither guarantees a sale. The first gives you something you can evaluate.
There are good reasons to build for a single customer. A strategically important account may fund reusable infrastructure or open a deliberate new market. Make that a conscious investment with an owner, a scope boundary, and an economic case.
The feature that borrows a competitor’s strategy
Your competitor has an integration marketplace. A board member notices. Now you need one too.
Perhaps you do. But their product may serve a different buyer, have a different distribution advantage, or operate at a different scale. Matching their feature list can import the costs of their strategy without importing its benefits.
Ask which actual buying decision you are losing because the capability is absent. Separate verified loss reasons from a competitor comparison somebody assembled for a slide.
Competitive parity can matter. It deserves evidence as much as any other investment.
The automation built before the work is understood
Founders often want to automate a process as soon as it repeats.
But a process can repeat because the same uncertainty keeps arriving, not because the correct response is stable. Automating an unsettled onboarding process can harden exceptions into architecture before you understand why they exist.
Try delivering the outcome manually for a bounded set of customers. Record the steps, exceptions, and decisions. Then automate the parts that remain consistent.
The early manual work is useful when it produces knowledge. It becomes a problem when the company quietly sells unlimited service at software margins.
The platform built for customers you do not yet have
Custom roles. Plugin systems. Flexible workflow builders. Configuration for every conceivable use case.
These capabilities can be essential. They can also be an expensive attempt to avoid choosing a market.
Flexibility moves work somewhere. It may move it from your engineering team to a customer’s administrator, an implementation partner, or your support team. That can be a good trade, but it is still a trade.
If you cannot name the initial workflow the flexibility is supposed to improve, you may be designing around uncertainty instead of resolving it.
The AI feature without a specific decision to improve
“Add an AI assistant” is a format, not a customer outcome.
What decision will become better? What task will become faster? What happens when the output is wrong? Who checks it? Does the improvement survive the cost of review?
A summary feature that saves five minutes of reading but requires ten minutes of verification is an illustrative example of negative value, even if the demonstration looks excellent.
Start with the workflow and its failure cost. Then decide whether AI belongs in it.
Use an obligation test before feature prioritization
Prioritization frameworks can help compare proposals. They become more useful once the proposals include their real consequences.
Before committing meaningful capacity, I would put these questions on one page:
| Decision question | Evidence to bring |
|---|---|
| Whose problem is this? | A defined customer segment and an observed situation |
| What will change? | A purchase, completed task, repeat behavior, or risk reduction |
| What proves the need? | Actual behavior, a costly workaround, or a qualified buying constraint |
| What is the cheapest useful test? | A prototype, manual delivery, limited integration, or bounded experiment |
| What do we own after launch? | Maintenance, support, security, training, and operating costs |
| What will wait because of this? | The specific alternative losing people or calendar time |
| When will we reconsider? | An owner, a review date, and evidence that could change the decision |
Do not turn this into a spreadsheet that produces a precise-looking score from speculative inputs. Its purpose is to expose the assumption the room has been treating as a fact.
For one feature, the weak assumption will be demand. For another, it will be implementation cost. For another, it will be the belief that an enterprise buyer will accept the same product as your existing customers.
Those are different problems. They need different tests.
Measure outcomes without punishing useful niche features
Low adoption is a signal to investigate, not an automatic instruction to delete.
Consider a hypothetical product with eighty customer accounts. Twelve need an audit export, and ten of those twelve use it. Adoption is 12.5% across all accounts, but approximately 83% among eligible accounts. The same feature can look irrelevant or useful depending on the denominator.
Security, accessibility, administration, and recovery features may also create value when they are rarely used. The question is whether they serve a legitimate requirement, enable a purchase, or reduce a consequential risk.
For optional workflow features, define the outcome before release. If a feature aims to help customers complete setup, measure successful setup, time to value, and relevant failure rates. Counting clicks on the new button tells you whether people noticed it.
Microsoft’s experimentation guidance recommends explicit hypotheses and metrics that also detect regressions. The practical implication is straightforward: a local improvement should not hide damage elsewhere in the experience.
A/B testing is useful when the traffic, design, and expected effect support a trustworthy result. Early B2B companies may need customer observation, manual pilots, or staged releases instead. A small sample does not become convincing because it appears in an analytics dashboard.
There is reason to stay humble. In a 2013 account of large-scale experimentation, Microsoft’s Ronny Kohavi reported that fewer than a third of evaluated ideas improved their intended metrics, with an even lower rate in an optimized environment like Bing. That is historical evidence from a particular experimentation context, not a universal failure rate for startup features.
The useful lesson is that confidence inside the company is a weak substitute for evidence outside it.
What to do with features you have already built
Start with a feature review, not a deletion campaign.
Classify each capability into one of four decisions:
- Keep: there is clear customer, commercial, operational, or protective value.
- Repair: the problem matters, but discovery, usability, reliability, or distribution is failing.
- Contain: preserve a legitimate use case while limiting customization or new dependencies.
- Retire: the continuing burden no longer has an adequate justification.
Then speak to the affected customers before changing the experience. Check dependencies and commitments. Provide a replacement path, data export where relevant, and a reasonable transition. Turn off access gradually when a staged change is appropriate.
The original development effort is already spent. The decision now concerns future value and future obligations. However, the cost of removal is real and belongs in that calculation too.
A useful question for the next planning meeting is: “If this did not exist today, what evidence would convince us to build it?”
If nobody can answer, investigate. Do not let longevity become the business case.
The value of another operator in the room
A difficult roadmap decision often sits between functions. Sales sees a contract. Engineering sees a dependency. Product sees a distraction. The founder sees all three and still has to decide.
This is where I can help: make the trade-offs explicit, test the weak assumption, and decide which commitment the company should make next.
Bring the feature you are about to approve, or the one nobody wants to remove. We can examine the customer evidence, operating burden, and opportunity cost together.