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

31–40 of 45 posts

Re: How product teams should set deadlines

#31

Post by drawkbox »

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…

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.

Re: How product teams should set deadlines

#32

Post by jseban »

AdamN wrote: post #29
quanticle wrote: post #20

Earlier quoted context omitted.

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

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

Hehe the modern Agile software sweatshop.

Re: How product teams should set deadlines

#36

Post by snidane »

jseban wrote: post #32
AdamN wrote: post #29

Earlier quoted context omitted.

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

> 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. Hehe the modern Agile software sweatshop.

The modern Agile sweatshop is the one that manages by deadlines using timeboxed sprints. Not very agile by definition, yet the term stuck and people better find a new one.

Re: How product teams should set deadlines

#37

Post by snidane »

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…

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.

Re: How product teams should set deadlines

#38

Post by coldcode »

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…

At my last employer (very large, not FAANG) every project started with a deadline for when it had to be done, but few details on what was being asked for, followed by detailed estimates being required that were then only used for budgeting and not how hard it was to meet the deadline. Then inevitably all the details changed daily until the deadline was missed and recast again. Rinse, repeat, until eventually the project was canceled. All of this because the company had too many execs who wanted in on expensive projects, a product team with no ability to say no, and thus the development teams worked long hours to no avail. Shipping small incremental versions was considered anathema. So one could work on a project for 18 months and ship nothing only to start another project that also didn't ship.

Re: How product teams should set deadlines

#39

Post by jimnotgym »

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 problem with the adaptive model is in creating the culture inside the company to work with it. It might be easy if you are a software company, but for those of us where software is only a part of what the company does, it can be really difficult to get that mindset. Marketing want to know when the release is going to happen, the MD wants to get to market with this new thing that will do x for y (but won't really)....

I believe this is the main source of stress in my life! I have tried everything and I win a bit, some of the time. Despite all of this all I really gained was pushing the launch date back a bit. I have manouvered some other departments into the firing line so I don't get all of the flack. I have set the most demanding stakeholders up to argue their demands for new features in a way that makes them look bad for delaying the project. Sometimes I think we take a step towards an agile organisation, then other times we are back at square one

Re: How product teams should set deadlines

#40

Post by senko »

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.

Post reply on HN