Hey, I’m Colin! I help PMs and business leaders improve their technical skills through real-world case studies. For more, check out my Live cohort course and subscribe on Substack.
How estimates usually work
Let’s set a scene:
It’s 3 weeks until your Q1 roadmap kicks off. You’ve been wrapping up annual planning and just realized you need to get your roadmap out by the end of the week.
You take a look at your backlog, some customer requests, and the PRD you wrote 6 months ago that didn’t make the cut. You cobble together a quick spreadsheet with deliverables, a blank column for engineering estimates, and some requests that came in from another team they said were important. You fill in “TBD” for engineering estimates.
The next day, you do some clean up and share the doc with your engineering manager. You ask for quick estimates for each line item. Because you’re a good PM, you reserve 20% of the roadmap for “engineering stuff”.
Your EM does their best to guess how long each item will take. You wrap up with some capacity planning, showing you’re at 105% of your engineering capacity if you include PTO and sick days.
Then, the quarter starts. Engineers skim the PRD and tell you there’s a dependency on the infrastructure team. Then they stop reading. Infrastructure doesn’t have capacity (they’re at 115% for Q1) but they’ll try to squeeze you in.
3 weeks into the quarter, the feature you had estimated for 7 weeks is already done, your engineers had unexpected critical security updates, and you’re asking for updated estimates based on new dependencies.
If you’ve ever worked in large enterprise products, you’ve probably experienced something like this. Unfortunately there isn’t a silver bullet solution – coordinating many dependencies across teams is hard, even for the highest performing organizations. Some organizations flip entirely to engineering-led product development (PostHog, Linear) but this isn’t the norm in large organizations.
But there is a better way - a way to not only get better estimates, but also improve the quality of both your product and decision making.
How to get better estimates (and make better decisions)
Let’s imagine an alternative timeline. One that’s better but still realistic.
Building Product Sense
In the past quarter, you’ve been regularly meeting with customers to talk about your product. You’ve kept notes on what they care about and dove into the rationale for their requests. You have a general sense of what needs to improve for them to get better outcomes from your product. You’ve developed some product sense.
You’ve also maintained relationships with your finance and sales teams. You know what the levers are that make the numbers go up.
Throughout the quarter, you’ve been drafting something like a PRD. They’re really just notes on what you could improve and how those improvements would impact the business and your customers.
Drafting PRDs
6 weeks before the start of the quarter, you formalize your notes into a few draft PRDs. These aren’t for this quarter necessarily – they’re just the most important things you think you should work on right now.
You get some feedback from customers on the proposed solutions. You’re not walking though mockups, you’re trying to validate what outcomes they really care about. If it's internal customers, you make sure you’ve nailed the workflows and there won’t be any major surprises.
You share the docs with your team for review and comment. A few people read them but they’re busy - and that’s okay. You already set up a live call to review. On the call, you summarize the important points for engineering and ask them if they see any major obstacles or gaps. You clean up the doc together.
Building Roadmaps
Now, it’s time for roadmapping. You grab the docs that outline the most impactful work your team can do. You ask your engineering manager for estimates for the initiative as a whole, not for individual line items within it.
You prep your roadmap with a clear opinion on why you selected these specific initiatives. If there’s technical debt, you include it because it has a meaningful impact on your team’s ability to ship or the customer’s experience.
When the quarter starts, you have kickoff calls booked with all the relevant stakeholders for each initiative. Some unexpected things come up, the PRD gets adjusted, and you continue forward.
The engineering estimates are still off – they can’t predict the future – but at least they’ve served a purpose. Your team is aligned on the work to be done, engineers understand the customer and business value, and you are able to form a clear opinion on what should be done and why.
How do I improve engineering estimates?
If you’d like to give this a try, here’s a few tips to get you started:
1) Spend more time with customers
Spending time with customers is by far the most important part of good roadmapping. There is a direct relationship between the product manager understanding what the customer actually wants and the accuracy of engineering estimates. The most common reason that estimates end up being wrong is that the feature needs large changes based on feedback that comes too late.
2) Don’t back yourself into a corner
When putting together your roadmap, watch out for explicit commitments on small-grained deliverables. These often apply pressure to the team to meet a series of small deadlines rather than using the total allotted time to build the best solution. It’s completely normal for some things to change during delivery and protecting the team from negative feedback here is critical
3) Partner with engineering
Many gotcha’s that come up during delivery could have been caught during planning if there was more overlap between product and engineering. Engineering estimates improve dramatically when engineers understand the context and feel ownership of the problem and solution. Include engineers in customer discussions and share business context and metrics. Listen to technical concerns and ideas, and give space for technical exploration.
4) Start early
Quality planning takes time. Starting early lets you focus on getting it right rather than just getting it done. Maintain ongoing discovery work and document insights as you go. Build relationships before you need them and give time for thoughtful review.
5) Match your organizations expected outputs
The reality for all of us is that each organization has their own way of doing things. Rather than fighting upstream against these processes, find ways to establish best practices for yourself while still meeting expectations.
6) Understand the role of estimates
Estimates on individual tasks should not be used for building gantt charts or creating project plans. Think of them as relative estimates of complexity.
If your entire engineering team agrees a task will take 2 weeks, that just means it will take no less than 1 and no more than 4. Don’t rely on estimates for absolute values when planning.
Wrapping Up
Bad engineering estimates are most often a result of missing information. By closing this gap through better planning, you can reduce the churn of roadmapping and dependencies.
Estimates will never be perfect but they can get better!
Up Next
If you enjoyed this post, you’ll probably also like:
I completely vouch for T-shirt sizing the effort at the PM level for starters. It is not a silver bullet and is a really slow process to get the hang of, but it certainly helps to get a better hold of your product.