The holidays are over, and most companies are back to business as usual. Dev teams around the world pick up the backlog where they left it last year. Managers measure the progress that has been made over the previous weeks. We're back in business!
But some people will have this uncomfortable sense of dread. Last year, they spent so much time building that Roadmap 2024, and now that the year has kicked off, they wonder: are we still on track? The majority of managers will not yet reassess their plans. That's too early. They will wait a few more weeks to take a look. After all, the year is only a week young. How much can we have deviated already?
The answer is: quite substantially.
For one of my customers, we made a roadmap for the first half of 2024. We defined the topics we wanted to focus on, allocated our appetite, and mapped it on a timeline. There were buffers and ample room for operational work. And right before the holidays, the team was on track.
But the new year had a few surprises in store. The team saw a surge in customer support tickets and discovered a potentially high-impact bug over the holidays. On top of that, the integration with an external vendor was moved up. So, we did what a lot of managers do: we adapted our big Roadmap 2024 in the first week of that year.
I write about planning for software products and get a lot of feedback from developers who tell me planning is futile and that we can't predict the future. These people will look at this story and see this as some kind of confirmation. The big plan failed in the first week! Surely that means we can't plan?
They are mistaken. This is a story that shows the power of planning.
If this were a classical software project, the skeptics would be right. In projects, the plan gets made before the work starts. The project plan is the yardstick against which to measure progress. If I defined a project and would be behind schedule in the first week, I would be a lousy project manager. Being behind schedule is a problem in project work because the schedule is the iron triangle. Being behind means delivering late or over budget.
But my customers, like most software teams these days, aren't delivering projects. They have a SaaS product, so the rules of product management apply.
Product plans, like their products, are never first-time-right. Plans, like their software, are iterative products. We inspect and adapt all the time. In this context, a roadmap is not Big Design Upfront. It's a communication device to align teams and stakeholders.
In product management, the goal is not to stick to a schedule. The goal is to adapt our product to reality, its feedback, and events. Our plan will reflect that.
That's a crucial distinction. Projects can be behind schedule. Our initial assumptions failed, and now we need to catch up or pay more. We don’t want that. In product management, there is an equivalent. While there is no fixed schedule, our plans can be out of sync with reality. That's equally bad. If our plan mistakenly says a feature will be delivered by June, we will disappoint stakeholders, waste their resources, and damage their faith in us.
So, back to my customer. We adapted the roadmap and were able to keep the vendor integration on track. We didn't tweak estimates or count on an overly optimistic velocity. We could keep the vendor integration on track at the expense of two features. One got pushed to the second half of 2024, and the other one was taken off the plan completely.
When events occur that impact our teams, this impact is non-negotiable. It's there whether we like it or not. It's there whether we plan for it or not. The goal of planning is not to predict these events. It's to give us the tools to assess their impact on our teams and adapt. So, rather than flying blind or pretending we still might be on track, we could communicate the impact of these events long before they would affect the stakeholders.
That feature that we were going to deliver by April will not be delivered at all. That's the price we have to pay to keep the vendor integration on track. This trade-off is now explicit and clear to all.
Stakeholders are perfectly fine with this. They don't mind a change of plans. They do loathe a last-minute change of plans.
That's why roadmaps are vital. They allow us to communicate the impact of today's events on the deliverables of the future.
Without a roadmap, we would be helpless victims of fate. We would react to events after the fact and disappoint our stakeholders at the very last minute.
A long-term plan for software products shouldn’t be first-time-right. It should be good enough for now. It’s our tool for adapting to the real world and aligning with our stakeholders.
So, take a look at your big 2024 plan and start shifting what’s already out of date. Changing your roadmap early and often is a healthy habit to build in the new year.
Roadmap = our defined path with what we know now, expected to be adjusted as we know more!