How Product Teams Should Set Deadlines

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1847

Abstract

e really important, and to put a stake in the ground by building only the minimal feature set.</p><p id="6aae">And this isn’t just a one-time thing. Teams should regularly assess their current and future work, and then they should themselves whether they can complete this work by the deadline. If the answer to that is “no” or even “maybe,” they should figure out what can be removed from scope to change that answer to a “yes.” In some cases they may choose to move the deadline, but we will get to that in a second.</p><p id="ea2a">The truth is that these two methods aren’t mutually exclusive. You can consider how much will fit and also encourage people to work hard to fit that. Pretty much every non-trivial project I have worked on has had its schedule slip at some point in the process. There will be times where your team bite off more than you can chew, even if it originally seemed like the estimates were conservative. When you come to that point, you will need to decide whether to push or to cut scope, and in some cases you will do both.</p><h1 id="45a9">Taking a bottoms-up approach</h1><p id="575f">So I when I mentioned that there is a top-down approach, where you start with the deadline and work backwards, there is also a bottoms-up approach. In the bottom up approach, you set the deadline by estimating each of the individual pieces and then adding in some buffer. This sounds good, but in practice it’s kind of a black art. Estimating engineering tasks is often an error-prone process, both because there will be unknown complications and because the timing will vary based on who is actually doing the work.</p><p id="1eac">Some engineering managers build sophisticate methods for “costing” projects. These can sometimes work well if you are working with a known team on a well-quantified task. But the truth is that ther

Options

e are just too many sources of uncertainty for this to work well in any general case. A good costing system may be able to differentiate between a one month project and a two month project, but that’s going to be about it.</p><p id="010e">The way most teams handle this uncertainty is by adding in buffer, typically somewhere in the 50–100% range. When I have engineers estimate tasks, I typically ask them to use powers of two, so a task will take one day, two days, a week, or two weeks, and any attempts to use finer granularity are rejected. One engineer I know told me that she recently shipped a feature on time by multiplying her initial estimates by three. While this sounds extreme, this is a pretty common practice.</p><h1 id="4ffd">Adding a buffer is actually healthy</h1><p id="da96">I personally think it’s fine to add in a generous buffer to every project. The purpose of a goal is not to know exactly when a project will ship, but to come up with a timeline that people are willing to commit to. There are a lot of ways that bad managers can strong arm people into committing to an overly aggressive goal, and I’m not a fan of any of these. I think that the “How” owner should have the ability to figure out how long the project will take, and the rest of the team should respect that process. If that number is too high, then she can go to the “What” owner and make an argument for reducing scope.</p><p id="f123">Ultimately, the deadline should be a combination of top-down and bottoms-up. The top down number can be determined by the business needs, and the bottom-up goal can be determined by the level of effort required. If those two numbers differ by too much, then there can be adjustments in either prioritization or scope. At the end of day, a deadline that can’t be met isn’t really a deadline at all.</p></article></body>

How Product Teams Should Set Deadlines

A few months back, I wrote a post entitled “The Why, What, and How of the Modern Product Team.” It was fairly well received, but one of my readers suggested that I answer the “When.” This is a tricky topic, because I don’t think there is any one correct answer.

There are really two different ways you can handle deadlines. The first is to go top down, and begin by choosing the deadline. Basically, you start by deciding when the product or feature will ship, and everything is subservient to that fixed point in time. This can happen when the release date is set by a business requirement such as a conference or a customer commitment.

How to approach a fixed deadline

There are two different ways you can handle a fixed deadline; the first is to push people to work as hard as is required to meet the schedule. And some managers really believe that teams can stretch to meet pretty much any deadline. While this strikes me as a good way to burn people out, there is probably some truth in saying that people will rise to the occasion. Setting a due date is a good way to focus people on actually completing a project.

The second way to work with a fixed deadline is to adjust scope until you have something that is shippable within the specified time frame. Once you know the deadline, you can work backwards and figure out how much you will have time to complete. This can be a good practice, as it forces you to decide what features are really important, and to put a stake in the ground by building only the minimal feature set.

And this isn’t just a one-time thing. Teams should regularly assess their current and future work, and then they should themselves whether they can complete this work by the deadline. If the answer to that is “no” or even “maybe,” they should figure out what can be removed from scope to change that answer to a “yes.” In some cases they may choose to move the deadline, but we will get to that in a second.

The truth is that these two methods aren’t mutually exclusive. You can consider how much will fit and also encourage people to work hard to fit that. Pretty much every non-trivial project I have worked on has had its schedule slip at some point in the process. There will be times where your team bite off more than you can chew, even if it originally seemed like the estimates were conservative. When you come to that point, you will need to decide whether to push or to cut scope, and in some cases you will do both.

Taking a bottoms-up approach

So I when I mentioned that there is a top-down approach, where you start with the deadline and work backwards, there is also a bottoms-up approach. In the bottom up approach, you set the deadline by estimating each of the individual pieces and then adding in some buffer. This sounds good, but in practice it’s kind of a black art. Estimating engineering tasks is often an error-prone process, both because there will be unknown complications and because the timing will vary based on who is actually doing the work.

Some engineering managers build sophisticate methods for “costing” projects. These can sometimes work well if you are working with a known team on a well-quantified task. But the truth is that there are just too many sources of uncertainty for this to work well in any general case. A good costing system may be able to differentiate between a one month project and a two month project, but that’s going to be about it.

The way most teams handle this uncertainty is by adding in buffer, typically somewhere in the 50–100% range. When I have engineers estimate tasks, I typically ask them to use powers of two, so a task will take one day, two days, a week, or two weeks, and any attempts to use finer granularity are rejected. One engineer I know told me that she recently shipped a feature on time by multiplying her initial estimates by three. While this sounds extreme, this is a pretty common practice.

Adding a buffer is actually healthy

I personally think it’s fine to add in a generous buffer to every project. The purpose of a goal is not to know exactly when a project will ship, but to come up with a timeline that people are willing to commit to. There are a lot of ways that bad managers can strong arm people into committing to an overly aggressive goal, and I’m not a fan of any of these. I think that the “How” owner should have the ability to figure out how long the project will take, and the rest of the team should respect that process. If that number is too high, then she can go to the “What” owner and make an argument for reducing scope.

Ultimately, the deadline should be a combination of top-down and bottoms-up. The top down number can be determined by the business needs, and the bottom-up goal can be determined by the level of effort required. If those two numbers differ by too much, then there can be adjustments in either prioritization or scope. At the end of day, a deadline that can’t be met isn’t really a deadline at all.