Deadlines Have Vanished. Rapid Value Delivery is Fading Too
In an era where deadlines seem irrelevant, how can we still deliver real value?
“Engineering is just like a conveyor belt,” the COO told me 10 years ago when I landed my first official product manager gig, “The more engineers you have, the more story points you get done. Just make sure the pipeline is full and you can estimate your roadmap”. Needless to say, neither that logic nor the startup worked, burning over $2 million in less than a year.
Modern product development promised us a quicker route to delivering user value, but it came at the expense of rigorous estimations and detailed timelines. Forecasting roadmaps with story points (like in the startup above) created a false sense of precision, leaving teams scrambling to meet deadlines that don’t align with the reality of development.
And as these years have passed and Agile methods have spread, many of us began to lose sight of the value part, twisting these practices into the worst of both worlds—big, long, outcome-driven projects without clear timelines and high value uncertainty. On one hand, you’ve got leaders like that COO, stuck in an industrial-era mindset, and on the other, the occasional engineer who refuses to give any estimations at all. “It’s too complicated”; “Timelines are pointless”; “Agile isn’t about estimations” — adding even more chaos to the mix.
So how do we fix this disconnect between the promise of faster value delivery and the messy, unpredictable timelines we’ve ended up with?
1) Set deadlines and goals around delivering metrics and value
In most companies I talk to, features still dominate roadmaps. This creates an artificial focus on outputs (what they build) instead of outcomes (the actual impact of their work). Seriously, it’s 2024—it's time we finally shift our goals to prioritise metrics and user value over simply shipping features. Teams should have the freedom to figure out how to drive key metrics that matter, in close collaboration with and proximity to their users.
Setting goals around metrics then also becomes a function of arguably more practical variables:
a) What target is even achievable?
b) What is the minimum level of impact on the metric that will justify the team’s existence? (and if it’s not reasonable to achieve, should we focus on this exact metric or should the team exist at all?)
c) What target aligns with the company's ambition and strategy? (and if it’s not achievable, is our company strategy realistic?)
2) Demand and facilitate frequent shipping (always with some user value creation)
Deadlines for frequent iterations create a sense of urgency that can spark creativity and reduce procrastination. They provide structure and help teams maintain momentum by delivering something tangible on a regular basis. When teams ship frequently, they see the direct impact of their work more quickly, which boosts morale and keeps them motivated.
3) Make Public Commitments and Create a Culture of Accountability
Encourage teams to make public commitments regarding goals and targets. When deadlines and goals are transparent across the organisation, it fosters accountability without micromanagement. A culture of accountability empowers teams to own their progress and outcomes while also encouraging open communication when things don’t go as planned. By making these commitments visible, teams feel more responsible for meeting their goals, while creating a system where timelines are respected but also flexible enough to adjust when real-world challenges arise. And you should then encourage holding regular reviews or retrospectives, where teams not only track their progress but reflect on what went well, what didn’t, and how they can improve.
4) Take time and seek help to estimate a more complex project
Ideally, the need for an estimation of complex project timelines should be rare if you lead with the points above. But we all know these situations do happen.
Similarly to prioritisation, there are dozens of estimation techniques, each with its own pros and cons. Sometimes, the effort required for these estimation techniques may outweigh the value they provide. The challenge is that their effectiveness often depends on factors like your team, project, and company. It’s very rarely replicable.
When facing a particularly complex project, it’s often beneficial to collaborate with technical experts or those who have handled similar challenges before. This not only improves the accuracy of your estimates but also ensures that you’re considering all the technical nuances that may impact delivery in your situation. I have often found that people in the community are more willing to provide support than we might initially assume and you can always ask for help there. For those bigger unique projects, taking time and investing into the estimation may actually make sense.
Unfortunately, none of the suggestions above promise a silver bullet, because there isn’t one. But what we can do is take accountability for our product work by owning the value we deliver – and setting deadlines around those. After all, isn’t that the true goal of Agile?
Mike, thank you for bringing this topic to the table. I’ve also been thinking that often development teams practice agile methods, while having lost the original agile idea of delivering value quickly and learning from user feedback. The company itself is not truly agile. Regarding outcome (metrics) vs output (features) based roadmaps, a survey conducted with product managers in the summer showed that companies are increasingly trying to move towards outcome-based roadmaps, and many use a combined approach.