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

21–30 of 45 posts

Re: How product teams should set deadlines

#21

Post by gherkinnn »

jseban wrote: post #18
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..

You don’t slice software. You layer it.

Re: How product teams should set deadlines

#22

Post by meerita »

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

Re: How product teams should set deadlines

#23

Post by Falkon1313 »

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.

Re: How product teams should set deadlines

#25

Post by pjc50 »

jseban wrote: post #18
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..

Ironically you can't agile a cake, because the whole thing has to go in the oven at once for a defined time period.

Or maybe you could; if management can't or won't specify the cake in advance, say whether it should be round or square until ten minutes before the deadline, you could just bake a pile of cupcakes and squash them into the tin.

Re: How product teams should set deadlines

#26

Post by nivertech »

Falkon1313 wrote: post #23

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…

  Prioritization
     Deadlines / Milestones
        Estimations
           Informal - no prioritization/deadlines/estimations

Re: How product teams should set deadlines

#27

Post by jordanbeiber »

donatj wrote: post #11
cjonas wrote: post #6

Earlier quoted context omitted.

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…

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

Re: How product teams should set deadlines

#29

Post by AdamN »

quanticle wrote: post #20
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 agr…

Half-assed happens in both scenarios. If you have something shippable by the pre-ordained date or shortly thereafter, it ships. Whether you use an adaptive or predictive approach, the outcome is the same that further improvements may or may not happen.

The advantage of the predictive approach is better driving of your workers with a deadline. The disadvantage is low morale over time and lower quality products under the hood. Rotating workers who come in fresh can mitigate this outcome but at a cost.

Re: How product teams should set deadlines

#30

Post by jseban »

Falkon1313 wrote: post #23

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…

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.

Post reply on HN