The Product Got Killed. The Lessons Didn't.

Not every product ships. We talk a lot about the ones that do, and almost never about the ones that get quietly shut down. That silence is a problem, because the products that die rarely die for the reasons you would guess. The design is fine. The research is real. The team is good. And it still gets killed.

I led one of those. Inside the Kessel Run software factory, paired with Air Force users at Pivotal Labs, I ran product for a tool we called Dingo, the Common Asset View. Its sibling product, Spacer, shipped and fed mission planning in active theater. Dingo did not. It was disbanded partway through when another team delivered a competing solution. This is the honest version of what happened, because the lessons are worth more than the win would have been.

The problem was real

Air operation planners needed something basic and surprisingly hard to get: when is a squadron available, and what can it fly? That information lived in inconsistent formats, reached different people, and often arrived too late to act on. Contracts rarely got updated or removed, so planners regularly built mission plans on invalid data. The legacy process ran on Friendly Order of Battle worksheets, PDFs hand-jammed into spreadsheet macros and then into the planning toolkit.

We did the work. We modeled the domain. We designed a structured request form with real fields so squadrons could state which planes they had, when they could fly, and any restrictions, and keep it current as events changed. On paper it was a clean single source of truth for asset availability across four Air Operations Centers.

It still got disbanded. The team retrospective was honest about why, and almost none of the causes were technical.

What actually killed it

No clear user champion from day one. Without one named owner pulling for the product, stakeholder opinions filled the vacuum. The team jumped between visions instead of committing to one, and entered discovery and framing before anyone agreed on who we were building for.

Portfolio strategy overrode user needs. There was a pull toward the broader Air Tasking data architecture, the system-of-systems view, that competed with what planners at the 609th actually needed on a given day. When portfolio goals and daily user needs disagree, and nobody resolves it out loud, the product drifts.

A competing team won the priority fight. A sister product got the 609th's priority, and its contracts work functionally replaced the data Dingo was building. The teams were never blended to share it. Two groups solved overlapping problems in parallel, and only one could win.

Everything churned at once. Pivotal PM turnover and Air Force staffing changes hit simultaneously. When both sides of a coaching relationship rotate at the same time, nobody can get up to speed, and momentum never compounds.

The next steps listed at disbandment told the whole story: "build out MVP" and "identify initial deployment champions." We had not shipped widely enough, or built enough of a coalition, to survive internal competition.

What survived it

Here is the part I would not trade.

The coaching outlasted the product. I paired with the Air Force product manager through real release calls and discovery decisions, not theory. The product was shut down. She went on to lead product on the sister tool that won. Enabling a client PM to outgrow the engagement is its own durable outcome, and it does not show up in a shipped-features list anywhere.

The domain model sharpened the wider system. Even disbanded, the work of modeling availability and contract data clarified how the larger planning cycle actually fit together. That understanding did not evaporate when the product did.

The lessons I now bring to every kickoff

• Name the user champion on day one. Not a stakeholder, a champion: one person who will fight for this product and the user behind it. Without one, stakeholder opinions decide the roadmap, and they rarely agree.
• Make cross-team dependencies explicit and early. One team needing another team's data before it was ready created a timing conflict nobody ever resolved. I now surface those dependencies at kickoff with a service brief that orients the whole team on the system they sit inside, before anyone writes a story.
• Separate portfolio goals from user needs, in writing. When the org-level data strategy and the end user's daily reality compete, name the tension explicitly and decide which one leads. Letting it stay ambiguous is how a product loses its center.
• Treat distance as a design constraint. Running product across a coast-to-coast timezone gap meant scheduling, facilitation, and pair calls had to be deliberate, not incidental. Remote coordination is not a tax you pay later; it is part of the design.

A disbanded product feels like a loss in the moment. With distance, it reads more like the clearest teacher I had that year. The design was never the risk. The organization around it was. That is the lesson I would hand to anyone leading product inside a portfolio of competing teams: ship a coalition before you ship a feature, or the better product will lose to the one with more friends.