Managing Product Development
Delayed releases are typically the result of "just one more thing" requests. Every time we add another requirement to a release, we delay the date. Some vendors find themselves in the position of distributing patches that are really undocumented and untested features, because a big customer or a sales person squawked. And some companies do this for months and months until someone finally shouts, "Enough!" Long release cycles are extremely de-motivating. Developers and product managers lose heart that the project will ever end. Sales and marketing want to talk about the exciting features in the next release. Customers are continually told to wait for a fix or a feature that should be shipping "any day now." One technique is to break a big release into smaller ones. Johanna Rothman writes, "One of my clients complained about ranking, 'We'll have hundreds of requirements. It's overwhelming.' If you're still doing big releases, ranking requirements helps you create smaller releases. (Take the first 10 requirements and make that a smaller release. You don't have to release to the external world, you can release to the test group.)"
We advocate this approach in Requirements That Work--build small releases focused on a specific persona or market segment, which may or may not actually ship to existing customers. But if a new or existing customer needs a key feature, we can deliver the latest release, assured that it's been tested and is ready to go. If your company has a "big" project, break it down into a series of small release candidates. These release candidates allow you to balance project time and feature set. And this approach allows the team to feel a sense of accomplishment, take a deep breath, and then start it up again renewed.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.