How deadlines and date-setting can work in product development
Everyone involved in software development has probably at some point been confronted with a deadline they have to hit, especially in larger organisations. The common understanding that I’ve encountered among those involved in Product Management and software development is that deadlines are an inherently bad thing, and somewhat ‘un-Agile’. Perhaps that’s down to so many deadlines being missed. But they can work and be hit— as long as the approach is right.
The need for deadlines
Deadlines exist in most industries, at most levels. They set expectations, they inform planning, hiring, marketing, and a host of other activities. In larger businesses, they’ll often be communicated to the Board and to customers in order to excite or appease, depending on the product/feature being delivered. The world of business works on dates and deadlines.
It’s naive to assume they can or should be removed in software development, particularly in large organisations. And deadlines can be good for a product delivery team, providing focus and impetus.
The problem with deadlines in software development
“We have committed at Board level to deliver this product, with this set of features, by this date and we need you to build a Scrum team and make it happen” — this was said to me in one of my early Product Management roles, and in my naivety at the time I said ‘ok’. We had yet to build a team, we had no product designs or designers, and we had multiple third-party APIs yet to be analysed. This is the fundamental problem with deadlines as they happen in most large organisations. They are top-down, they are arbitrary, they are done blindly and very early, and it will be the delivery teams who face the backlash if they don’t hit them. These are the type of deadlines that are regularly missed.
Not only will these deadlines most likely be missed, they will result in other negative outcomes — development teams cutting corners, working overtime, stress, tension, and bad decisions. In Product Management, these are all big problems. Delivery teams lose engagement, the product and future roadmap suffers from the cut corners and bad decisions, and senior management end up wondering why the deadline is still missed or the product doesn’t achieve their expectations.
A good approach to setting deadlines, where great Product Managers can excel
Deadlines are crucial in the business world, so removing them completely isn’t an option. But the way they are set often has negative outcomes, including most obviously those deadlines being missed. The answer isn’t to avoid setting deadlines altogether, it’s to take a different approach — and this is a key task for Product Managers to facilitate. In my experience, the best approach (and one I encourage businesses to adopt) is to view date-setting and deadlines as a transaction between the business and the delivery team.
In this scenario, the role of the business is not to provide a date, but to provide the environment for a team to set its own dates and to hit them. The business gets the certainty and ability to plan that it needs, and the delivery team are not held to impossible deadlines. Negotiation is fine (it is a transaction after all, and collaboration is always good), but in the same way a delivery team would commit to an amount of work in a Scrum sprint, they should provide the deadline they are comfortable with for a product launch or feature release. These are deadlines that are much less often missed, with much more positive outcomes for all involved.
For the business to be part of the transaction, they must provide the right environment, which means accepting that the delivery team are best placed to estimate work, and crucially delivering information at the right time — if the business can’t provide the information a product delivery team needs to provide a robust estimate of the work, then it simply can’t demand dates and deadlines in return. These are fairly Agile principles, essentially using a ‘definition of ready’ at a higher level and the idea in Scrum that the team commits to deliver certain functionality in a certain amount of time, again simply at a higher level.
This is an extremely important concept for Product Managers, particularly in larger organisations where the adoption/understanding of Agile outside of the dev teams themselves varies from awful to mildly bad. Businesses understand transactional relationships and with education can come to appreciate that they are ultimately getting what they want, which is the ability to plan to dates. And Product and software development teams are no longer impacted by impossible delivery dates and the negative outcomes they bring.