Scope creep sinks many projects. And the best way to manage scope is to create basic rules about which features are going to receive top priority. With basic rules, you can hopefully get away from the traditional pitfalls of prioritization:
- The squeaky wheel – “But I really want it and I’m important!”
- The untested default – “I know what my customers want because it was in the legacy version.”
A while back, I was helping a client think through how to prioritize features for a new, complex, custom system. When I started listing the types of features that should go to the top of the queue, I figured I would end up with about three or four criteria that would fit that bill. But, I got stuck at two and I couldn’t think of any more.
Here’s what made the cut; top priority features must pass one of these rules:
- They create a compelling end-user experience
- They accelerate rapid experimentation and deployment of new features (DevOps-like stuff)
Now, there can be a lot of healthy argument about what qualifies a feature as fitting either of those rules (especially the first one), but it becomes very easy to see what DOESN’T make the cut: anything related to back-office (assuming they aren’t the end-user) or other supporting non-customer facing functions. And yes, I’ve heard the argument: “This feature will cost us less than we are paying Johnny to do that manually every month.” Fine, then let’s find another way to help Johnny. Create a macro for his spreadsheet. Build something that he runs locally. Just keep Johnny’s time-saving needs away from our new complex system.
Why prioritize the needs of a limited community (which in some cases is just Johnny, but even if we’re talking about twenty or hundreds of people) over thousands or millions of customers or prospects? True, making the lives of operations, finance, HR, etc. easier should and could have a trickle-down effect on your customers. But, helping those customers directly is always a clearer return on investment than helping them indirectly.
But, what about “mandatory” features? Doesn’t it have to work in all 50 states? What about regulatory requirements? Maybe, but challenge all of that. Everything is negotiable when you limit the scope of related functionality. Look at what Intuit did with SnapTax. Initially, it only worked with simple tax returns and only in California. You can bet that someone at Intuit was jumping up and down that it had to be multi-state and it had to handle more complex returns before it could be rolled out. And eventually, some of that functionality was rolled out. Prioritization is about WHEN more than about IF (with the caveat that the lower priority features might never make the cut). New ideas that have top priority attributes should always rise to the top.
Providing customers with newer, better, or additional functionality (and having the mechanism to get it to them quickly and to pivot based on experiments) is the lifeblood of companies and the driver of innovation. That’s the power of technology. A lot of other things are important too but nowhere near the top priority.
