The Feature Factory Problem: Why Product Teams Keep Building Things Customers Do Not Need

Walk into almost any mid-sized product organization and ask to see the roadmap. What you will usually find is not a plan. It is a list. Fifteen, thirty, sometimes eighty items, each one traceable to a person who asked for it: a sales rep who needed a checkbox to close a deal, an executive who wants something to show at the next board meeting, a support lead tired of the same complaint, a competitor who shipped something similar last quarter. No single item on that list is unreasonable. Taken together, they describe an organization that is building constantly and improving customers’ lives only by accident.

This is the feature factory problem, and it deserves to be named plainly because it is common, expensive, and almost never the result of one person doing a bad job.

How a Feature Factory Forms

No team sets out to become a feature factory. It happens gradually, through a sequence of individually sensible decisions that add up to a roadmap disconnected from customer outcomes.

It usually starts with sales. A prospective customer says they will sign if the product does X. The deal is large, the request seems small, and the sales team escalates it. The roadmap absorbs X, not because anyone validated that X solves a widespread or severe problem, but because a revenue number was attached to it. Do this often enough and the roadmap becomes a record of deals rather than a record of customer problems.

Then there is the executive review. Leadership wants to see visible motion, a list of things shipped, a chart of velocity trending upward. Shipping is legible. Outcomes are harder to see in a quarterly slide. So the team optimizes for what is easy to report, and “features shipped” becomes the de facto scoreboard even when nobody explicitly decided that it should be.

Support and customer success add their own pressure. A frustrated customer complaint travels fast, especially if the customer is large or vocal, and it lands on the roadmap as an urgent fix. Some of these complaints represent real, severe, frequent problems. Many represent an edge case affecting one account. The trouble is that a complaint arrives with more emotional force than an outcome hypothesis does, so it often wins the argument regardless of its actual weight. As the framework puts it: a complaint is not automatically a high-priority product problem. Judging that requires actually weighing frequency, severity, urgency, cost of inaction, and willingness to change, which is exactly the kind of comparison a request-driven roadmap skips.

Layer on internal stakeholders: a design lead who wants to redo a screen, an engineer who wants to pay down infrastructure debt disguised as a feature, a founder who read something interesting last week. Each request has an internal advocate. None of them, individually, is required to justify itself against a customer outcome, because the roadmap was never built to ask that question.

Melissa Perri named this pattern the build trap in her book of the same name: organizations that measure their success by what they ship rather than by the value that shipping creates, running teams that take orders instead of teams that solve problems. Marty Cagan and the SVPG community describe the same organizational shape as the difference between feature teams, which exist to implement a roadmap of asks, and empowered product teams, which exist to solve problems for the business and the customer. Neither critique blames the individual product manager caught inside the system. The PM in a feature factory is usually working hard, shipping on schedule, and still producing very little customer value, because the system rewards throughput, not judgment.

The AI era makes the pattern more dangerous, not less. When producing software, prototypes, and content becomes cheap and fast, a team that has not fixed its prioritization discipline does not become more strategic, it just produces more of the wrong thing, faster. Velocity without direction creates waste faster. GitClear’s 2025 research on code churn during the rise of AI coding assistants is a useful data point here: as AI-assisted output scaled between 2020 and 2024, researchers observed rising churn and duplicated code, a reminder that more output is not automatically better output. A feature factory equipped with AI tooling is still a feature factory. It is simply a faster one.

A roadmap built from a list of requests answers “who asked for this?” A roadmap built from validated outcomes answers “what changes for the customer if we do this?” Those are different questions, and only one of them protects the business from wasted work.

A Roadmap Review, Before and After

Consider a hypothetical product team at a mid-market B2B software company. Their quarterly roadmap review has eleven candidate items, submitted by sales, support, an executive sponsor, and two engineers. Before any filter is applied, the list looks like this:

1. Add a CSV export button (requested by three enterprise accounts)
2. Rebuild the settings page with a new visual style (design lead)
3. Add single sign-on for a specific prospect (sales, tied to a $180K deal)
4. Add a dashboard widget showing “engagement score” (executive request)
5. Fix a slow-loading report that support tickets mention weekly (support)
6. Add dark mode (recurring low-volume request)
7. Build an in-app notification center (competitor recently shipped one)
8. Add bulk-edit for records (support, moderate ticket volume)
9. Migrate the backend queue system (engineering, framed as a feature)
10. Add a “Getting Started” checklist for new accounts (onboarding team)
11. Add an AI summary feature for reports (executive, general interest in AI)

Ranked by who is asking and how loudly, this list could easily be prioritized in the order sales and the executive sponsor prefer: SSO, the engagement dashboard, the AI summary, then everything else squeezed in around them.

