6 ms·

How product teams should set deadlines

63 points by dlevine 4y ago

donatj 4y ago
We never really had deadlines, especially not firm ones. Things went out when they were done, we maintained very minimal technical debt and a very high quality app. Things got love when they needed it, not on a timeline. We had a very loyal customer base. We got bought out. We got firm deadlines for features we didn't want from on high. Quality dipped, technical debt soared, and customer retention dropped. Our overall sales went down in the name of pushing out low quality features fast. It was nice while it lasted.
- dopidopHN 4y ago
  I’m experiencing that right now. It’s crazy fast, too. A few key people left, the team is somewhat overwhelmed. And now we have to ship no matter what. Quality is dropping already.
- cjonas 4y ago
  I'm on a project that started with a deadline before we really even knew what we were building (months away from that deadline and we still don't). Despite seemly unlimited budget to throw at it, technical debt is out of control and we're already moving slow. I get pulled into 8 hour meetings every other week where 30+ people try to "plan" our way into building faster. There are countless challenges with this project, but the forced timeline is by far the worst of it.
  - donatj 4y ago
    > I get pulled into 8 hour meetings every other week where 30+ people try to "plan" our way into building faster. Somehow we've thus far managed to keep our "as few meetings as possible" culture. Our original founder (whose since been let go, if that's any indication) hated meetings and had rules that were basically: 1. No meetings that could be an email 2. No one has to be in a meeting who doesn't want to be there 3. No PowerPoints Other departments have bi-weekly day long planning meetings. We have hour long "goals for the quarter" meetings, quarterly. Once in a while a retro when PMs from higher up force them on us.
    - jordanbeiber 4y ago
      Retros can be great though, to be fair. If approached as a way to adapt ways of working - e.g ”we’ve had to many pointless meetings that could have been asynchronous slack messages.”
  - jseban 4y ago
    > I get pulled into 8 hour meetings every other week where 30+ people try to "plan" our way into building faster. The beatings will continue until morale improves.
- drawkbox 4y ago
  Products are like creative works, they should be built with depth, deep dives and aim to be a fun experience and friend of the user. Bottom up processes can create great products with polish and love, they are value creation processes. Top down processes and deadlines create shallow features and products, they are value extraction processes. Games for instance especially should focus on the fun and gameplay mechanic. Arbitrary timelines, milestones and push can kill both of those very important things. This doesn't apply to just games though, products should be fun, bring joy and be almost a friend/companion of the user. All that is lost when you move to today's finance/marketing/business led value extraction style over the creative/design/development approach of value creation. Agile was supposed to give more time to the value creators, but instead it became a micromanagement tool of the value extractors and the depth has been made shallow. When you slow the "velocity" to add in some love/fun, you are now the problem not the solution, which is completely backwards. The best value creation process is just an iterative/incremental cycle, with lots of power in the court of the value creators over the value extractors.
metadat 4y ago
"should" is a pretty poor choice of wording, and best to avoid using in nearly all cases. Why should we consider to this opinion? Given the crappy title, why should one even bother clicking on the link? Sorry, it's intended as a personal criticism (in fact, my intention is the opposite!), but the decision sets the stage for quite a weak and unpersuasive argument.
- kadoban 4y ago
  > why should one even bother clicking on the link? You can't even avoid using the word in your admonition against using the word though. What's better phrasing, and why?
  - metadat 4y ago
    I used it sarcastically, there's always a better way to say it. Use your imagination! "How we make life better for our team by setting deadlines" The possibilities are endless.
    - kadoban 4y ago
      > How we make life better That's overly ambitious, and the meaning is also completely different. That says that setting deadlines itself improves life, which is not what the article or original title are saying. > Use your imagination! My imagination is okay with "should", when the benefits will be spelled out later, which they are in the article.
      - metadat 4y ago
        It's all good, glad it works for you. I found that for me, when I paid attention to the "shoulds" it was a bigger burden than it was worth for not much gain. Thus I learned it's best to filter them out in favor of messaging that is less preachy and more nuanced. It's a tradeoff, as inevitably I'll miss some good ones but overall it seems like a better way to allocate my attention. Ymmv :)
