Estimation for Product Managers
Product managers are responsible not just for the products they ship, but also the processes that drive those products. One of these key processes is estimation: understanding the level of effort associated with any given initiative.
Challengingly, estimates aren’t uniform across different product organizations.
A one-month initiative at company A might require three months at company B, and a three-month initiative at company A might require only one month at company B.
So, even the most seasoned product managers must recalibrate their sense of estimates whenever they move from one organization to another.
Even more challengingly, the estimation process works differently for different sizes of engineering teams. Some engineering teams might use sprint poker, others might use person-hours, and yet others might use Fibonacci estimates.
That’s why we’ve pulled together this guide on estimates tailored specifically towards product managers. We cover:
What the value of estimation is
Estimation anti-patterns to avoid
What the cost of estimation is
How to drive estimates in smaller teams
What granularity of estimates to use as a PM
Rules of thumb to assess estimates
How to get better at estimating
Let’s start at the beginning. Why does estimation matter for software product development?
The value of estimation
Estimates provide distinct value for a variety of different groups: product managers, engineers, and stakeholders.
Product managers benefit from estimates because the estimation process provides insight into areas of complexity as well as the sustainability of upcoming workloads.
If estimates reveal that particular blocks of work will be particularly heavy, product managers can proactively partner with design and engineering to identify ways to scope down the effort without drastically cutting back on the expected benefits of that functionality.
After all, not all tasks are created equal. By using the Pareto principle, we can expect that in many cases, we can reap about 80% of the benefit using only 20% of the effort, as long as we prioritize the highest-impact components for each proposed solution.
And, when product managers have clear and defensible estimates, they can spin up the business case for particular initiatives to add to the roadmap. If the return on investment (ROI) for these initiatives is higher than those of other initiatives, PMs can advocate for additional resourcing to get these initiatives funded.
After all, companies seek to invest in the highest ROI initiatives at all times, and so if a product manager has a compelling case that identifies both the benefits and the costs of a given investment, leaders can be persuaded to shift resources around.
Engineers also appreciate estimates for multiple reasons. First, estimates make it easier for engineers and their teammates to balance workloads. By understanding what the pipeline of upcoming work looks like, they can identify whether the current workload is sustainable or not to meet a given product objective.
And, estimates enable engineers to assess which sprints were effective vs. which sprints were ineffective. By spending time in sprint retrospectives to analyze the team practices that are yielding the best results, PMs and engineering managers can jointly improve team processes over time.
Furthermore, estimates give engineers the ability to share level-of-complexity context with other engineering teammates in different groups, especially if there are cross-group dependencies.
For example, say that a front-end engineering team identifies a dependency against a platform engineering team. If the platform engineering team provides an estimate of 1 person-month, then perhaps the front-end engineering team can wait on that workstream to complete.
But, if the platform engineering team provides an estimate of 10 person-months, then the front-end engineering team should likely pursue a different initiative in the short term instead.
When engineering teams can share a high-level sense of how much work might be required to unblock the dependency, product managers and engineering managers from both teams can work together to identify how to best sequence and scope the work.
Lastly, stakeholders appreciate estimates because it helps them understand release velocity. That is, estimates enable stakeholders to have a sense for how long they should expect to wait for a particular feature. Once they have this tentative timeline in place, they can then gear up for any process changes that will come with particular releases.
After all, as product managers, we need to keep in mind that every product we ship will have downstream impacts on our stakeholders, ranging from sales to marketing to customer support to compliance. So, providing stakeholders with estimates enables them to plan their bandwidth accordingly so that they can take the right action at the right time for each product release.
But while estimates are valuable for so many different groups, they can be misused. Let’s talk about which kinds of estimation practices to avoid, and why we should avoid them.
Estimation anti-patterns
Occasionally, product teams fall into the trap of “having the estimate be the end goal” rather than simply “a tool to help facilitate the end goal.” As a reminder, the end goal is to ship the most value for users in the fastest time possible!
Therefore, we need to make sure that we don’t do the following with estimates:
Not allowing engineers to deviate from estimates
Inflating estimates to drive quarterly resource allocation
Artificially modifying estimates to look good in front of executives
First, estimates are not meant to be set in stone. The more rigorous you require the upfront estimate to be, the more time engineers have to spend on upfront investigation, which means the less time they spend actually building. Remember, we want engineers to focus on shipping value rather than filling out paperwork!
Furthermore, when engineers are asked to set estimates in stone, they’ll tend to inflate estimates to protect themselves. After all, software development is not predictable - there will always be unexpected bugs and unforeseen complexities that cannot be identified ahead of time.
Individual engineers should not be rewarded for beating estimates or punished for missing estimates on a ticket-by-ticket basis. This sort of practice induces fear and reduces psychological safety within the engineering team, leading to less innovation, less creativity, less ownership, and less customer impact in the long run.
Instead, the entire group should use estimates as a learning tool to identify the instances where the estimate was significantly different from the end result, whether the estimate was too high or too low. From there, the group can then discuss the root causes that led to that situation and find ways to address those root causes.
When used appropriately, the estimation process enables us to identify ways to improve engineering group velocity over time. And, it can groom junior engineers into senior engineers who can assess complexity and provide alternative solutions.
Second, we shouldn’t use estimates during org-wide resource allocation processes such as quarterly planning. When this happens, the PMs who provide bigger estimates receive more engineering bandwidth for their work, and the PMs who provide lower estimates receive less engineering bandwidth.
Resource allocation should be an entirely separate conversation where the business seeks to diversify and balance its portfolio of bets. The business should identify a rough ratio of how much bandwidth to invest in each product area, rather than attempt to micromanage resourcing at an initiative-by-initiative basis.
Third, we shouldn’t artificially modify the estimates to look good in front of leaders and executives.
Inflating estimates at the start and then consistently beating those estimates is not a good thing, because it means that we’re not pushing the team to think about creative ways to scope down the work and aim at more aggressive timelines.
If our playbook is to always overestimate, then we’re never seriously challenging ourselves to look for ways to yield outsized impact through creative low-cost solutions.
And, on the flip side, consistently underestimating is also not a good thing. When product managers inflate the expected ROI of their initiative by artificially deflating the estimated cost of the initiative, the company will incorrectly invest in this initiative rather than other initiatives that would have truly yielded higher ROI.
This phenomenon deprives customers from attaining the highest possible value they could have from the entire product as a whole, leading to customer churn and attrition.
We’ve now discussed how to appropriately use estimates, as well as traps to avoid when it comes to estimation. But, while estimates are valuable, we can’t get estimates for free.
The cost of estimation
Estimates take productive time away from engineers. For engineers to provide any sort of estimate, they first must understand what the desired functionality looks like, and then they need to investigate what the current architecture looks like.
Afterwards, they need to sketch out 1-3 different approaches for attacking the problem and identify any risks or drawbacks with those approaches. From there, they can then provide informed estimates for each approach and identify the path that they recommend.
That means that the people who can give the best estimates are those who are relatively senior, which means that their time is even more precious to the team.
Therefore, estimation only becomes more valuable as you add more people to the engineering team.
We need to keep in mind that every process carries an overhead cost. Estimates typically don’t make sense for small teams because the "time cost of estimating" heavily outweighs the "benefits of estimating." But, once the team becomes bigger, the benefits of estimating outweigh the time cost of estimating.
If your pod has only 1-2 engineers, then the process of adding estimates to initiatives is not valuable for engineers. But, if your pod has at least 4 engineers on the team, then it starts to make sense to implement the process of estimation.
For most engineering orgs, your engineers won’t be opposed to providing estimates, as the team is usually large enough to benefit from an estimation process.
But, let’s dig into the special case where you might be working in a very small team that would prefer not to provide estimates.
Estimates in small teams
When working with a small and nimble engineering team, you might sometimes find that they prefer to respond to one-off questions about estimates and deliverables, rather than dealing with process overhead.
But, many times, this approach is counterproductive for product managers. When you need to proactively ask engineers for estimates on a case-by-case basis, you’re operating in a “pull” model rather than a “push” model.
That means you need to dedicate significant time and effort towards repeatedly asking for updates, which reduces your ability to operate as a proactive product manager.
If you run into this situation, ask your engineers this question: "as a team, what's a way for us to provide accurate timelines without the process being a burden for engineers or PMs?"
Keep in mind that you can still get to rough deliverable timelines without having engineers estimate every single ticket that makes up a given initiative.
Many times, nimble engineering teams take issue with sprint poker or ticket-level estimates (e.g. person-hour granularity), but have no issues with giving you estimates at a feature level (e.g. person-sprint or person-month granularity).
And many times, as PMs, we don’t need to have ticket-level estimates. We only need to know the broader initiative-level estimate to keep customers and stakeholders in the loop.
A couple of ways that our conversation with our engineering counterparts might resolve:
They might agree to maintain a list of epics or features, where each sprint they'll provide updated delivery date estimates for each epic
They might agree to T-shirt sizing (large/medium/small) without getting down to the story point level, either at the epic level or at the story/task level
The return on investment of estimates (ROI = benefits / costs) is typically not as good when your team is small. The ROI only gets better as your team gets bigger.
As long as the estimation process works for the team, it's a good process. If the process doesn't work for the team, then it's a bad process.
So, be sure to use that lens as you consider what estimation process to implement - many times, processes in your company’s larger engineering org won't necessarily work for your specific situation.
Now, let’s discuss how granular estimates should be for product managers.
Using person-month estimates
The most valuable granularity for product managers is person-months, rather than story points or person-hours.
That is, even if tickets or tasks are broken down into story points, product managers should work with engineering managers to identify the person-month estimate at the initiative level, rather than the story point estimate at the feature level.
Story points are valuable for estimating complexity and workload for individual people, so this is better suited for scrum masters and engineering leads.
And, person-hours are more valuable for execution-oriented environments (e.g. billable hours for consulting or custom development), so this is better suited for technical project managers rather than product managers.
But, what exactly is a person-month? It helps to think of "a person-month" as a "unit of work" or as a "unit of effort".
As an analogy, let's look at cars (engineers), miles traveled (output), and gallons of gas (unit of effort). Here, we'll assume that 1 gallon of gas gets you 20 miles of distance (20 miles per gallon a.k.a mpg).
If you use 1 gallon of gas on 1 car, then that car can drive 20 miles.
If you split 1 gallon of gas on 2 cars so that each car gets 0.5 gallons, then each car goes 10 miles. 2 cars * 10 miles each = 20 miles total.
So, if your "unit of effort" is the same, then your "total output" is the same, irrespective of how many cars you use to split the effort. This applies to any project in the same way!
Let's say that we want to figure out "how much gas we need to buy" (i.e. how much effort will it take) for the following initiative:
Car A needs to drive 100 miles
Car B needs to drive 20 miles
Car C needs to drive 60 miles
Then, Car A needs 5 gallons, Car B needs 1 gallon, and Car C needs 3 gallons. 5+1+3 = 9 gallons total.
The PM equivalent of this: imagine you have a project where Person A needs 5 months, Person B needs 1 month, and Person C needs 3 months. Then, you need 5+1+3 = 9 person-months worth of effort for this project.
As a different scenario, let's say we don't know how many cars we have on hand. All we know is that we need to drive 200 miles.
200 miles / 20 mpg = 10 gallons required, and we can allocate these gallons to however many cars we have on hand.
The PM equivalent of this: you estimate that you need to finish 50 story points worth of work, and you know that 1 engineer can finish 5 story points every 2 weeks.
How many person-weeks worth of work is this?
50 story points / (5 points per person / 2 weeks) = 50 / 2.5 = 20 person-weeks.
If you have 5 engineers on the team, then you could evenly split 20 person-weeks into 20 / 5 = 4 weeks per person.
Or, you could have one person tackle 8 weeks of work, and have the other four people tackle 3 weeks of work each.
So, to recap: think of "person-time" (person-weeks, person-months, person-days, etc.) simply as a unit of effort, the way that you'd think about a gallon of gas or a tank of gas.
You can split the effort across lots of people, or you can keep the effort concentrated on one person. But, ultimately, to travel some given distance (or to get some desired output), you must spend that much total effort regardless of how many people you split it across.
The value of splitting it across people is that it gets done faster - but it doesn't decrease the total effort involved!
Now that we understand what granularity to use for estimation, let’s talk about rules of thumb when it comes to sizing and estimating work.
Estimation rules of thumb
Each product organization works with different tech stacks and different constraints, so estimates will differ from org to org.
Still, we can use the following rough rules of thumb to assess effort and complexity:
1 person-week for lightweight visual changes (e.g. words, sizes, colors)
1 person-month for logic changes (e.g. if-then logic, ordering logic, display logic)
1 person-quarter for new UX behavior (e.g. animations, registration, navigation)
1 person-year for new architecture (e.g. new microservices, new integrations, refactors and abstractions)
In some cases, these guidelines won’t apply. I’ve seen lightweight visual changes require 3-6 person months due to underlying architecture changes required, and I’ve seen microservices get spun up within 2 person months.
By having these rough guidelines at hand, you can now have a more informed conversation with engineering counterparts. If your tech lead provides an estimate that’s significantly lower or higher than expected, take the time to understand their rationale.
The point is not to distrust them or to question their judgment, but rather to understand the specific nuances of your tech stack, and how these nuances contribute to higher or lower levels of complexity for given kinds of work.
Getting better at estimates
As a PM, you’re not responsible for coming up with individual estimates, but it’s valuable to start calibrating your sense of how large a particular initiative will likely be.
When we get better at estimates, we can prioritize at a higher level. That is, we can get a rough sense at an epic level whether a given area of investment makes sense to pursue, rather than waiting on a full decomposition from engineering at a feature level or a ticket level to inform our assessment of ROI.
Furthermore, when we get better at estimates, we can start to identify places where we can encourage our engineering teams to find creative solutions to reduce effort without impacting value. And, just as crucially, we can also identify the places where it’s simply not productive to make these kinds of requests, due to the underlying architectural constraints of our product.
To strengthen your calibration around estimates, proactively participate during sprint planning, and don’t hesitate to ask good questions about why some efforts take longer than others.
We also recommend that you take the time to sync with your engineering manager counterpart during quarterly planning and ask for a quick primer on why some initiatives take more effort than others.
Closing thoughts
As a product manager, you’re in charge of the entire product development process from end to end. Therefore, you’ll want to have a strong grasp of the pros and cons of estimates, so that you can partner with engineering to implement the right kind of estimation process for your specific context.
The goal of estimation is not to point fingers and blame others for dropping the ball. Rather, it’s to get an overall sense of the work, to make product scope tradeoffs before we ship any code, and to evolve as a team towards making more informed decisions.
By strengthening our estimation processes as a team, we’ll provide the most value we can for our user and our customers over the long run.
Thank you to Pauli Bielewicz, Mary Paschentis, Siamak Khorrami, Goutham Budati, Markus Seebauer, Juliet Chuang, Kendra Ritterhern, and Carol Zhang for making this guide possible.
