We've all been there as PMs, we communicate a timeline based on an estimate and it turns out to be wildly off. Engineering says something will take one week and it ends up taking three. Three weeks takes six. Six weeks takes ten. This hurts you in a number of ways: customers feel like you pulled one on them, roadmap priorities need to be adjusted, another round of communication needs to go out to stakeholders, and on and on.
It's a hassle for sure, but also a daily reality for every product manager. While there are strategies (I discuss one below) to produce more accurate estimates, the more pragmatic approach is to treat estimates as the incomplete information that they are and plan for estimates to be wrong from the start.
How can we do this? There are multiple ways, but I’ll discuss a few specific strategies that have helped me.
Design a balanced roadmap
Make sure your roadmap includes a mix of small, medium, and large projects. This way if a project ends up getting delayed, you can still continue to deliver value to customers. What you want to avoid is having a roadmap that only consists of large projects and a delay potentially creates a devastating cascading effect that ruins your entire quarter or longer. If something does end up getting delayed, do you have backup projects you can seamlessly insert into the roadmap?
A key skill in planning a balanced roadmap is getting good at t-shirt sizing projects in a way that lets you always sprinkle in some smaller wins. That leads me to my next and most widely used strategy.
Become an expert at padding estimates
To do this, you need to understand exactly what kind of changes engineering will need to do well ahead of development getting started. Talk to your engineers early and often, introduce project concepts, and figure out what needs to get done for a feature to get implemented. You don't need any designs to do this.
Are there going to be new internal APIs developed or updated? Are there database migrations? Do some core validations have to be revisited? Is it a particularly nasty part of the app that might need a refactor? All of these tell you something. A database migration and update to a core internal API is a sensitive set of changes. If an engineer tells you roughly three weeks to do that, then you can use your best judgment and decide if you want to plan for it taking six.
While you may not have ever built this specific feature before, your engineers have definitely done this type of development work before, so you can also take a look at historical data to see how long it took in the past.
Limit the amount of large projects you do
This builds on the prior two strategies, but you absolutely need to limit the amount of large projects your team is undertaking at once. It’s not just engineering, we are all bad at estimating how long something is going to take and especially when we think it’s going to take a while.
If an engineer says something will take a day, it’s very likely to be accurate. A week? Less accurate, but still pretty spot on. A month? Now we’re getting into the danger zone. A quarter? This could easily become 2 or more quarters.
The rule is simple: the less large projects you have, the less variance in your timelines, the less unpredictability you have to deal with.
Conduct one or more technical spikes
This is something you can implement to try and produce more accurate estimates. Before any kind of estimate, add some room to your sprint (or however you plan your work) and have engineering do a technical spike or proof of concept so they can get a better understanding of how this feature might be implemented. This should lead to a more accurate estimate AND will arm you with valuable information about any potential hiccups that could happen during development. It might even produce a really cool demo to get the rest of the company excited about what’s to come.
Instead of lamenting that you've been hit with a delay or bad estimate, treat inaccurate estimates as a fact of life and plan around them. You'll have a much less stressful time managing delays when (not if) they happen.