jdlshore 4y ago
The article describes a predictive project-management approach, and it's the same misguided focus on deadlines you hear from people with a predictive mindset. But an adaptive approach is so much more effective. The adaptive approach: Products should ship as soon as they're ready for market, not according to some deadline. To ship sooner, they should be sliced into pieces that have compelling individual value. Each piece is shipped when ready. And those pieces ("valuable increments") should be sliced into even more pieces that could be shipped sooner in case new business opportunities come along. That way, when that new business opportunity comes along, you're not left with a choice between abandoning work or ignoring the opportunity in favor of finishing what you started. There are times when deadlines matter, such as regulatory requirements, tax season, the Christmas shopping season... but people who are "setting deadlines" aren't talking about real deadlines; they're talking about artificial deadlines because they think it's the right way to manage software teams. (They don't understand that managing by deadline causes teams to compromise internal quality, and that hurts productivity, which creates stress, which forms a vicious cycle that further harms quality and productivity.) If you do have a real deadline, the correct way to manage the risk of missing that deadline is to, once again, use an adaptive approach: identify the smallest thing that will mitigate the risk, build that first, and then incrementally expand from there in as small pieces as possible. Keep the software shippable at every step of the way and ship on the deadline with whatever you finished.
- klenwell 4y ago
  This is a good argument for continuous release and agile over waterfall. When making estimates, I also like to differentiate between what I call happy-path projections and lazy-bayesian estimates. The former take a sort of get-there-from-here best-case-scenario approach with some buffer tossed in to make it seem like we're not completely delusional. Lazy-bayesian estimates try to identify similar projects or references as a baseline for forecasting. Daniel Kahnemann refers to the two approaches as the inside and outside view in Thinking Fast and Slow and offers an excellent tale to illustrate the difference: http://txti.es/kahneman-outside-view http://txti.es/kahneman-outside-view I wish I could get every project manager I work with to read this. (I've tried.)
- presentation 4y ago
bruce511 4y ago
The article sums up the approach I first read by the c++ spec committee. "pick a date, but not features, or pick features but not a date" I now often have arbitrary release dates for projects, but when I'm asked if x will be included or not I reply I don't know. We'll all find out together on that day. After that date the project gets regular updates (often weekly) with new stuff. Updates are on the "when it's ready" basis. This approach has worked well, when asked I explain the logic, and it seems to satisfy those that need a date (marketing et al) and also those needing features. The former can plan events around the date, the latter know they'll get their pet feature as soon as its ready. Both understand that I have constraints that make predicting unreliable.
a_c 4y ago
A product can mean a team that build - an one off project - an imaginary product solving imaginary problem - A MVP that verifies a hypothesis and taking care the whole customer journey - iteration and improvement of mvp - part(s) of customer journey - feature(s) Deadline means different thing to different team. As other comment point out, there are real deadlines. When not real, deadline is about a rthym, about a pacing, about expectation at different stage, rather than a specific expectation that by an arbitrary date everything will be "done done". And who's doing the estimation is as important as what the estimation is. In music, the time signature is to give expectation what pacing a piece is in. It is futile to pack more notes than the member can play. The job of the composer is to know what is within the possible realm of playability and to assemble a team that can handle it. You don't "push" a member, you understand the member. Same for software product building
davidkuennen 4y ago
As a Product Manager I avoid deadlines like the plague. They are always wrong, pressure the team and lead to worse results.
meerita 4y ago
+12 years PM here. Good teams know how to estimate. Estimations are that, estimations and not solid predictions. Deadlines should be blurry enough to have the idea when business can have something, and never fixed dates. The reason is simple: people get sick, people find new corner cases, problems, technical difficulties and day-to-day operations will sabotage (indirectly) the excution to deliver that new project.
- knightofmars 4y ago
  Exactly! Estimates are useful and volatility is real.
