Today’s read is 5 minutes long. Includes 5 ways of doing roadmaps that is fit for modern software development, and how to manage timeline expectations.
Humans are over-optimistic in near-term, and under-optimistic in the long-term.
Explains a lot about software development estimates or in general for any prediction to do with rollout of digital products.
Next time, you see an optimistic stakeholder or a team member who believes something can be finished in ‘quick 3 months exercise' or ‘this should be around 6 months give and take’, you can well share with them some indicative statistics (1):
Only 16.2% of software projects are completed on time and within budget
52.7% of software projects cost 189% or more of their original estimates
31.1% of software projects are canceled before completion
One must wonder, if accuracy of these estimations and estimates is rather not dependable, why must product teams continue to give timelines?
Hey 👋As an annual paid subscriber, you get free access to Product Leadership course on 3 August (this week) and one new course every quarter in future. You can also choose to become monthly paid subscriber for discounted access to course, guides and tools. Upgrade here to paid or simply become a free subscriber:
Register for Product Leadership Basics (2 hour session on 3 August,2024)
You will have 4 key takeaways from this course:
1. Understand best practices to create a product strategy
2. Explore recommended ways to hire and nurture talent
3. Compare frameworks and methods for an effective product roadmap execution
4. Get tips on driving business success as a product leader
Date: 3 August,2024 (Saturday)
Time: 9AM to 11AM EST/ 1PM to 3PM GMT / 4:30PM to 6:30 PM IST
Use the CODE PRODUCTIFYNOW at checkout to get 62% off on the ticket price. Register here:
It’s like going to board a train at 0500pm as per train schedule, but you always know the train is not going to turn up till next morning. Would you still continue to check train timings every-time? It not a rhetorical question, rather a philosophical.
But since when did the need for timelines came up in software development projects?
A lot of it in modern times is just reaction to some kind of market pressure.
As the software industry grew rapidly, companies faced increasing pressure to release products quickly to stay competitive and capture market share.
These tendencies creeped into product teams where some stakeholder or a client has a timeline in mind, and if that timeline is missed there’s a risk to winning in the market in some shape or form.
But the real culprit is the traditional project management mindset.
This mindset has existed since 1800s since the industrial revolution, where there was a sudden need to structure things and manage large scale executions.
These earlier methodologies often emphasized rigid planning and control mechanisms, which could lead to inflexible timelines.
Many of these projects were working backwards from a deadline.
In my understanding, blaming anyone in the organization when they ask for timelines or giving them a lesson about the worthlessness of their ask is of no help. They are coming from the right mindset of winning in the market.
Or they just have been doing waterfall project management for too long.
But you should look at this as an opportunity.
First of all, explain how uncertainity plays out
I like to use a simple example for this.
And I will be temporarily using the term ‘project’ a few times below to refer to general task undertaking, as a single term to refer to both modern software development but also to more traditional natured projects.
And I like this one because this is taken from the traditional project management books, easy to explain but also mimics how value of software development plays out in the modern world.
Meet the cone of uncertainty.(2)
On day 1 of doing estimates, the variance of timelines is the highest. An estimate of 4 weeks could mean 1 week or 16 weeks, you cannot predict.
As the project moves forward, more unknown variables become known, more dependencies become known and life happens, but you get more clearer about where you will hit the timeline or not. The variance in timelines continues to decrease as project progresses.
So, it is important to convey that the project is important to get started (without getting started, the timelines are just excel sheet magic), and then along the way it is important for stakeholders to keep checking into the project to know any other variables and unknowns and hence arrive at new more accurate timelines.
The aim is ‘to keep moving towards accuracy’ and not ‘be accurate the first time’
Secondly, find out if timelines are necessary
Drumsticks… yes, timelines are sometimes important even in modern software development, so do not kill the message yet.
Before moving to the typical ‘lets experiment and find out’, know some scenarios where timelines remain crucial:
Fixed-date deliverables: When there are immovable deadlines, such as regulatory compliance dates, major events, or market-driven launch windows.
Contract-based projects: For projects with contractual obligations or service level agreements (SLAs) that specify delivery dates.
Integration with other systems: When the software needs to be ready for integration with other systems or processes at specific times.
Resource allocation: To plan and allocate team members and other resources effectively across multiple projects.
Stakeholder management: To set and manage expectations with stakeholders, especially in enterprise environments or when working with external clients which have timeline expectations.
Budget constraints: When working within strict budget limitations that require careful planning of development time and resources.
Phased releases: For planning and coordinating phased rollouts or feature releases, especially in product-based development.
Dependency management: When coordinating with other teams or external partners whose work depends on or influences the software project.
So, if you do find that timelines are important, then start with a prediction of work and all the participants and dependencies coordinated to hit the timeline, ensuring that you can also do act ‘cone of uncertainity’ by revisiting timelines and budget as you progress.
For projects that are bound by timelines, here are key success factors to consider and plan for in advance(2):
But, if you find that the timeline pressure is unnecessary and not needed..
Here's when timelines become less critical and learning becomes more critical. Choice is between launching many failed projects vs. more successful products:
When building innovative or disruptive products:
For groundbreaking products, quality and market fit are more important than rigid deadlines. The focus should be on creating a product that truly solves user problems and stands out in the market.In highly competitive markets:
When facing stiff competition, releasing a superior product is often more crucial than being first to market. Rushing to meet arbitrary deadlines can result in a subpar product that fails to gain traction.For products with evolving requirements:
In markets where user needs are rapidly changing, flexibility to adapt the product is more important than sticking to predetermined timelines.When building complex systems:
For intricate software systems, ensuring robustness, scalability, and security often takes precedence over strict deadlines.In startups or new product development:
For new ventures, finding product-market fit is more critical than adhering to rigid timelines. This often requires multiple iterations and pivots based on user feedback.
Then in these cases, you should really ask your stakeholders asking for timelines:
Do you want us to meet timelines?
Do you want us to move the metrics?
Meeting timelines is for the soft-hearted, moving metrics is where the legends play
The beautiful thing about setting timelines is that you know you will feel accomplished at the end of it. You will get something done that was supposed to be done by a certain date it was supposed to done.
But such projects in modern day software development are a bit like a falling tree in a forest. Did someone really notice you completed a project in the market? Your customers probably didn’t.
It is the same thing about features.
You can launch features. It gives a sense of accomplishment.
and there are many more such vanilla stuff you can be happy about.
But if that is your approach to the market, the happiest person is your competitor.
‘Moving metrics driven by customer and market insights’ is the more difficult task.
Today the product management has evolved to understanding the market faster by doing timely rollouts and iterative deployment, rather than waiting for a big bang launch.
Since the market in hyper competitive environment is always changing, you can only dip your fingers into water at an instant to know how hot or cold the water is, and then decide the next step. You need to make use of changing dynamics of the market.
So, to convey timelines you can rather use other frameworks and not task+time driven traditional roadmap. Here’s some other ways to convey roadmap to stakeholders when you’re building in an iterative manner to address problem statements at hand:
Theme-based roadmaps:
Instead of focusing on specific features with fixed dates, organize your roadmap around themes or strategic goals. This approach allows for flexibility while still providing a clear direction.Now-Next-Later format:
Use a simple categorization of initiatives into "Now" (current focus), "Next" (upcoming priorities), and "Later" (future considerations). This provides a sense of priority without committing to exact dates.Outcome-driven roadmaps:
Focus on desired outcomes rather than specific features. This allows for flexibility in how those outcomes are achieved through iterative development.Rolling wave planning:
Provide detailed plans for the near-term (e.g., next 2-3 months) and broader, less specific plans for the longer term. Update this regularly as you progress.Confidence levels:
When discussing timelines, use confidence levels (e.g., high, medium, low) instead of fixed dates. This acknowledges the uncertainty inherent in software development.Milestone-based communication:
Focus on key milestones or release points rather than detailed timelines. This provides a framework for progress without over-committing to specific dates.Regular updates and demos:
Conduct frequent stakeholder updates and product demos to show progress. This helps manage expectations and provides opportunities for feedback and course correction.OKRs (Objectives and Key Results):
Align development efforts with broader business objectives using OKRs. This helps stakeholders see how iterative development contributes to overall company goals.
So in general, timelines serve a certain purpose, but what is the real goal that each stakeholder is behind?
Stop asking for timelines, start asking for value and metrics
This is how I balance between expectations from stakeholders and clients with how my product teams want to work.
Both sides actually want to move the metrics and create value- it could be orders, transactions.. or even revenue. Isn’t it?
But it is a pity if seniors in these companies are tracking timelines.
Emphasize the importance of delivering value over meeting arbitrary deadlines. Use metrics to demonstrate how the team is delivering value to users and the business:
Customer Feedback: Collect and act on user feedback to improve the product.
Business Impact: Highlight how delivered features are impacting key business metrics.
User Engagement: Show how new features are being adopted and used by customers