Managing your product backlog

[Mark Dalgarno]

I'm interested in how people record and prioritise those features of their product and service that are yet to be implemented.

What tools and techniques do people use?

What are the typical pitfalls?

How do people assess market value of new features?

How do people prioritise new customers over existing customers?

How do you reach a consensus on what to build next?

etc...

[allan kelly]

Tools: Excel for everything - with a bunch of word files.
Index cards for the more near term stuff.

Techniques: lay the cards on a table then order them; have everyone who wants a say in the room
Of course its far better if your Product Manager has the legitimacy to just do this ordering themselves.

Pitfalls: 1) No doing it, 2) leaving ambiguity in the ordering. e.g. Asking engineering to deliver 5 must have features. That is an abdication of responsibility, you are asking engineering to order them as they like.

Market value: Umm, nice idea :)
Of course I want to do this, of course I've tried to calculate some stuff but usually I find it comes down to who shouts loudest or who out ranks others.

New over existing: Again its usually all in the discussion

Consensus: Something to aim for.

Absolute prioritisation helps because people get to see the consequences of their decision. We did this at a company in South London with a senior management team in New Jersey. Each time the guys in New Jersey would prioritise stuff which US customers wanted even if the customers were small or only prospects in the pipeline. The the UK staff would say: fine, as long as you realise that this stuff for our bigger, existing European customers is now lower priority. After a few times they got the message.

[Daniel Kuperman]

Excel is king.

I initially had all the features listed down a column and each of them were ranked based on different impact criteria such as:

- competitive advantage (no competitor has this feature)
- competitive requirement (all competitors have this feature)
- customer request (people are asking for this)
- product stability (will reduce crashes)
- product performance (will make it faster)

Each 'impact' was ranked 0 (no impact) through 3 (high impact). Features were scored and the scores were normalized. Highest normalized scores means higher priority for development.

We then plotted the releases and features on a table with dates so we could track progress. I can send you the excel template I created if you'd like.

This model didn't go far, though. I had sales, marketing, development, and professional services helping rank each feature but they didn't want to spend time doing that and so we went back to a simple ranking of "high", "medium", "low". We discuss each feature, each dept gives their rationale for ranking a feature "high" and we come to an agreement. Not very scientific but works for us and is quicker. Since we are getting input from multiple departments who have different views on customer and market needs we end up with some good input for discussion.

[Mark Dalgarno]

Thanks Daniel, some follow-up questions.

Is everyone on a single site? I ask because at my previous company we had people feeding in feature requests from around the world and different country managers had their own priorities. It wasn't feasible to bring everyone together regularly to discuss things in depth.

How frequently did you release your product? Did these discussions happen on an on-going basis or at set times during release planning?

Did you have some features that were less well-defined and others better-defined?

[Daniel Kuperman]

Hi Mark,

We're all spread out. I'm in Tampa, FL, the VP of Development (and his team) are in Boston, MA, the Director of Sales is in Oklahoma.... so we use Video Conferencing regularly. Product Management meetings happen over VC so that we can all see each other and save on travel.

We have three products, each with 2 releases per year and we created what we called a "rolling 6 months plan", meaning that the next six months are very well defined and the following 6 months are less detailed (priorities change all the time). In our 'product roadmap' we break down our features/releases with labels such as "Commitment" (detailed plans that will not change), "Intent" (what we hope to accomplish but may change), and "Future" (looks like will happen but is likely to change).

So to answer the question about features being defined, the answer is it depends. For the very next release the features were very well defined. The ones for the release after that were not as well defined.

During development is also routine for priorities to change, no surprise there. A customer or multiple customers come to us requesting something or a major change is required due to a bug discovered. All these things impact the plans. What we do is get the team together and we all agree if there will be a change in the roadmap. We assess whether the change will impact the schedule and the cost and make the decision.

I keep a chart with documented changes throughout the development cycle and the CEO likes to show it at every meeting when development talks about changes in the roadmap. This helps us keep things in perspective and instead of always shifting dates to try and hit the goal we set forth originally.