Falkon1313 4y ago
I'd say in my experience both deadlines and estimates are garbage 90% of the time. What really matters is prioritization. Are you focusing on the right things, the impactful things? Are you also prioritizing all the 'not-so-shiny' stuff (performance, security, etc.)? Do you have actual levels of priority (instead of just making everything top priority, which is no priority at all)? If you prioritize well, then you'll always be delivering the top priorities and some of the mid-level priorities. On a good week, you'll also knock out some of the low-priority stuff. And all of the concerns will be getting addressed. And everyone will be happy. The developers will feel good, management will be happy, and the customers will be pleased. Deadlines or estimations will be largely irrelevant. But if you prioritize sloppily, and constantly change priorities, so you're always yanking people out of the middle of one thing to work on another that is suddenly the highest high priority among all the other tasks all of which are high priority, then you'll always get less done. Some random assortment of stuff will get done, but it doesn't look important, at least not any more important than the stuff that didn't get done. No one will be happy. Some concerns will go entirely un-addressed. And no amount of deadlines or estimation will fix that. I'd much rather be working for a good prioritizer than the world's best psychic estimator and the world's best deadline forecaster anyday.
- nivertech 4y ago
  Prioritization Deadlines / Milestones Estimations Informal - no prioritization/deadlines/estimations
- jseban 4y ago
  I agree, deadlines and estimates are used to cover up for product actually not having a solid use case and design in the first place. Which is also not just blame the people that work as product managers, but also a critique of Agile swerving too far away from waterfall and now having no method whatsoever for requirement analysis and leaving a lot of really important work to fall through the cracks.
- snidane 4y ago
  What matters is prioritization and momentum. You're gonna get more people aligned if you focus on things that other teams happen to be working on at the same time. If you decide to work on something else when there is a huge infrastrucuture design project going on, just because of some precommitted sprint plan, you're gonna play catch up later. If you keep dropping a task for another because of arbitrary sprint plan, you're gonna be jerking yourself and the team around and never getting people get aligned with what you're building for long enough and it'll ge harder to get feedback from them. Momentum matters, especially for multi product teams, such as in data science and data engineering.
morsanu 4y ago
Arbitrary deadlines are only valuable as checkpoints to review work done and plan ahead. Using them as a timeframe to finish some tasks shows that you don't really understand estimates.
trhoad 4y ago
I think the term is "bottom-up", not "bottoms-up", which has a slightly different meaning...
20375587 4y ago
black_13 4y ago
senko 4y ago
Yeah, this doesn't sound like a modern approach to managing timelines. What's described here is "take the estimate and multiply it by some factor, adding a buffer, and then commit to it" approach, which is an ancient rule of thumb. As other commenters here pointed out, a more realistic approach is to either have a fixed deadline with flexible scope (time-based delivery) or fixed scope but flexible on when it's going to be finished (feature-based delivery). Problem with feature-based delivery is that nothing else can depend time-wise on it. If you have a big product launch and need to prepare marketing, buy ads, or execute on some contracts, "it'll be done when it's done" is not going to fly. This is an example of a real, hard deadline, that needs to be dealt with. The management problem I see in many organizations is managers conflating "estimates" (internally produced timelines that may or may not be achieved) with "deadlines" (externally produced constraints). These two are often handled in the same way. In a team where the managers/product owners/clients do understand and keep the difference in mind, engineers feel free to estimate without fear of putting a noose around their neck, and in turn understand that some things may be externally forced at a specific date.
c_o_n_v_e_x 4y ago
The issues with scheduling IMO highlight a deeper topic: culture. Specifically, are you product led or sales led company? Throughout my product career, arbitrary dates have come from sales committing to a random date to close a deal (which also leads to other problems when Sales starts acting as Product, coming up with new "features".)

