You're not in a feature factory yet. You're just shipping a bit faster than you used to. The backlog grew because you found more problems worth solving. The roadmap got busier because stakeholders are more engaged. You added velocity as a KPI because accountability is healthy. See? You're still being thoughtful.

But you're not. In six months, you will be. Feature factories don't announce themselves. They arrive quietly, one small compromise at a time.

What feature factories actually look like

John Cutler coined the term "feature factory" to describe product teams optimised for shipping volume instead of customer outcome. The symptoms are subtle at first. Your team ships 10 features a quarter instead of 5. Everyone's busy. Velocity is up. And then you notice: 70% of shipped features go unused. Customers aren't happier. Revenue isn't moving faster. But everyone's working harder.

This happens to good teams. The problem isn't laziness or incompetence. It's incentive structures. When you measure success as features shipped, when you celebrate velocity, when you tie bonuses to delivery predictability — you're teaching your team to optimise for the wrong thing.

The scary part: by the time you notice the problem, the culture shift is already complete. Engineers have internalised that shipping matters more than impact. Product managers are defending their backlogs instead of questioning them. The board is happy because they see activity.

The early warning signs (while you can still reverse course)

Your team stops asking "why." Requests come in. They get estimated. They get shipped. You don't see deep dives into customer problems anymore. You don't see discovery spikes. Ideation happens in hallway conversations, not structured sessions. When your team goes from "let's deeply understand this customer" to "let's build what we think they want," you're drifting.

Velocity becomes a scorecard metric. There's nothing wrong with tracking velocity. But when velocity is what leadership celebrates, it's what teams optimise for. The question shifts from "Did we move the needle?" to "Did we hit 45 points?" Suddenly skipping QA to hit the sprint goal isn't a bug, it's a feature.

Your roadmap is completely full 12+ months out. Not "these are our goals" but "these are the exact features we're shipping in Q4." Paradoxically, this feels like discipline. Really it's inflexibility. You've traded your ability to learn and adapt for the illusion of certainty. When evidence surfaces that you should pivot, the roadmap becomes a prison.

You're measuring output instead of outcome. "We shipped the mobile app," not "30% of new users are now accessing the product from mobile and staying 2x longer." "We launched the API," not "third-party integrations are driving 15% of new revenue." When your metrics are features instead of business impact, you're in a factory.

Your engineers feel like order-takers. This is the canary. Engineers who aren't thinking about problems, who are just translating specs into code, who don't ask why — they're checked out. And you can't get them back until you change what you're asking them to do.

"A feature factory is a place where the goal is volume, not value. You can spot it by asking: 'Do we ship things we're proud of?' If the answer is 'we ship a lot of things,' you're in a factory."

John Cutler, on product culture

How to reverse course before it's too late

Kill a project. Not defer. Kill. Something on your roadmap has to die. This accomplishes two things: it signals that shipping volume is not the goal, and it frees capacity for discovery. The killed project should be something stakeholders care about. Make it visible. This is the hardest move and the most important one.

Measure adoption and impact, not just shipping. Start tracking: Of the features we shipped last quarter, what percentage are being used by >20% of our user base? How many have we iterated on since launch? How many have we killed? This reframes success from "we shipped it" to "it worked."

Protect discovery time. Block 20% of capacity for problem discovery, not solution building. This isn't "research sprints," it's structured time where your team deeply understands customer problems before scoping solutions. This time is sacred. When the board pushes back, you have to defend it.

Change how you celebrate. Stop celebrating "shipped 50 points." Start celebrating "moved NPS from 42 to 48 by shipping one small feature and fixing three broken ones." The metrics you celebrate are the culture you build.

Hire for curiosity, not just execution. When your hiring bar is "can they build fast," you attract feature factories. Your next hiring cycle should be about finding people who ask why. Who want to understand problems. Who get bored shipping things they don't believe in.

Why the Spotify model actually works

Everyone references the Spotify model as the ideal. It's not because they found a clever structure. It's because their model puts autonomy and alignment above output. Each squad owns a mission, not a feature list. They have the context to make decisions. They can kill things. They can pivot. The result isn't more features. It's the right features.

You don't need Spotify's scale to do this. You need clarity on what autonomy means: "Your job is to move this outcome. You own how." That's different from: "Your job is to build this feature. Here's the spec."

The honest check-in

Ask your team these questions anonymously:

- Do you understand why you're building what you're building?
- Have you said "no" to a request in the last month?
- Do you know if the thing you shipped last quarter made an impact?
- Would you use your own product?

If more than half your team says no to these, you're drifting toward a factory. The good news: you can still turn the ship. The hard news: it requires changing some things your leadership might not want to change.

But the alternative — a team that ships volume instead of value, engineers who are checked out, customers who are building workarounds instead of using your features — that's worse.