Most "failing" software projects aren't failing because the team can't build. They're failing because nobody has decided what to build first — and the longer that goes unanswered, the more the project calcifies. Here is the playbook I keep coming back to.
I've walked into more than one product that had been "almost ready" for over a year. The pattern is always familiar: a backlog several hundred items deep, three competing visions of what the product is, and a team that has quietly stopped believing a launch will ever happen. On one logistics platform, that stall had lasted twelve months. We shipped a working MVP in six.
The fix is rarely heroic engineering. It's a sequence of unglamorous decisions, made in the right order, and then defended.
Start by finding the real blocker
Before changing anything, I spend the first week listening. Not in a kickoff workshop — in one-to-one conversations with the people who actually touch the work. The engineer who knows which module everyone is afraid to open. The support lead drowning in the same three tickets. The stakeholder who keeps adding scope because no one has told them what it costs.
Nine times out of ten the stated problem ("we need more developers") is not the real one ("we have never agreed what done looks like"). Naming the real blocker out loud, in front of the people who own it, is half the recovery.
The six-month playbook
Once the blocker is named, the work becomes a repeatable sequence. This is the version I run almost verbatim:
- Freeze the backlog. Nothing new gets added for two weeks. The goal is to stop the bleeding before trying to heal anything.
- Define the spine. Identify the single end-to-end path a real user must complete for the product to have any value at all. Everything else is a branch off that spine.
- Cut to the spine, ruthlessly. Move everything that isn't on the critical path to a "later" list. Expect resistance — protect the cut anyway.
- Re-baseline in weeks, not story points. Translate the spine into a dated plan people can actually picture. Calendars beat abstractions when trust is low.
- Ship something internal in 30 days. A rough, working slice of the spine, seen by real stakeholders, rebuilds belief faster than any status report.
- Then widen, one branch at a time. Only after the spine is solid do the deferred items come back — prioritised against evidence, not opinion.
What actually moves the needle
The steps above are simple to write and hard to hold. The real work is political, not technical: keeping the scope cut intact when a senior stakeholder wants "just one more thing," and keeping the team's confidence up when progress feels slower than the old illusion of busyness.
Two habits do most of the heavy lifting. The first is making delivery visible — a single, honest view of what's done, what's next, and what's been deliberately deferred. The second is making decisions reversible-by-default, so the team can move without waiting for perfect information.
A stalled project is rarely short of effort. It's short of agreement.
Six months later, the logistics platform had a live MVP, a team of seven that trusted its own roadmap again, and a backlog that finally reflected reality. None of it required a bigger budget — only a clearer answer to the question the project had been avoiding from the start.
If you're in the middle of one right now
Pick the spine. Defend the cut. Ship something small and real within the month. The momentum you get back is worth more than the scope you set aside — and the scope is still there waiting when you're ready for it.