Posted on | February 4, 2010 | 4 Comments
This post was written by Greg Cohen
If you map out the path your product takes from idea to launch, you will find many queues. There will be at least one for each stage your product must go through and there may even be holding queues where your product waits between stages. Most likely your product started its life an idea that had to wait to be evaluated. Once evaluated, it waited for approval. Once approved, discovery occurred and detailed requirements were researched and written. The requirements were then passed to engineering, where they waited for a review. Once the review was complete, the requirements were signed-off on and development started. Once the requirements were turned into working code, it moved to quality assurance (QA) and then to staging where it waited to be deployed. Once deployed it went through beta testing before finally reaching general availability.
Queues, especially long ones, are the enemy of responsive and flexible product development. In his excellent book The Principles of Product Development Flow, author Donald Reinerstsen demonstrates how queues hurt product development cycle time, quality, and efficiency. As cycle time expands, a company is at greater risk that customer preference will change or the product will be pre-empted by a competitor. Long queues also increase schedule variability (i.e. delays) and decreases our ability to cope with them because large backlogs create high resource utilization. Product team members cannot shift tasks without dropping another ball.
Even worse, long queues impede the feedback loop and results in lower quality. As work gets passed down the value chain (from product management to development to QA and to the customer,) queues delay valuable learning. Thus, developer feedback to product management, QA feedback to development, and ultimately market feedback to product management all arrive late. This not only delays our response, but even a small mistake in a product requirements document might get coded into the product in many places before being discovered months later. Significantly more rework, and additional delay, will be required than if the error had been caught and corrected quickly.
Lastly, as queues build-up, companies initiate multiple projects to move work in parallel. This exacerbates the problem, further increasing cycle times. The company thus ends up with many projects in all stages of development. As a result, a whole new layer of additional management is implemented for tracking, status reporting, and coordinating each project.
Product management must start minding the queue. We need to measure how long it takes for products, features and fixes to move from idea to deployed (and in the case of the whole product to market demand.) In my next post, I will speak about how to use batch size to help manage queues.