63 points by dlevine 4y ago

We never really had deadlines, especially not firm ones. Things went out when they were done, we maintained very minimal technical debt and a very high quality app. Things got love when they needed it, not on a timeline. We had a very loyal customer base. We got bought out. We got firm deadlines for features we didn't want from on high. Quality dipped, technical debt soared, and customer retention dropped. Our overall sales went down in the name of pushing out low quality features fast. It was nice while it lasted.

dopidopHN 4y ago
I’m experiencing that right now. It’s crazy fast, too. A few key people left, the team is somewhat overwhelmed. And now we have to ship no matter what. Quality is dropping already.
cjonas 4y ago
I'm on a project that started with a deadline before we really even knew what we were building (months away from that deadline and we still don't). Despite seemly unlimited budget to throw at it, technical debt is out of control and we're already moving slow. I get pulled into 8 hour meetings every other week where 30+ people try to "plan" our way into building faster. There are countless challenges with this project, but the forced timeline is by far the worst of it.
- donatj 4y ago
  > I get pulled into 8 hour meetings every other week where 30+ people try to "plan" our way into building faster. Somehow we've thus far managed to keep our "as few meetings as possible" culture. Our original founder (whose since been let go, if that's any indication) hated meetings and had rules that were basically: 1. No meetings that could be an email 2. No one has to be in a meeting who doesn't want to be there 3. No PowerPoints Other departments have bi-weekly day long planning meetings. We have hour long "goals for the quarter" meetings, quarterly. Once in a while a retro when PMs from higher up force them on us.
  - jordanbeiber 4y ago
    Retros can be great though, to be fair. If approached as a way to adapt ways of working - e.g ”we’ve had to many pointless meetings that could have been asynchronous slack messages.”
- jseban 4y ago
  > I get pulled into 8 hour meetings every other week where 30+ people try to "plan" our way into building faster. The beatings will continue until morale improves.
drawkbox 4y ago
Products are like creative works, they should be built with depth, deep dives and aim to be a fun experience and friend of the user. Bottom up processes can create great products with polish and love, they are value creation processes. Top down processes and deadlines create shallow features and products, they are value extraction processes. Games for instance especially should focus on the fun and gameplay mechanic. Arbitrary timelines, milestones and push can kill both of those very important things. This doesn't apply to just games though, products should be fun, bring joy and be almost a friend/companion of the user. All that is lost when you move to today's finance/marketing/business led value extraction style over the creative/design/development approach of value creation. Agile was supposed to give more time to the value creators, but instead it became a micromanagement tool of the value extractors and the depth has been made shallow. When you slow the "velocity" to add in some love/fun, you are now the problem not the solution, which is completely backwards. The best value creation process is just an iterative/incremental cycle, with lots of power in the court of the value creators over the value extractors.

metadat 4y ago

"should" is a pretty poor choice of wording, and best to avoid using in nearly all cases. Why should we consider to this opinion? Given the crappy title, why should one even bother clicking on the link? Sorry, it's intended as a personal criticism (in fact, my intention is the opposite!), but the decision sets the stage for quite a weak and unpersuasive argument.

kadoban 4y ago
> why should one even bother clicking on the link? You can't even avoid using the word in your admonition against using the word though. What's better phrasing, and why?
- metadat 4y ago
  I used it sarcastically, there's always a better way to say it. Use your imagination! "How we make life better for our team by setting deadlines" The possibilities are endless.
  - kadoban 4y ago
    > How we make life better That's overly ambitious, and the meaning is also completely different. That says that setting deadlines itself improves life, which is not what the article or original title are saying. > Use your imagination! My imagination is okay with "should", when the benefits will be spelled out later, which they are in the article.
    - metadat 4y ago
      It's all good, glad it works for you. I found that for me, when I paid attention to the "shoulds" it was a bigger burden than it was worth for not much gain. Thus I learned it's best to filter them out in favor of messaging that is less preachy and more nuanced. It's a tradeoff, as inevitably I'll miss some good ones but overall it seems like a better way to allocate my attention. Ymmv :)

