Product Idea Triage

When I was training to become a fire fighter in my younger days, we also had training in wartime disaster relief. This is where you learn how to set up emergency hospitals in tents and rescue injured people from collapsed and collapsing buildings while everything is on fire around you in the middle of a firestorm. Good stuff to know.

But one of the more relevant and well known techniques we learned, once you actually locate and rescue someone is triage. In general triage is a way of sorting people into groups of priority, that is, who needs most immediate medical attention. There are several different schemes practiced around the world, but we learned to use three different groups:

A) Those that were not critically injured and who needed medical attention at some point, but could wait

B) Those that were seriously injured, but were able to survive if they were given immediate medical attention

C) Those that were mortally wounded and who, given the circumstances, would not be able to be saved

This is a tough decision to make, but we were training for wartime or serious catastrophes (I have actually tried triage myself at an American hospital. That was a very pleasant experience, because I got put into the B category apparently and skipped the long line in the emergency room. My serious, though not yet mortal wound, was being bit in the nose by a dog. Yes I know, I should have known better since I have also trained sheep dogs, but I feel we are drifting a bit off topic here…

I often encounter the gordian knot of prioritisation in software companies: it is impossible to find out which ideas to build first. That leads to prioritisation paralysis. There are too many ideas to work on and you don’t know for sure which ones will be of most value. You need to specify in more detail the idea before you can ask your engineers to build it. It may be necessary to do a mock up or describe some business rules. It could be that it is necessary to do graphical design. You can immediately see that some ideas are more well shaped and don’t need so much work, while others are just too complicated. Some ideas are urgent and need to be built immediately. They could be bugs, while others can easily wait. How do you get started? You probably don’t just start from idea number one.

In this case you can use the same triage technique as I mentioned above. You just have to tweak the meaning of the triage categories a bit:

A) ideas that have some potential but are in no particular rush to be made. They may need a bit of polishing and precision, but there is no need for immediate action. Ideas in category “A” can just be queued for when you have a moment to work on them. They could be customer requests, infrastructure features, annoying but non critical bugs etc. These should be treated as buffer tasks that can be picked by engineers when they are idle.

B) Ideas that have some potential, need to be made immediately. Ideas in category “B” are critical bugs, responses to competitors, or any other thing that has a large time to market constraint. They should be put into the most immediate sprints or releases. If needed other ideas should be taken out of the Work In Progress and parked.

C) Ideas that have very limited potential of immediately becoming fruitful. Category “C” ideas are those that are typically too complex to build quickly. It will take a long time to conceive, design and build them. However there may lie a huge potential here. The trick is therefore to selectively choose some that have a huge potential benefit. They could be big bets or the like. Find a percentage of work effort that can be dedicated to following unlikely successes, so you don´t miss out on great opportunities.

Ideally every idea should be scored according to the strategic parameters of the company, but I realise that this is often not feasible. Either because it is too cumbersome or because there are simply too many ideas. This is why we suggest this faster, but more crude feature triage. The product manager can either do it himself or together with the engineering team. It is a good idea to have both market knowledge and technical knowledge present since you will have to gauge the feasibility and market urgency of the idea.

One way is to get three signs (for example blue, white and cyan. For each idea, each participant holds up the triage sign he or she thinks it belongs to. In case all signs are the same color this feature is simply given this triage category. In case of disagreements the reasons for this disagreement should be discussed. If after 5 minutes the disagreement has not been settled you go to a vote. It is important to have an unequal number of participants. If this is not possible and the votes are equally distributed the triage is decided with a coinflip.

This way you will quickly have escaped prioritisation paralysis and be ready to do some actual and sensible work.