The UX of Product Priorities

By | September 4, 2009

How do you decide what to build next?  Let’s start with some high level categories:

  1. New Whiz Bang Features.  Sales is going to love demo’ing.  Marketing is going to love the story-telling.
  2. Polish the Apple.  This is going back over existing features and making them better.  More polished, more nuanced.  Sales and Marketing won’t care, but the customer will be happy with progress and improvement.
  3. Systems Infrastructure.  Sometimes this is as simple as upgrading your version of Apache or PHP.  These aren’t sexy or feature rich, but they are the foundation of your whole product.  Ignore at your peril.
  4. Refactor Code.  This is similar to infrastructure except it’s upgrading code instead of systems.  Taking a piece of working code and making it better will improve maintenance and have other fringe benefits.
  5. Internal Systems.  Logging, reporting, control panels, etc.  The support team needs to be able to gain insight into issues before involving an engineer to grep the logs.  These kinds of systems pay high dividends in support costs.
  6. Demo Systems.  Your sales and training staff need systems with “dummy data” that can do whatever the system does without actually doing anything.  This kind of work is inevitable, but it’s hard to prioritize.

This is a fairly long list of potentially gigantic initiatives for your product.  What strategies should you use to decide?  Here are some options:

  1. Dictatorship.  One person, Product Manager, CEO, whomever, decides and picks the priorities.  It’s fast decision making, but not very collaborative.
  2. Six-Sigma.  Gather a committee of people and put so much bureaucracy around it that decisions get made in slow motion.  (I’m not a big fan)
  3. Reactionary.  Wait until a problem is literally so big it threatens the enterprise and then over-react and create a Manhattan Project around it.  Usually mobilizes alot of people, but would be cheaper if you planned a little more in advance.
  4. The balanced approach.  Take a little of each and sprinkle it into the release.  Everything makes progress slowly, but lacks focus and spreads resources thin.
  5. Merry-Go-Round. Focus on one category per release.  I’ve never seen this in action.  I wonder if it works.
  6. Focus on 2 through 5 for as long as possible.  This is avoiding feature creep.  Lots of applications do one thing extremely well.  This is a decent recipe for success.  However, in a highly competitive market, you need to be careful of being pigeon-holed as “not innovative”.

6 and 6, seems like a good place to stop.

At first, maybe I thought this would end with a “I suggest you….” but I think that would be a mistake.  Sometimes, just listing out the possibilities is a good thing.  Listing out the categories helps you think about the choices more clearly.

Clarity comes from reducing complexity.

The reality of most organizations is that decisions like this are made through a very human process that includes our very real human foibles.  Not liking someone will make you dislike their ideas too.  Regardless of their merit.  None of this exercise will solve that problem.

The real question is: How can we make decisions more based on merit and less based on personalities?

Leave a Reply