Home > Blogs > What to do?

Once in a great while, I find myself in a position where I wonder what to do next. This is rare, of course, as usually there are more than enough things to keep me occupied. With technology companies, it is almost always the case that there is way too much to do, and even worse, it is almost always someone else that seems to be calling the shots. From what I have seen, there is a better way.

I had lunch with a couple of people driving the technology side of a successful business a few days ago, and it was a familiar story. They had challenges getting everything done that they were being asked to do, but it wasn’t simply a function of their skills or capacity. The marketing team had a real propensity for suggesting that everything was a top priority, that it didn’t matter what else might be needed. Priorities seemed to shuffle all the time, there had been a number of urgent things that just had to be done that turned out not so urgent after all, and through all of this, the perception was that the development team couldn’t do their job. In my experience, this is more the norm than the exception.

What is needed in a situation like this is recognition that the effort and risk associated with adding a feature to the system is just as real and important as the relative value of having this feature available. Two very different, real and important perspectives that must be balanced together to allow the business to move ahead with the best combination of value for effort. If you let the marketing side call the shots you are likely to build very expensive features when simpler ones will do, or take on too much risk when you don’t need to. Let the tech side call the shots, and you might get easy-to-build features or cool technology, but will likely miss the value expectations.

A simple spreadsheet is the weapon of choice for managing this duel, and it is easy to implement and maintain (the original idea comes from Karl Wiegers, the essence of it is explained here). Start off by listing all of the things that are discretionary, but someone wants in the system. Remember, just because someone says they want it, does not make it a mandatory feature – the list of mandatory features is likely a lot shorter than you think, and unless it is something driven by a business rule such as external legislation, I would tend to put it in the discretionary list to start. Don’t get caught in the trap of wanting everything your competitor has, or you will never get a chance to build something unique. All the potential features, major architectural elements, anything else that might fit at that magnitude, whether it is requested by a user proxy or by an internal stakeholder such as an architect.

You will find there is a reasonable level to balance this list. At too high a level, you will miss out on some opportunities to partially implement major features, so your flexibility diminishes. At too low a level, you will have an administration nightmare on your hands, and you also run the risk that you could prioritize out something that is needed by a feature that you want to build. I find that if you work around the level of use cases or scenarios within these use cases, you will do well.

Take this list, and let each side fill in their own scores for the features. Each one is scored on a 1-9 relative scale, there’s no need to be too precise (don’t mess with larger or smaller numbers, fractional numbers or anything like that). One of the things I particularly like about this system is that if one side tries to game the numbers by ranking all of the features very high or very low, they essentially lose their voice in the overall results. Nothing like a game where the rules force you to play fairly.

The customer representative rates each feature on two dimensions: the relative benefit of the feature being included in the system, and the relative penalty if the feature is not implemented. A feature will have a high relative benefit if it is seen as a differentiating feature (if you ask Tiger Woods or Kelly Ripa, OnStar automotive navigation systems would fall into this category), and would have a high penalty if the feature is expected in that class of products (for those same cars, cup holders or a good sound system or tinted glass would be expected). Interestingly, something that starts out having a high benefit in a class of products will eventually migrate to having a high penalty if absent over time, as the competition all picks up on the good features – just try to buy a new car without onboard navigation in ten years.

The technology team team then ranks the same features from their perspective: the relative cost of implementing the feature, and the relative risk involved in doing so. While the cost appears straightforward, be careful to consider the full lifecycle costs for implementing the feature, rather than just the code and test effort. For the risk, this can include the uncertainty in the cost (remember that no estimate should be a single-point number), and the risk to the architecture caused by injecting this feature at this time. A big feature, added to the system late in the game, can be a significant risk. This is just one example of how any of these numbers can evolve over time.

With all the numbers input, let the spreadsheet to what it does best. Sum the benefit and penalty for each feature, divide by the sum of the cost and risk. Sort the spreadsheet by this resulting column, and you have converted different perspectives into important information. Near the top of the list (sorting highest to lowest) will be a collection of features with an attractive balance of high value and low cost: where you want to be with your work. Near the bottom will be those things you want to stay away from: costly or risky items that don’t add a lot of value. In the middle will be those features where it is appropriate to have the rich discussions and debate.

I’ve seen clients take this basic form and extend it in many directions. Once you are comfortable with the basics, you may want to weigh one or more of the columns differently (you may want to bias the list to be more strongly differentiating, or less sensitive to risk, for example). One team added columns with absolute costs and uncertainties, so the spreadsheet could give them their first cut at effort automatically. Another team found they had a couple of major clients that drove their prioritization, so they augmented the basic formula to include weightings for these clients. Whatever you do, make the adjustments and agree to them in advance. Debate the model first to remove the politics, then deal with the results afterwards.

This list can be large, but that is ok. Once past the initial hurdle of populating the list the first time, things get a lot easier. This is something best considered as an ongoing management tool rather than a one-shot exercise, so plan to keep it around. Indeed, this prioritization list serves as a great backdrop for ongoing change management, and has been used as a more refined backlog for teams using a scrum-like approach for developing their products.

The spreadsheet shouldn’t be considered an absolute arbiter, but it certainly helps balance and focus discussion. It takes away prioritization based on personal perspectives or organizational power, and helps you decide what to do to get the most bang for your buck. If you think about it, that’s really what everyone involved wants in the first place.