jdlshore 4y ago

The article describes a predictive project-management approach, and it's the same misguided focus on deadlines you hear from people with a predictive mindset. But an adaptive approach is so much more effective. The adaptive approach: Products should ship as soon as they're ready for market, not according to some deadline. To ship sooner, they should be sliced into pieces that have compelling individual value. Each piece is shipped when ready. And those pieces ("valuable increments") should be sliced into even more pieces that could be shipped sooner in case new business opportunities come along. That way, when that new business opportunity comes along, you're not left with a choice between abandoning work or ignoring the opportunity in favor of finishing what you started. There are times when deadlines matter, such as regulatory requirements, tax season, the Christmas shopping season... but people who are "setting deadlines" aren't talking about real deadlines; they're talking about artificial deadlines because they think it's the right way to manage software teams. (They don't understand that managing by deadline causes teams to compromise internal quality, and that hurts productivity, which creates stress, which forms a vicious cycle that further harms quality and productivity.) If you do have a real deadline, the correct way to manage the risk of missing that deadline is to, once again, use an adaptive approach: identify the smallest thing that will mitigate the risk, build that first, and then incrementally expand from there in as small pieces as possible. Keep the software shippable at every step of the way and ship on the deadline with whatever you finished.

klenwell 4y ago
This is a good argument for continuous release and agile over waterfall. When making estimates, I also like to differentiate between what I call happy-path projections and lazy-bayesian estimates. The former take a sort of get-there-from-here best-case-scenario approach with some buffer tossed in to make it seem like we're not completely delusional. Lazy-bayesian estimates try to identify similar projects or references as a baseline for forecasting. Daniel Kahnemann refers to the two approaches as the inside and outside view in Thinking Fast and Slow and offers an excellent tale to illustrate the difference: http://txti.es/kahneman-outside-view http://txti.es/kahneman-outside-view I wish I could get every project manager I work with to read this. (I've tried.)
presentation 4y ago

bruce511 4y ago

The article sums up the approach I first read by the c++ spec committee. "pick a date, but not features, or pick features but not a date" I now often have arbitrary release dates for projects, but when I'm asked if x will be included or not I reply I don't know. We'll all find out together on that day. After that date the project gets regular updates (often weekly) with new stuff. Updates are on the "when it's ready" basis. This approach has worked well, when asked I explain the logic, and it seems to satisfy those that need a date (marketing et al) and also those needing features. The former can plan events around the date, the latter know they'll get their pet feature as soon as its ready. Both understand that I have constraints that make predicting unreliable.

a_c 4y ago

A product can mean a team that build - an one off project - an imaginary product solving imaginary problem - A MVP that verifies a hypothesis and taking care the whole customer journey - iteration and improvement of mvp - part(s) of customer journey - feature(s) Deadline means different thing to different team. As other comment point out, there are real deadlines. When not real, deadline is about a rthym, about a pacing, about expectation at different stage, rather than a specific expectation that by an arbitrary date everything will be "done done". And who's doing the estimation is as important as what the estimation is. In music, the time signature is to give expectation what pacing a piece is in. It is futile to pack more notes than the member can play. The job of the composer is to know what is within the possible realm of playability and to assemble a team that can handle it. You don't "push" a member, you understand the member. Same for software product building

davidkuennen 4y ago

As a Product Manager I avoid deadlines like the plague. They are always wrong, pressure the team and lead to worse results.

meerita 4y ago

+12 years PM here. Good teams know how to estimate. Estimations are that, estimations and not solid predictions. Deadlines should be blurry enough to have the idea when business can have something, and never fixed dates. The reason is simple: people get sick, people find new corner cases, problems, technical difficulties and day-to-day operations will sabotage (indirectly) the excution to deliver that new project.

