Escape the Feature Factory by Wiring Outcomes Into How You Run

Most teams that want to escape the feature factory try to fix it with a speech. The leader stands up, says "we care about outcomes now, not output," everyone nods, and two weeks later the roadmap is still a list of features with dates. The words changed. The machine did not.

The feature factory is not a mindset problem. It is a wiring problem. If your reviews still ask "did we ship it," your team will keep optimizing for shipping. This brief lays out how to change the wiring: the targets you set, the reviews you run, and the way decisions get made. Do that, and the mindset follows on its own.

Why shipping more just makes things worse

Start with the math, because it is uncomfortable. When companies test their ideas with A/B experiments, only about 1 in 3 ideas move a metric, and the common rate is closer to 10 to 15 percent. So most of what you build creates no measurable value. Meanwhile every feature costs you twice: once to build, and forever to maintain, support, and work around.

Put those two facts together and the classic goal of "ship more, faster" turns into "produce waste faster at a growing cost." Itamar Gilad calls this the slippery slope toward bloated, hard-to-maintain products. Pushing developers to more story points per sprint is, at best, a second-order fix.

The better thing to optimize is the ratio of launches that actually create value. Once you accept that, a lot of what your team does today stops making sense. That is the point.

Set targets your team could hit without you in the room

The first piece of wiring is what you point the team at. Not a roadmap, a target. Matias Muhonen calls these Objective Targets: measurable goals anyone on the team can check for themselves. The test is simple. Could the team drop a planned feature and still be judged a success if the number moved another way? If yes, you have a real target. If no, the target is a feature in disguise.

Good targets sit between trivial and impossible. "Improve customer satisfaction" is too broad; there is too much noise to ever prove you moved it. A team owning product search should track something they touch, like add-to-carts per session or the rate of searches that end with nothing added to cart.

Scope the target to what the team controls. A team that owns the whole store can chase revenue. A support team should chase resolution time. Do not hand a team a number they cannot move.

Run outcome reviews, not demo days

Here is where the speech fails and the calendar wins. If your standing reviews are demos of what shipped, you are running a feature factory no matter what you say. John Cutler, revisiting his feature factory list years later, points at leaders who bake outcome reviews into how everything runs as the thing that actually breaks the pattern.

So change what the review asks. Instead of "what did we ship," ask "what did we learn and did the number move." Structure the report around goals, the ideas being tested, the evidence from those tests, and the decisions made off that evidence. Do this on a fixed cadence, every two weeks, not once a quarter when someone remembers.

Watch what your team celebrates, too. Muhonen's tell is sharp: factories cheer effort and finished features, outcome teams cheer results. If the pride in the room is "we finally shipped it" and nobody asks whether it worked, the wiring is still off.

Give the team the problem and the authority to solve it

Marty Cagan draws the line hard. A feature team gets a prioritized list of features and dates, while a product team gets problems to solve with business outcomes and the room to figure out how. In a feature team, whoever ordered the feature owns whether it works. In a product team, the team owns it. That difference in accountability is the whole game.

Authority has to come with the target. Saeed Khan makes this concrete from his own years as a PM: he was measured on revenue and profit, but he also held authority over the marketing spend and pricing that moved those numbers. Objectives without authority just set people up to be blamed for outcomes they could not control.

So when you hand a team a target, hand them the levers too. If you cannot, you have not empowered them. You have set a trap.

Decide by evidence, not by the loudest voice

The last piece is how decisions actually get made. When one group rules the product, whether it is a stakeholder, a designer, or you, you get a built-in bias. Itamar Gilad's answer is the Trio model, where a product manager, an engineering lead, and a designer decide together on goals and what to test first. Each brings a view the others lack. Evidence settles the arguments that opinion cannot.

To make that work at scale, borrow Netflix's habit of leading with context. You push strategic context down: the vision, the top metrics, the yearly goals. Teams push tactical context up: what they are seeing on the ground and how the numbers are moving. Nobody has to run every call up the chain.

The nice part is you can start inside the product org without a company-wide reorg. Merge the silos into trios, kill separate engineering, design, and PM OKRs, and set up a rhythm of sharing context up, down, and across.

The deep cut

The thing that is easy to miss is that you cannot fix this with words, and you cannot fix it once. Leaders keep treating the feature factory like a belief they can talk their team out of. It is not. It is the sum of your targets, your reviews, and your decision rights, and it resets the moment those go back to normal.

So the real work is boring and structural. Change what the target is. Change what the review asks. Change who owns the outcome and whether they have the levers to move it. Then keep it there through the next planning cycle, when the pressure to just ship comes back. The mindset is downstream of the machine. Fix the machine.

Three questions for your team

• Look at each team's current goals. Could they drop a planned feature and still succeed if the number moved another way? If not, you are handing out features dressed up as targets, and it is time to rewrite them.
• In your standing reviews, what gets celebrated: shipping something, or moving a number? If it is shipping, change the review agenda this week to ask what was learned and whether the metric moved.
• For every target you have set, does the team hold the authority to move it? Where the answer is no, either give them the lever or stop measuring them on it.