Laurence’s List – Roadmap Features to Prioritize

Is the number of issues in your backlog into the triple digits?  Angry customers, bugs that have you tangled in spaghetti code, the talking head just changed the spec AGAIN!!!… and now the President comes to your desk and says payroll can’t be met unless feature X ships on Friday…

We’ve all been on chaotic software projects. Here is a formula to prevent it, or at least fight back. It is based on logic AND business experience, so you can’t lose:

First, make a roadmap so you can navigate:

A software roadmap is the equivalent of a business plan.  If you don’t have a roadmap, make one.  Professional ones look like typical spec docs or excel spreadsheets, but the most useful are drawings on paper like trees or ‘maps’ – cool concept.

To help guide planning, items on the roadmap should be grouped into the following categories. The higher on the list the more important it should be.  The priorities are based on customer satisfaction, which drives revenue, which drives platform upgrades, which drives more customers. It is a cycle.

Be careful if too much of your work falls below priority 8 on the list… if that is the case you are spiraling down, not up like you would like to be.

Typical sources of work on a software project, in order of priority:

1. Bugs – fix these first.

   1. This is not a new idea, in fact it is criteria #5 on Joel’s list from way back in the year 2000 when Napster was still alive:
      Do you fix bugs before writing new code? 

   2. It is easier to fix bugs if you have good logging and customer feedback mechanisms in place to catch them.

   3. Consider this a cultural issue and a technological issue.

   4. Leaving bugs out there is fine if you don’t care about your customers, or the system is so far gone some bugs will just never be fixed.

2. Items that directly relate to bringing in money.

   1. No revenue = no paycheck.

   2. Hopefully this is the bulk of what is being focused on.

   3. If your tasks don’t relate to bringing in money, see: the writing on the wall…

3. Items that improve the initial user experience, enhance the trial experience, or increase compatibility with other platforms / systems.

   1. If your system includes a trial period, make sure it is rock solid awesome.

   2. Features that increase compatibility with other systems makes it easier for users to switch to your software.

   3. For some businesses, #3 is really the same thing as #2 Items that directly relate to bringing in money, so these items should be pretty high on the list, especially for startups.

4. Infrastructure improvements – anything that will turn into a fire in a year or less if not addressed.

   1. Examples are scaling limitations, backups, security, dependencies on unmaintained packages (see software ghettos), database design that doesn’t cope well with upcoming requirements.

   2. Stay well ahead of these and your overall time fighting fires goes down considerably, perhaps close to zero which is as good as it gets.

   3. Every few months assumptions about the infrastructure should be checked.

5. Items that influencers would like to see in the product before they will endorse it.

   1. These are the golden nuggets to add to your road map as high priority items.

   2. Influencers are worth trying to please if they send users your way or help build features experts would want.

6. Features not in your system which are supported by the competition.

   1. This is part of the table stakes question – what is the minimum set of features required to be viable in the market?

7. Items that expand your feature list, but are more or less ‘buried’ features only a few of the highly devoted users will enjoy.

   1. By doing a few of these on a regular basis, the loyal fan base will be kept happy.

   2. The nice thing is you don’t have to do them right away. Do them when convenient.

8. Chasing fires rather than putting them out properly.

   1. In software, fires are the interest on technical debt.

   2. See #1 Fix Bugs First, as the solution to this one.

   3. Fires can get out of hand if left unmanaged. They are, unfortunately, a fact of software development.

   4. If this is most of your job, see: the writing on the wall…

9. One huge customer / stakeholder / investor has you on a short leash.

   1. If you let a 500 pound gorilla dictate what features get done next, you will probably be in trouble later.

   2. Being on a short leash generally involves customization for a particular use case.

   3. Stay focused on things that benefit your platform and the broader market while keeping the lights on.

   4. Don’t steal the profits from the big contract and call it a good business. Reinvest the profits into your platform so you can have many more customers down the road.

10. Reacting to loud customers.

    1. If the loudest users determine the schedule, you may end up building features that only 1% of the user base cares about.

    2. You could also end up changing things so they work in a different way, alienating the users who like it they way it is and are happily silent.

11. Engineering for the sake of it.

    1. Caution: The next monument to computer science is waiting to be born.

    2. If the engineers decide what to build, they will be having all the fun!

    3. Having fun is great, and should be practiced daily.

    4. However, too much fun of this nature almost always leads to something that doesn’t address a real market need. At best, it is using a sledgehammer to crack an egg *splat*.

What about relative effort / task size?

My thought process is to balance the big, medium, and small tasks. It is tempting for any business to continually delay the big items, because the small items are ‘cheap and easy’. Addressing the big items usually means shoring up the foundation, paying down technical debt, or building large new feature sets which can be risky. Consider where the system will be in 6 months if only the small items get done, and go from there.