UX Roadblock #48: Sexy Requirements

There are a thousand different ways to manage requirements and plan a release. One of the all too common methods is to make a list of the biggest, most important requirements and rank them from top to bottom based on "customer need". Of course, "customer need" can mean anything from "an executive already promised this to a customer" to "marketing thinks this feature will enable us to get into a new market". If you've been on a team that used this method, you know what happens... people learn that the best way to get your favorite requirement into the product is to make it as big and sexy as possible. Because once you have the ranked list, sizings are done and once the resources run out you've got your list of in-plan requirements. If your requirement isn't near the top, now matter how easy it is to do or how great the ROI is, it won't make it in.

This is a bad method for lots of reasons, but it particularly hurts the user experience. First, the overall user experience is made up of a ton of small interactions, and often the best way to make improvements is to fix a lot of small issues rather than add some groovy new "user experience feature" while leaving the small issues alone. Those small issues add up quickly. But comparing any of the small fixes to one of the big sexy requirements makes the small fix look optional.

Second, this type of process encourages a "feature-centric" view of release planning. The discussion naturally becomes focused on which of two features is the most important... and tends to avoid the discussion of whether either feature is the best way to spend those resources. Making the existing features better gets lost in the mix.

If you are stuck in this situation, you might not have the ability to force a wholesale change to the process (which is what is ultimately needed). If that's the case, here's some pragmatic advice on how to get around this particular roadblock (based on my own experiences):

1. Create a big sexy requirement that is a collection of UX improvements and try to tie the individual improvements into a single theme that will sound good to release management, like "Decrease customer time-to-value through out-of-box-experience improvements". Of course, you'll know that this is really just a bunch of little improvements, but by combining them together by theme you'll be able to better compete against the new feature requirements.
   
2. Work with release management (and product management) to create "buckets" of resources that are dedicated to particular release objectives, then prioritize within the buckets. And, of course, make sure one of the buckets is dedicated to user experience. This is easier than it sounds because (almost) no one thinks user experience is unimportant, and at a theoretical level it's easy to convince folks that some percentage of effort in a release should go towards improving the user experience... the problems arrive when those well-meaning people are forced to choose between a new feature that some customers genuinely want and improving the user experience. By creating separate buckets, it removes that forced choice.
   
3. Partner with the folks who are working on one of the big sexy new features that is likely to make it into plan and persuade them that there are a number of user experience improvements that ought to be tied to the requirement. One reason this technique can be so successful is that adding user experience items to the new feature can make it even more sexy, so the people pushing the new feature are motivated to work with you. The downside to this is that unlike the first two techniques, tying the UX improvements to a new feature constrains your choice of which UX improvements to tackle. You have to pick things that relate to the new feature, however loosely. Of course, if your choice is between getting nothing done versus getting your second or third choice done, it's still an easy decision.

None of these actually removes the roadblock, they just help you get around it.