Now apply a single outcome filter question to each item before it earns a place on the roadmap: does this map to a validated customer outcome, and if so, which one? Not “did someone ask for it,” but which of the customer’s outcomes, already understood through discovery, does this move? This is the same discipline described in the framework’s needs, pains, and outcomes stage: an output only belongs on the roadmap once it is tied to a customer outcome that has been named and evidenced, not assumed.

Run the eleven items through that filter:

• CSV export: tied to a known outcome. Enterprise finance teams need to reconcile data in external tools; failing to do so costs them manual rework every month. Frequency and severity are both real. Keep, but scope it to the minimum export fields those accounts actually use.
• Settings page redesign: no customer outcome attached, only an aesthetic preference. Park it.
• SSO for one prospect: the deal is real, but is SSO solving a broader authentication or security-compliance outcome shared across the core customer segment, or is it a one-off condition for a single account? The team checks and finds three other enterprise prospects have asked for the same thing in the last two quarters. That reclassifies it from a special favor into a validated segment-level outcome. Keep.
• Engagement score widget: nobody can articulate what decision a customer would make differently by seeing this number. It is an executive’s hypothesis about what customers want, not a customer’s stated need. Hold, pending a small discovery effort to test whether it changes any behavior.
• Slow report fix: high frequency, direct cost to the customer’s time, clearly tied to an existing “get my answer quickly” outcome. Keep, and treat it as a guardrail issue, not a feature at all.
• Dark mode: low frequency, low severity, no evidence it affects retention or task completion. Deprioritize.
• Notification center: driven by competitive anxiety, not a validated internal outcome. The team has no assumption on file about what behavior it would change. Hold until a hypothesis is written and tested.
• Bulk-edit: moderate ticket volume tied to a real time-cost outcome for core customers doing repetitive record updates. Keep, scoped as a minimum viable output rather than a full bulk-editing subsystem.
• Queue migration: this is a real need, but it is an internal reliability outcome, not a customer-facing one, so it belongs in a different conversation with its own guardrail metrics, not competing head-to-head with customer items on the same list.
• Getting Started checklist: tied to a known adoption problem, new accounts churning in month one before reaching first value. Keep, high priority given severity and urgency.
• AI summary feature: no named customer outcome, no assumption written down about what would improve for the customer, just general enthusiasm about AI. Hold until someone can state the hypothesis in the framework’s experiment format: which customer, which outcome, which threshold of evidence.

After the filter, the roadmap looks nothing like the original request-ranked order. Five items are confirmed with real customer outcomes attached (CSV export, SSO, the slow report, bulk-edit, and the onboarding checklist). Three are held pending a written hypothesis and a small validation step. Three are parked indefinitely, not rejected with hostility, just no longer competing for engineering time until someone can show the customer outcome they serve.

Nothing about the team changed. The engineers are the same, the sales pressure is the same, the executive still wants a good story for the board. What changed is that every request now has to answer one question before it becomes an output: which customer outcome does this serve, and what is the evidence. That is the entire mechanism. It costs almost nothing to run and it reliably separates requests that deserve engineering time from requests that simply arrived first or loudest.

Why This Is a Systemic Fix, Not a Personal One

It is worth being explicit about what this walkthrough does not claim. It does not claim the PM running the original request-ranked roadmap was doing a bad job. Under the incentives that existed, ranking by stakeholder pressure was a rational response to an organization that measured shipping, not outcomes. The fix is not a better PM, it is a better gate: a shared, repeatable filter applied at the roadmap review stage, visible to sales, support, and executives alike, so that the conversation shifts from “why won’t you build my thing” to “what outcome does your thing serve, and how strong is the evidence.” That reframing protects the PM as much as it protects the customer, because it gives everyone a shared standard to argue against instead of a personal veto to resent.

Teresa Torres’s continuous discovery work makes a related point: teams that maintain a steady rhythm of customer contact build a standing inventory of validated opportunities, so that when a roadmap review happens, the team is choosing among evidenced options rather than negotiating a pile of untested requests for the first time. The outcome filter works best when it has real discovery behind it, not just a good-faith guess at what customers might need.

Key Takeaway

The feature factory problem forms slowly, through the accumulation of individually reasonable requests from sales, support, executives, and engineering, none of which are weighed against a customer outcome before they land on the roadmap. The fix is not a heroic PM or a stricter no, it is a simple, repeatable filter applied at roadmap review: does this map to a validated customer outcome, and what is the evidence. Applied consistently, that one question reorders priorities without requiring anyone to be blamed for how the list got long in the first place. Teams that want a fuller structure for making this filter permanent, not just a one-time exercise, can look at the full outcome-driven framework for how segmentation, evidence, and measurement fit together across the roadmap.