Trapped in the Vicious Cycle of the Timeline Roadmap
You hear me go on about timeline roadmaps and why they are setting your team up for failure. But the reality is, it’s not the timeline roadmaps that are the root cause of the problems.
It’s the endless stream of due dates that are created as a result that is the real problem.
And those due dates cause deeper problems than you might think at first.
See, the fundamental problem with a timeline roadmap is that it assigns a due date to everything on the roadmap, just by the nature of it having a date-driven timeline at the top. The very format of the roadmap means that everything underneath it has a due date, whether explicitly promised or implicitly made.
Every product manager wants a roadmap that’s achievable and realistic. They don’t want to get caught out having to renege on their previously published roadmap plans. That doesn’t look good or feel good.
But a timeline roadmap that implies a promised land of endless delivery dates stretching far into the future spells trouble.
It creates a vicious cycle!
All of this creates a vicious cycle that can be hard to escape.
No one wants to be caught holding the hot potato by missing a deadline. One of the coping mechanisms for giving breathing room around deadlines is to add a little buffer. Finding the right amount of buffer is a fine art, but ask any product person, and you’ll find that buffer tends to disappear pretty quickly. To compensate, bigger and bigger buffers are given, just to be on the safe side.
A fact of life is that work expands to fill the time given for that work. This is called Parkinson’s Law and is the reason that you always seem to be running up against due dates, no matter how far out they started. Scope always creeps if you give a bunch of time for a task, and procrastination sets in way too easily for anything that has been given a far-off due date.
When the product team starts reporting back these longer estimations, it results in longer, and riskier-looking timelines. Execs become even less comfortable giving freedom to build in lean ways, so they react by trying to tie down even tighter due dates. This is all so that they regain some sense of control over costs and output of the team.
There’s never room for discovery in this way of working—it’s suffocating! There’s no time for rework or real quality assurance, and so the wrong things are built, problems aren’t solved properly, and overall, the quality of the product suffers.
This all leads to blame culture, where no one feels safe being the one to make a misstep at work. No one wants to be the one to point out the problems, lest they have to ask the execs for more freedom in the way they work, more time to work on quality, or frankly, just speaking up to point out that something’s fundamentally wrong with the way things are working. Instead, people just find it easier to resort to simply giving bigger buffers and estimates for their work, in hopes they don’t get it wrong ever again—this time, the estimates will be accurate and there will be enough time to build the quality product they hoped for… this time. Until this time fails, and the cycle repeats.
Those bigger buffers are given, and the entire team slows to a crawl over time.
This is why you can have huge and well-resourced teams who can’t seem to deliver anything of value and are being absolutely lapped by much smaller, nimbler competitors.
At the end of the day, it’s not the format of the roadmap that gives or sucks the life out of your product. It’s how you manage delivery dates. The added pressure of stacked-up delivery dates results in a vicious cycle that makes it harder and harder to be lean. Conversely, freeing yourself of arbitrary deadlines, and instead focusing on outcomes and prioritizing solving problems first, allows your team to deliver quality products, iterate as the market requires, and do so in a considerably less stressful environment. It’s a win-win-win!