Multistage buffering

Consider a scenario from a major release of an annually updated product. The initial launch timeline is set at the end of May. Project managers establish a sequential process across multiple stages – early testing, QA, security, compatibility, marketing, etc. Each stage has dedicated stakeholders requiring their own approvals, and naturally, each one asks for additional buffer time for thorough checks. This seems reasonable at first. Consequently, deadlines are staggered backwards: marketing in April, compatibility in March, security in February, QA in January, and early testing initially planned for December, which inevitably slips into early November due to the holiday break.

The product is slated for release in late May, yet the engineering team is directed to finalize everything by the previous October – effectively condensing what should be a year’s worth of development into less than four months, following the first month spent on strategy and user experience research. This leaves the team with an unrealistic timeline to outpace the competition. Good luck indeed!

While each team optimizes in good faith for their specific deliverables, this approach often culminates in a product that, despite being well-tested, secure, and backward-compatible with excellent marketing, ends up being merely mediocre.

The antidote? Rethink your release cycle. Aim for going live weekly or daily, not annually. This isn't the era of '90s Microsoft. After automating and streamlining your release processes, then focus on rapidly incorporating user feedback.