In 2016, John Cutler published a blog post called "12 Signs You're Working in a Feature Factory." It resonated so deeply with the product community that "feature factory" became standard vocabulary overnight. Nearly a decade later, the post is still shared weekly in PM Slack groups because the pattern it describes is still everywhere.
A feature factory is an organization that measures success by output (features shipped) rather than outcomes (problems solved). It is a product team that operates like a factory assembly line: requests come in, features come out, and nobody checks whether anyone is better off.
If you have ever felt like your team ships constantly but nothing actually improves, you might be in one.
The Diagnostic Checklist
How many of these statements are true for your team?
- ☐ Success is measured by shipping on time, not by customer or business impact
- ☐ Nobody goes back to check whether shipped features moved any metric
- ☐ The roadmap is a list of features, not a set of problems to solve
- ☐ PMs spend more time writing specs than talking to customers
- ☐ Engineers do not know why they are building what they are building
- ☐ Feature requests from sales or executives go directly onto the roadmap without validation
- ☐ There is no mechanism for killing features that did not work
- ☐ "Velocity" is the primary team health metric
- ☐ Discovery is something that happens "when we have time" (meaning never)
- ☐ The team celebrates launches, not outcomes
- ☐ A/B tests and experiments are rare or nonexistent
- ☐ Technical debt grows because the schedule has no room for anything but new features
If 6 or more are true, you are in a feature factory. If 9 or more are true, you are in a deeply entrenched one.
The insidious thing about feature factories is that they often feel productive. The team is busy. Sprint velocity is high. Features are shipping on time. The Jira board is moving. It is only when you zoom out and look at customer outcomes, retention metrics, or market position that the emptiness of the activity becomes visible. The factory is running smoothly. It is just producing the wrong things. Sometimes the best products are the boring ones. Reliable, predictable, and focused on removing friction rather than chasing the next exciting feature.
Why Do Feature Factories Form?
Feature factories do not emerge from malice. They emerge from organizational incentives that reward the visible over the valuable.
Shipping is visible. Impact is delayed. A feature launch happens on a specific day. It can be demoed, announced, and celebrated. Its impact takes weeks or months to materialize and is hard to attribute cleanly. In organizations that reward what they can see, shipping always beats learning.
Output is easy to measure. Outcomes are hard. "The team shipped 14 features this quarter" is a clean number for a board slide. "The team improved activation rate by 6 points, which we project will increase NRR by 3 points over two quarters" requires explanation, caveats, and trust. Many organizations choose the simple number.
Stakeholders frame needs as solutions. When the VP of Sales says "we need a Gantt chart," they are expressing a customer need in the form of a feature request. Without a product culture that translates requests into problems, those feature requests flow directly into the roadmap.
Empowered teams require trust. In Marty Cagan's framework, empowered product teams are given problems to solve and the autonomy to find the best solutions. Feature factories give teams features to build. The difference is trust. Many organizations do not trust their product teams enough to empower them, either because the teams have not earned trust or because the organizational culture does not allow it.
Growth creates pressure. When a company raises a Series B or C, the board expects faster delivery. Headcount doubles. New PMs and engineers join who need clear tasks. The easiest way to manage this complexity is a feature factory. Break work into discrete features, assign them, and track delivery. It is a management shortcut that sacrifices long-term product health for short-term organizational clarity.
The Escape Playbook
Escaping a feature factory is hard because it requires changing organizational incentives, which means changing what leaders value. Here is a practical approach.
Phase 1: Prove the Pattern (Weeks 1-4)
Before you can change anything, you need to make the problem visible. Collect data:
The impact audit. Go back through the last 6 months of shipped features. For each one, answer: What metric was this supposed to move? Did it move? By how much? If you do not know the answer (and in a feature factory, you usually do not), that itself is the finding. For guidance on which metrics to track for product features, explore our product metrics glossary covering activation, retention, and engagement patterns.
Present this data neutrally. "We shipped 23 features last quarter. Of those, 7 had defined success metrics. Of those 7, 2 hit their targets. For the other 16, we do not have data on whether they helped." This is not an accusation. It is a mirror. Let the data speak. Resist the urge to editorialize. The numbers are damning enough on their own.
The utilization study. Check usage data for your last 10 shipped features. In most feature factories, 30-40% of recently shipped features have adoption below 10%. This is expensive proof that shipping fast without validation wastes resources.
Phase 2: Run a Pilot (Weeks 5-12)
Do not try to change the whole organization. Pick one initiative and run it the right way.
Choose a problem, not a feature. Define success metrics upfront. Do discovery (talk to at least 10 users). Prototype and test before building. Build the minimum version that addresses the core problem. Measure impact at 30 and 60 days. The Product Discovery Handbook provides a structured approach for running discovery sprints within feature factory constraints.
Pick a problem where you have strong conviction that the outcome-oriented approach will produce a better result. The pilot needs to succeed to justify expanding the model, so do not pick the hardest problem. Pick one where you can win clearly.
Document everything. When the pilot produces better results than the factory approach (and it will, because validated solutions outperform guesses), you have a case study.
Phase 3: Expand the Model (Weeks 13-26)
Use the pilot results to get buy-in for expanding the approach. Frame it in terms your leaders care about:
- For the CEO: "The pilot team delivered better customer outcomes with fewer features. This approach lets us do more with less."
- For the CTO: "The pilot team's features had 3x higher adoption, which means less engineering waste on unused code."
- For the VP of Sales: "The pilot team's feature directly addressed the pain points that were driving churn in enterprise accounts. Here are the specific accounts affected."
Offer to run the approach on a second team for a quarter. If both teams produce better outcomes, the evidence becomes hard to ignore.
Phase 4: Change the Metrics (Weeks 27+)
The structural change that makes the escape permanent is changing what gets measured and rewarded. This is the hardest part because it requires leadership buy-in.
Propose a shift from:
- Features shipped per quarter -> Customer problems solved per quarter
- On-time delivery rate -> Feature adoption rate at 30 days
- Velocity (story points per sprint) -> Impact per sprint (metric movement)
- Roadmap completion percentage -> Outcome target achievement
This will not happen overnight. Start by adding outcome metrics alongside output metrics. Over time, shift the balance. Eventually, the outcome-based roadmap replaces the feature list entirely.
What If You Cannot Change the Feature Factory?
Let us be honest: some organizations will not change. The feature factory is too deeply embedded in the culture, the incentive structure, or the leadership mindset. If you have tried the escape playbook and hit a wall, you have three options.
Option 1: Optimize Within the Constraint
Even in a feature factory, you can influence what gets built. If you cannot change the process, change the inputs:
- When a feature request comes in, do 3 user interviews before writing the spec. You may not get permission for a full discovery process, but nobody will stop you from talking to 3 customers.
- Add success criteria to every spec, even if nobody else does. "This feature is successful if 25% of enterprise users adopt it within 60 days." When you check back and the answer is 4%, that data accumulates.
- Propose smaller versions of requested features. "Instead of building the full dashboard, can we ship a single metric view first and see if customers use it?" Smaller bets have lower downside.
Option 2: Find Your Tribe
Even in the worst feature factories, there are usually a few people who care about outcomes. An engineering manager who wants to stop building throwaway features, a designer who wants to do real research, an executive who is privately frustrated that nothing seems to move the needle.
Find them. Build an informal coalition. Run experiments together when you can. Share wins internally. Cultural change often starts with a small group of committed people, not a top-down mandate.
Option 3: Leave
This is not defeatism. It is pragmatism. If the organization will not change, staying in a feature factory will erode your skills and your motivation. You will spend years shipping features nobody uses, and your resume will show volume without impact.
There are organizations that do product development well. Companies where PMs are empowered, where discovery is valued, where success means outcomes. Find one. The skills you build in an outcome-oriented environment compound in ways that feature factory experience does not.
How to Screen for Feature Factories in Interviews
If you are leaving a feature factory, make sure you do not land in another one. Here are questions to ask during your PM interviews:
"How do you measure the success of a feature after it ships?" Good answer: specific metrics, timelines, and examples of features that were iterated on or removed based on data. Bad answer: "We track usage" (vague) or "Success is shipping on time" (output-focused). The Product Analytics Handbook covers outcome measurement frameworks that separate high-performing product cultures from feature factories.
"Tell me about a feature you decided NOT to build." Good answer: a specific example with reasoning, data, and stakeholder communication. Bad answer: confusion, because the concept of not building something is foreign to them.
"What percentage of your roadmap is committed versus exploratory?" Good answer: some mix, with room for discovery and iteration. Bad answer: "Everything on the roadmap is committed" (zero flexibility).
"How much time do PMs spend on customer research versus spec writing?" Good answer: at least 20-30% on research and discovery. Bad answer: "We have a research team for that" or "We do research when we have time."
"What happens when a shipped feature does not perform as expected?" Good answer: the team investigates, iterates, or removes it. Bad answer: "We move on to the next feature."
These questions will not give you a perfect read on the company, but they will surface the obvious feature factories quickly. The way people talk about product development reveals what they value, and feature factories always reveal themselves through language that centers on output, speed, and delivery.
The Bigger Picture
The feature factory is not just a product management problem. It is an organizational design problem. It reflects a company's beliefs about how value is created: through predictable execution of a predetermined plan, or through iterative discovery and validated learning.
Neither belief is entirely wrong. Execution matters. But execution without direction. Shipping features without understanding whether they help. Is the most expensive kind of waste. You are not wasting time. You are wasting engineer-months, designer-weeks, and customer attention, none of which you can get back.
The first step out of a feature factory is naming it. The second step is proving there is a better way. Everything after that is persistence.
If you are in a feature factory right now, take one small step this week: pick the last feature you shipped and measure whether it actually moved the metric it was supposed to move. Share the result with your team. That single act of measuring outcomes instead of outputs is the beginning of the end of the factory.
The features you build should make your customers' lives better. If you cannot prove they do, it is time to change how you work.