Add “Quick Hits” and (Finally) Address Those Priority 3 Enhancements

By Chloe Morrow November 06, 2007

Woe to the minor enhancement request that gets tagged as a dreaded Priority 3 or nice-to-have feature during the prioritization phase of a project. All too often, it will get pushed into a future-release black hole—never to be seen again. These are not features that will win the big deal, leapfrog the competition, or get a sexy write-up in the product brochure. These are little tweaks your current customers would really like to have—and they can make the difference between a product that is good and a product that is great.

One of the challenges with minor enhancement requests is that they are minor; even your customers would agree their priority isn’t as high as other, more important features. Accumulate enough of them, however, and you start to feel the impact—with a product that has usability issues and lacks polish. Companies will often wait to compile enough minor enhancements to create a single release. But if you wait too long, your customers’ reaction might be “What took you so long?” rather than “Wow, great feature.”

When I worked for a former employer, we struggled to find a way to address at least some small enhancement requests in each release—without cutting bigger, higher priority features. We developed an idea called “Quick Hits.” For each release, we completed our standard process to define, refine, and negotiate the scope and timeline of the release with Development. Next, the product managers identified a pool of possible Quick Hit features to add. In our “contract” with Development, we agreed that these were features to be implemented at their discretion, as time permitted. Development wouldn’t implement the features if it might affect the overall project schedule—and the product manager would accept the possibility that none of them might be implemented. We considered any Quick Hits that were implemented as  bonus features.

I know what you’re thinking: Your projects are often late and features always end up getting cut…how could there possibly be room for bonus features to be implemented? The reality is, unless you have the most efficient development team ever, there are pockets of time to be found in almost every project. There might be a small, two-day gap between the completion of one major feature and the start of another. Or you might find a bit of down time while a developer is waiting for another team member to finish something. These pockets of time are unpredictable, and probably not large enough for any major features to be implemented. But, if the developer has a list of Quick Hit features at the ready, they just might get one or two of them implemented.
Implementing any new process or strategy will only work if you have buy-in at the start from those involved. So sit down with the right people in your organization, talk about the challenges around your growing pool of nice-to-have features, and see if implementing a Quick Hit idea in your next project will work.

There are huge rewards to be gained when you include a handful of nice-to-have features in each release. Your current customers will see you as being responsive to their needs, your new customers will benefit from a product that has been fine-tuned using feedback from other customers, and you will make a dent in that future-release checklist!   

Quick Hit Checklist

This handy checklist helps you choose the Quick Hit features that will make this technique successful. Be sure to involve your development team in defining the appropriate criteria for your organization.

  1. Quick implementation time. Quick Hit features should be small and able to be implemented rapidly. In our case, we set the bar at features requiring less than two days’ effort. More often, they were features requiring two to four hours. If the product management team at your organization is not able to accurately select features that are quick to implement, consider involving your developers in the evaluation process.
  2. Light requirements effort. To give your development team maximum flexibility, provide a long list of possible Quick Hits. Only a fraction may be implemented, so you don’t want to waste time writing long requirements documents for features that will never be implemented. Ideally, these are features you can describe in a couple of sentences or for which you can quickly write details if a developer finds extra time.
  3. Low impact on the rest of your development organization. Since you don’t know whether or not these features will be implemented, ensure that other teams (such as QA or documentation) won’t be forced to scramble if something doesn’t get done.
  4. Related to code being changed anyway. Ideally, your Quick Hit features should be related to aspects of your product on which you are currently working. If the developer already has the code for module X checked out and is making changes related to one of your major project features, it may be a perfect chance to make a small change to address one of your Quick Hit features as well. This will also help your QA team, since (presumably) this was a product area they would already be testing.
  5. Have enough on your list, but not too many. In addition to picking the right features, ensure you have the right quantity of Quick Hit features identified. You don’t want to select so many that the list is overwhelming, but you do want to ensure you have enough so your developer or project manager has flexibility in choosing a feature based on the amount of time available and within the application area where they are already working. Also be sure you have a selection of Quick Hits for each developer or development team.
  6. It’s not a must-have feature. The last, but most important, element in deciding whether a feature is a good Quick Hit is whether you, as the product manager, can live without it. Remember, these are features that wouldn’t otherwise have made the cut for the release. If your feature is a must have for the release, no matter how small, it needs to be scheduled into your standard release process.
Categories: Agile Requirements Working with Development
Chloe Morrow

Chloe Morrow

Chloe Morrow has over 10 years experience in software organizations, leading both product management and development teams. She is currently the VP of Operations at IDELIX Software where she helped the company to redefine its strategic direction and brought a new product to market. Prior to that she was a Senior Product Director at WebCT, leading their product management team through four major product releases and helping the organization strengthen its position as a market leader in the e-learning space. You can reach Chloe at chloe.morrow@gmail.com.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.