How product teams should set deadlines
dana11235.medium.com
How product teams should set deadlines
1–10 of 45 posts
Re: How product teams should set deadlines
#2We 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.
Re: How product teams should set deadlines
#3"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.
Re: How product teams should set deadlines
#4"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.
> 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?
Re: How product teams should set deadlines
#5We 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 overal…
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.
Re: How product teams should set deadlines
#6We 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 overal…
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.
Re: How product teams should set deadlines
#7The 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.
Re: How product teams should set deadlines
#8"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.
> 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?
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.
Re: How product teams should set deadlines
#9Earlier quoted context omitted.
> 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?
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.
> 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.
Re: How product teams should set deadlines
#10The 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.