Altitude: Team Alignment Drift Gap
Feature Factory
The team can list every feature it shipped last quarter, with the date each one went out. Ask which ones customers use, or what any of those features changed, and nobody in the room can say. Finding out was never part of the job.
Definition
Feature Factory means the team is measured on what it ships, not on what changes for customers.
Because shipping is what’s scored, an item is finished when it is released. It moves to Done, and the team starts the next one. No loop runs from release to the team’s next decision, so what the feature did never reaches it.
The recognition pattern
Look at the backlog, and at the week after a release, when the team is already on the next item.
- Success is measured by what shipped, not by what changed for customers.
- The backlog is a list of features, and no item says what it should change.
- After a release, the question is “Is it done?” Nobody asks “Did it work?”
- Launches get celebrated. Impact never comes up.
Any of these can have another explanation. Together, they point to a routine that ends at release.
Nothing comes back after release
Leadership asks “What did we ship?”, because that is what it can see. So the team is scored on output, such as features released, and not on outcome, such as fewer support calls. That scoreboard was in place before the team arrived, and Motion-as-Progress traces what the scoreboard does to leadership’s decisions.
The team’s own process follows the scoreboard. No step after release asks how a feature is being used, or what support is hearing about it.
Not checking would cost less if unused features were rare. Pendo, a product analytics vendor, found that 80 percent of the features in the average product were rarely or never used, over three months in 615 of its customers’ subscriptions. The figure counts use, not outcome, but a team that never checks can’t tell whether its own features look like that.
Without evidence of what its features did, the team can’t stop building what failed. It can’t do more of what worked. And the next request arrives with its solution already named. The team has nothing from earlier work to weigh against it, so the request usually wins as written.
What it costs
The team ships on schedule. Whether any of that work changed anything for customers is a guess.
The product gets heavier. Requests pile up in the backlog as solutions nobody validated. Every feature that ships has to be maintained, including the ones nobody uses, and the team can’t tell which those are.
The gap also feeds the Vicious Cycle, where the barriers keep each other going. Wrong Work is the rework that follows when a feature that was built on an unchecked guess about the need turns out wrong. In Overload, requests keep entering, and with no evidence of which work matters, nothing already started gets stopped to make room. So the team carries more work at once than it can finish.
The people doing the work start asking whether anyone uses what they build.
Boundaries and distinctions
Vanity Velocity corrupts a measure. A planning number is read as value, and the number inflates once it becomes a target. In Feature Factory, the count of what shipped can be honest. What is missing is any measure of what happened next.
Proxy Trap is distance from the customer. Requirements come from people far from the customer, before the build starts. In Feature Factory, results never return to the team’s decisions. The gaps can occur together, and running the loop shows which requirements did not produce the change they were for.
Motion-as-Progress and Delivery-as-Success are different forms of this condition above the team. The first shows up in the evidence leaders decide by, the second in what the organization counts as done.
Shipping is not the problem. A count of releases tells a team whether work is moving. The gap begins when release is the last thing the team looks at.
Example
An illustration, by construction. Two quarters ago, a team shipped a reporting dashboard for its customers’ administrators. The company’s sales leader had asked for it after hearing prospects ask for one. The release was demonstrated at the quarterly review, and the item closed. Now the same leader asks for phase two: custom filters and scheduled email reports. The team leader asks whether customers use phase one. Nobody knows, because nothing was set up to report how customers use the dashboard. Setting that up would take work the plan has no room for, and phase two is already in it. So the team builds phase two over six weeks. Later, chasing an unrelated support ticket, an engineer pulls the logs: few customers opened the dashboard more than once. The team now maintains both phases.
Applied Test: what came back from last quarter
When did your team last learn whether a shipped feature changed what customers do? The question comes from Applied End-to-End Flow: Team.
- List the features the team shipped last quarter, from the release notes or closed items.
- Beside each, write the outcome it was meant to produce. Where nobody wrote one down, write “none recorded.”
- Then write whether anyone checked that outcome and what they found, or “not yet due” if it isn’t expected yet.
- Count the features with an outcome both recorded and checked.
The count is not a score. It shows how much of last quarter’s work has an evidence trail, not how much of it worked. Leave out only work not yet due, and work with no customer outcome at all, as with some compliance changes. Features marked “none recorded” stay on the list.
Whose move it is
Some fixes are the team’s to make, and others need measures, tracking or access that someone else controls.
Within the team’s control. Ask “Why does this matter?” before work starts. Write the expected outcome on the item, with roughly when that outcome should appear. When the outcome is due, set aside time to check whether it happened. Usage and what support is hearing are good first evidence, not proof that the outcome happened. Then take what you found into the next decision: keep, change or stop the feature, or use the evidence to push back on the next request. Do this even if nobody asks.
Requires escalation. Lasting change needs outcome measures at the portfolio level, which the team can’t set. Without them, the team’s checks compete with a scoreboard that still counts only releases. Ask for those measures, and for the tracking or access the team needs to check outcomes. Bring the Applied Test’s list to whoever decides how delivery is measured, and to whoever controls the tracking or access. Frame the ask around the waste you can show: “Here’s what we shipped. Here’s which features have any evidence. Where we checked and found little use, here’s what those features cost. Here’s what it would take to know about the rest.” In our experience, leaders who see that cost usually engage. If the people you ask know this framework, name the larger conditions: Delivery-as-Success and Motion-as-Progress.
Before choosing either move, check where the constraint sits (see Altitude Error).
Sources and lineage
Feature Factory is an Applied End-to-End Flow concept developed by Curtis Hibbs and Joshua Barnes. Its framework treatment comes from Applied End-to-End Flow: Team, in the Alignment Drift barrier, where it is one of the three gaps that break the team’s correction loop, escalates as Delivery-as-Success and Motion-as-Progress, and feeds the Vicious Cycle through Wrong Work and Overload. The feature usage figure is from “The 2019 Feature Adoption Report” (Pendo, 2019).
Curtis Hibbs and Joshua Barnes are co-creators of Effective Enterprise AI and Applied End-to-End Flow, and co-authors of the Applied End-to-End Flow book series. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.