Nobody Plans to Run a Feature Factory. They Just Stop Asking the Right Questions.
Most companies don't set out to become feature factories. They slide into it, one "quick win" at a time, while the strategy deck gathers dust in a shared drive nobody opens.
There’s a moment I remember from about three years ago. We were in a quarterly planning session, and someone pulled up the company strategy document. It had been written maybe eight months prior. Beautifully crafted thing. Clear market positioning, defined customer segments, a coherent thesis about where we’d win.
The room went quiet.
Not because the strategy was bad. Because nobody recognised it. The roadmap we’d been executing bore almost no resemblance to what was on that slide. We’d drifted. Feature by feature, deal by deal, we’d wandered so far from the original intent that looking at the strategy felt like reading someone else’s diary.
This is the gap. Not a dramatic explosion. Not a visible failure. Just a slow, grinding disconnect between what leadership thinks they communicated and what teams actually build.
And when that gap gets wide enough, you end up running a feature factory without ever deciding to.
What a Feature Factory Actually Looks Like
The term gets thrown around a lot, usually as an insult. But it’s worth being specific.
A feature factory is an organisation that measures success by the volume and velocity of what it ships, not by whether any of it matters. The primary question isn’t “Did this change customer behaviour?” or “Did this move the metric we care about?” It’s “Did we ship it?”
“If you’re just using your engineers to code, you’re only getting about half their value.” — Marty Cagan
The symptoms are recognisable once you know what to look for:
Teams celebrate releases with no discussion of impact. The backlog is a graveyard of half-validated ideas, each one added because someone important asked for it. Engineers feel like ticket machines. Product managers feel like project managers. Designers feel like decorators brought in after the decisions are made.
And here’s the thing that doesn’t get said enough: most of the people working in feature factories are talented, well-intentioned professionals. They’re not lazy. They’re not stupid. They’re trapped in a system that rewards motion over progress.
The tragedy is that everyone’s working hard. They’re just working on the wrong things.
The Anatomy of the Gap
So how does this happen? How do organisations with perfectly reasonable strategies end up building products that have nothing to do with them?
I’ve seen a few patterns repeat across different companies, industries, and team sizes. None of them are complicated. That’s what makes them so insidious.
The strategy exists but doesn’t travel.
Someone, usually at the executive level, crafted a strategy. Maybe it was good. Maybe it was even shared at an all-hands. But then... nothing. No translation layer. No mechanism to turn “we’re going to win in mid-market B2B” into “here’s what that means for your sprint.” The strategy lives in a document. The work lives in JIRA. And the two never meet.
I worked with one team where the CEO had a clear point of view about their differentiation. Genuinely sharp thinking. But the product org had never seen it written down. They were making prioritisation decisions based on what sales asked for, because in the absence of clear strategic direction, the loudest voice wins.
Incentives point the wrong way.
When product managers are evaluated on features shipped, they ship features. When engineering leads are measured on velocity, they optimise for velocity. When sales compensation is tied to closing deals this quarter, they promise whatever it takes to close deals this quarter.
None of this is malicious. It’s just physics. People respond to the scorecard they’re actually judged against, not the one in the vision statement.
The feedback loop is broken or missing entirely.
Teams build something. It goes live. And then... silence. Nobody measures what happened. Nobody checks if users adopted it, if behaviour changed, if the problem was actually solved.
Without that feedback, there’s no way to learn. No way to correct course. You’re flying blind, so you default to the only thing you can see: output. At least you can count that.
Discovery gets squeezed out.
When there’s pressure to “keep teams busy” (a phrase that should make any PM’s eye twitch), discovery feels like a luxury. Why spend time talking to customers when there’s a backlog full of features waiting to be built?
This is how you end up with teams that are brilliant at execution and terrible at direction. They can build anything. They just don’t know if they should.
The Hidden Costs Nobody Wants to Calculate
Here’s what bothers me about the feature factory conversation: we talk about it like it’s just inefficient. Like the problem is we’re wasting some engineering cycles.
The costs are much worse than that.
You’re compounding technical debt. Every rushed feature adds weight to the codebase. Every shortcut becomes a tax on future development. I’ve seen teams where a feature that should take two weeks takes six, because the codebase has accumulated so much cruft that every change is a surgery.
You’re burning out your best people. There’s something soul-destroying about shipping things you know don’t matter. Senior engineers leave. Thoughtful PMs leave. What you’re left with is people who’ve made peace with the assembly line, or people who haven’t been there long enough to notice.
You’re training the organisation to ignore outcomes. This might be the worst one. When you celebrate shipping regardless of impact, you’re teaching everyone that impact doesn’t matter. That cultural debt is harder to pay down than any technical debt.
You’re missing the opportunities that actually matter. While your teams are busy building features nobody asked the right questions about, your competitors might be solving the problems your customers actually have. The opportunity cost is invisible but real.
Bridging the Gap: What Actually Works
Right. So what do you do about this? I wish I had a three-step framework that fixes everything. I don’t. But I’ve seen some patterns that help.
Make the strategy concrete and visible.
The strategy cannot live in a deck that gets presented once and forgotten. It needs to be translated into something teams can actually use for decision-making.
This is where something like a North Star Metric becomes useful. Not because it’s magic, but because it gives you a filter. Every proposed initiative can be tested against a simple question: “How does this affect the thing we said we cared about?”
At Quantive, working with enterprise clients like Adobe and John Deere, I watched teams struggle with exactly this translation problem. The companies that figured it out weren’t the ones with the fanciest OKR software. They were the ones where leaders consistently connected daily work back to strategic intent. Weekly. In every meeting. Relentlessly.
Protect time for discovery. Actually protect it.
Teresa Torres talks about continuous discovery as “at a minimum, weekly touchpoints with customers, by the team building the product.”
Weekly. Not “when we have time.” Not “before big initiatives.” Weekly.
This feels impossible in a feature factory because the machine is hungry. There’s always something that needs to ship. But here’s the counterintuitive bit: the discovery work is what makes the delivery work worthwhile. Without it, you’re just efficiently producing waste.
“Continuous discovery is about ensuring that every solution is tied to a validated customer opportunity.”
I’ve found the Opportunity Solution Tree useful here. Not as a religion, but as a forcing function. If you can’t draw a line from the feature you’re about to build back to a real customer problem, that’s information.
Change what you measure and celebrate.
If your sprint reviews are all about “what we shipped” and never about “what changed because of what we shipped,” you’re reinforcing the feature factory.
Start asking different questions. “What did we learn?” “What behaviour are we seeing?” “Did the thing we built last month actually work?”
This feels awkward at first. Teams aren’t used to it. But over time, it shifts the culture from output obsession to outcome curiosity.
Give teams problems, not solutions.
This requires trust, which requires that leadership actually lets go of control. Easier said than done, especially in organisations where executives got promoted by being the person with the answers.
But here’s what I’ve seen work: define the outcome you need, explain why it matters, set the constraints (budget, timeline, technical boundaries), and then get out of the way. Let the team figure out how to get there.
Marty Cagan calls this “empowered teams.” The mechanics matter less than the principle: you’re trusting smart people to solve problems, not treating them as ticket-processing machines.
Use economics to fight back against low-value requests.
When stakeholders come with feature requests (and they will, constantly), you need something better than “that’s not on the roadmap.”
Cost of Delay is useful here. It forces you to quantify: what’s the economic impact of not doing this? And what’s the economic impact of doing it instead of something else?
Not every conversation needs to become a financial model. But being able to say “if we build Feature X instead of Feature Y, we’re leaving approximately £400k on the table this year” is different from saying “I don’t think Feature X is a priority.”
Start small. Create a bright spot.
You probably can’t transform your entire organisation overnight. You might not even be able to transform your entire team. But you can probably run one experiment.
Pick one initiative. Do the discovery work properly. Measure outcomes, not just delivery. See what happens.
If it works, you’ve got evidence. If it doesn’t, you’ve learned something. Either way, you’ve broken the pattern.
The Uncomfortable Truth
I should be honest about something. Closing the strategy-execution gap is harder than any of the advice above makes it sound.
Organisations resist this change because the feature factory, for all its dysfunction, provides certainty. Executives can look at a roadmap and feel like they know what’s happening. Teams can look at a backlog and feel like they know what success looks like. There’s comfort in motion, even purposeless motion.
Outcome-driven work requires living with more ambiguity. You’re not promising to ship Feature X by Q3. You’re promising to move Metric Y, and you’re honest that you’re not sure how yet.
That’s a harder sell. To leadership, to stakeholders, sometimes to your own team.
But the alternative is continuing to build products that don’t matter, celebrating shipments that don’t connect to value, and wondering why the strategy slides still feel like fiction.
The gap between strategy and execution isn’t a one-time fix. It’s a discipline. A practice of constantly asking: “Is what we’re building connected to what we said matters?”
Sometimes the answer is no. And that’s the moment when you get to decide whether you’re going to keep feeding the factory, or start building something that actually works.
Anyway. That’s the thing about feature factories. Nobody wakes up and decides to run one. You just stop asking the questions that would reveal you already are.