, , , , , , , , ,

Without exception, all of us at times have succumbed to the weight of the day to day needs to the extent that we lose sight of the big picture. Nowhere can this be better illustrated than with the relationships in our lives. After a full day of work, there are errands to run, practices to get the kids to, appointments to keep, a workout to squeeze in, or chores around the house which need attention.

Those are just a few examples, I’m sure you have many more to offer.  But to borrow a quote, the reality is that the number of demands will always outnumber the supply of your time. And so using hindsight as a gauge, you will find that we inevitably choose to spend our time on what we define as being most important.

But when a relationship begins to suffer, or perhaps a loved one is diagnosed with a terminal illness, we are reminded that what we thought was most important, perhaps really isn’t.  We are forced to look at reality through a fresh lens, we are forced to reconsider what really is (or is not) important.  We are forced to re-evaluate what’s next.

This is called gaining perspective, and just as with the life example provided above, our ability to gain perspective and understand the bigger picture is essential in our roles as product management leaders.

In my last post (Facing the Mountains), I asked the question about how to approach situations where feature enhancements are stacking up, but capacity constraints prevent everything from getting done. The answer relies on prioritization.

My approach has always been to make the process as objective as possible, and a methodology I stumbled on in my early days as a product manager was something called QFD (Quality Functional Deployment). It is a team-based technique used for structured product planning and development, and enables the ability to clearly specify business or company needs and wants, and then systematically evaluate the needs in terms of the impact within the overall product design. The model focuses on:

  • the why – identifies the market and/or customer drivers, as well as your company drivers. Generally the why is answered with categories such as ‘to increase revenue’, or ‘to cut costs’, or to ‘improve inefficiencies’.
  • the how – how do categories relate to each other? For each category of why, how much weight should be designated to determine the relative importance of the category? For example, in a start-up driving revenue might be ranked highest .. but in a stable business customer satisfaction might take precedent.
  • the what – a list of needs that have been identified and qualified as valid enhancements. These can come from various sources including customers, partners, RF(x)s, market research, internal suggestions, and more.
  • the inter-relationships (scoring) – how do enhancements relate to each other. Each enhancement is scored by category based upon its importance within the category. They can be ranked from strong positive impacts to strong negative impacts (although negative impacts are generally more internally focused – like adversely impacting performance or scalability as 1 example).
  • the ranking (total score) – scoring each enhancement within each associated category, with an appropriate weighting applied should yield an objective measure.

Of course, because of other external factors, there will always be some level of subjectivity that needs to be applied. For example, your development team only has a finite capacity for any particular development cycle. Features A, B, and C are somewhat large features and will consume all of the resources. Whereas Features D, G, and I are low hanging fruit from a level of effort perspective and would generate positive buzz in the marketplace. So perhaps substituting D, G, and I for Feature C might make sense.

Other external factors might include an override because of a pet project from executive management (I know … this never happens, right), a necessary immediate reaction to a competitor, or perhaps an acquisition that suddenly changes the landscape. I’m sure there are others as well.

And so, just like with many thing in the wonderful world of product management, the answer is part science, part art, and a lot of patience.