Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How product teams should set deadlines

dana11235.medium.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: How product teams should set deadlines

#11

Post by donatj »

cjonas wrote: post #6
donatj wrote: post #2

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 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…

> 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.

Re: How product teams should set deadlines

#12

Post by metadat »

kadoban wrote: post #9
metadat wrote: post #8

Earlier quoted context omitted.

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.

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 :)

Re: How product teams should set deadlines

#13

Post by klenwell »

jdlshore wrote: post #7

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 pi…

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

I wish I could get every project manager I work with to read this. (I've tried.)

Re: How product teams should set deadlines

#14

Post by presentation »

jdlshore wrote: post #7

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 pi…

While I prefer working that way, I personally know for myself that when a deadline is coming I get more done closer to the deadline. I don’t think it’s one or the other, but a mix of both.

Re: How product teams should set deadlines

#15

Post by marsven_422 »

jdlshore wrote: post #7

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 pi…

No post body was provided.

Re: How product teams should set deadlines

#16

Post by a_c »

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

Re: How product teams should set deadlines

#18

Post by jseban »

jdlshore wrote: post #7

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 pi…

Great way to deliver cake! I wonder if you can slice software in the same way though..

Re: How product teams should set deadlines

#19

Post by jseban »

cjonas wrote: post #6
donatj wrote: post #2

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 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…

> 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.

Re: How product teams should set deadlines

#20

Post by quanticle »

jdlshore wrote: post #7

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 pi…

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.

I used to wholeheartedly agree with this view, but I've moderated my position considerably. What I've found is that, in practice, this encourages a mindset where a team (or even an entire company) delivers a lot of "half-assed" products or features. They make a minimally viable thing, ship it, and then move on to the next thing. They never come back to actually complete all the fit and finish work.

A great example of this is the "Familiar Faces" feature of Nest security cameras. Nest security cameras have a feature where you can train them to recognize people in your household. Then, when they alert, instead of sending a generic alert, they tell you which person was seen. This is great, but Nest never actually finished the feature. There is no setting which tells the camera to only notify when there's an unfamiliar face. You can get no notifications at all. Or you can get a notification every time the camera notices activity. But there's no way to tell the camera, "Hey, let me know if you see a stranger," despite the camera having the ability to distinguish strangers from friends and family.

Alphabet products, in general, suffer from this mindset. Another example is the new Suggested Audio feature of Android Auto [1]. I can tap on the icon and it'll bring up a random selection of podcasts from my (now defunct) Google Podcasts subscriptions. Is there any way to customize which podcasts appear? No. Is there any way to make the icon go away, because I use a different podcast app? No. It's just there, waiting for my finger to accidentally brush against it as I try to fast forward in PocketCasts. They made a minimally viable thing, shipped it, and moved on.

I contrast this with Apple, or even Microsoft, where there seems to be a lot more focus on having products that are at least somewhat thought out from the perspective of the user, and not shipping until there is certain level of coherence. Alphabet, on the other hand, ships features as soon as they're ready, but doesn't seem to realize that on buttons are useless without their corresponding off buttons.

[1]: https://www.androidpolice.com/2021/08/12/android-auto-starts...

Post reply on HN