knightofmars 4y ago
Exactly! Estimates are useful and volatility is real.

Falkon1313 4y ago

I'd say in my experience both deadlines and estimates are garbage 90% of the time. What really matters is prioritization. Are you focusing on the right things, the impactful things? Are you also prioritizing all the 'not-so-shiny' stuff (performance, security, etc.)? Do you have actual levels of priority (instead of just making everything top priority, which is no priority at all)? If you prioritize well, then you'll always be delivering the top priorities and some of the mid-level priorities. On a good week, you'll also knock out some of the low-priority stuff. And all of the concerns will be getting addressed. And everyone will be happy. The developers will feel good, management will be happy, and the customers will be pleased. Deadlines or estimations will be largely irrelevant. But if you prioritize sloppily, and constantly change priorities, so you're always yanking people out of the middle of one thing to work on another that is suddenly the highest high priority among all the other tasks all of which are high priority, then you'll always get less done. Some random assortment of stuff will get done, but it doesn't look important, at least not any more important than the stuff that didn't get done. No one will be happy. Some concerns will go entirely un-addressed. And no amount of deadlines or estimation will fix that. I'd much rather be working for a good prioritizer than the world's best psychic estimator and the world's best deadline forecaster anyday.

nivertech 4y ago
Prioritization Deadlines / Milestones Estimations Informal - no prioritization/deadlines/estimations
jseban 4y ago
I agree, deadlines and estimates are used to cover up for product actually not having a solid use case and design in the first place. Which is also not just blame the people that work as product managers, but also a critique of Agile swerving too far away from waterfall and now having no method whatsoever for requirement analysis and leaving a lot of really important work to fall through the cracks.
snidane 4y ago
What matters is prioritization and momentum. You're gonna get more people aligned if you focus on things that other teams happen to be working on at the same time. If you decide to work on something else when there is a huge infrastrucuture design project going on, just because of some precommitted sprint plan, you're gonna play catch up later. If you keep dropping a task for another because of arbitrary sprint plan, you're gonna be jerking yourself and the team around and never getting people get aligned with what you're building for long enough and it'll ge harder to get feedback from them. Momentum matters, especially for multi product teams, such as in data science and data engineering.

morsanu 4y ago

Arbitrary deadlines are only valuable as checkpoints to review work done and plan ahead. Using them as a timeframe to finish some tasks shows that you don't really understand estimates.

trhoad 4y ago

I think the term is "bottom-up", not "bottoms-up", which has a slightly different meaning...

20375587 4y ago

black_13 4y ago

senko 4y ago

Yeah, this doesn't sound like a modern approach to managing timelines. What's described here is "take the estimate and multiply it by some factor, adding a buffer, and then commit to it" approach, which is an ancient rule of thumb. As other commenters here pointed out, a more realistic approach is to either have a fixed deadline with flexible scope (time-based delivery) or fixed scope but flexible on when it's going to be finished (feature-based delivery). Problem with feature-based delivery is that nothing else can depend time-wise on it. If you have a big product launch and need to prepare marketing, buy ads, or execute on some contracts, "it'll be done when it's done" is not going to fly. This is an example of a real, hard deadline, that needs to be dealt with. The management problem I see in many organizations is managers conflating "estimates" (internally produced timelines that may or may not be achieved) with "deadlines" (externally produced constraints). These two are often handled in the same way. In a team where the managers/product owners/clients do understand and keep the difference in mind, engineers feel free to estimate without fear of putting a noose around their neck, and in turn understand that some things may be externally forced at a specific date.

c_o_n_v_e_x 4y ago

The issues with scheduling IMO highlight a deeper topic: culture. Specifically, are you product led or sales led company? Throughout my product career, arbitrary dates have come from sales committing to a random date to close a deal (which also leads to other problems when Sales starts acting as Product, coming up with new "features".)