Feature Prioritization & Product Road Mapping (Part 2)

So what did we get from Part 1?


Part 2: Feature-Value Matrix - Desired vs Actual Results

Desired Plot

Nice, easy sweet spot of features to implement

Actual Plot

Many features score similarly
FVM - Desired

Results of the plot were more complex than originally anticipated:


Group your features

Of course, you've played with the figures to death. Now you should try and group some of the features together. You're looking to find a 'sweet spot' of similarly-themed features - these will tend to have similar Attribute scores. Move them next to each other on the Excel sheet.

Overall, you can categorize these clusters as lemons, mediocre, pretty good and hot.


Side Note: Build vs Buy

Nearly always, a company has the opportunity to purchase some of its desired features from other sources. The build vs buy decision is not one I'm going to cover, but the significant point is that it will modify the resource requirement (if you consider the resources to be measured in time).

I specifically chose time because it is a commodity that definitely cannot be regained. Yes, money (particularly in start-ups) is in short supply, but with clever and persuasive management, it can (hopefully) be refreshed. Indeed, your product road-map is an extremely important part of your fund raising / return on investment proposition. More on this in Part 3.

Shifting to a buy decision will place a greater burden at the outset of the process (during the research for partners and specification stage). Of course, in the mid- to long-term, it should reduce the overall resource effort, but if the buy / outsource decision proves to be disastrous, this resource figure might balloon in the later stages, never mind the technical or delivery consequences.

If you have none or limited skills in one area, then outsourcing is the practical answer, but do you have enough skills to even outsource this? Difficult to answer, particularly if what you're trying to do is close to the bleeding edge. You may well find yourself educating your partners on your dollars.

 

Think Strategy & Tactics

So, once the build vs buy decisions have been made, then we just pick the top features and work our way through them, right?

Well no, some projects should be rejected:

Too risky

Some projects may just be too risky to contemplate undertaking for the required effort:

  • Best to kick out a quick and dirty prototype and validate it (or not) with focus groups - remembering of course that it is only prototype and not releasable feature at this stage!
Too long

Some projects are too long to fit into your release cycle.

For example, if you usually release a new version every 8 weeks and if a feature take 5 weeks, then this feature is pretty risky to squeeze it into a release (without the dreaded code branching).

  • These need to be broken down into phases (and to be stirred back into the project scheduling cauldron) OR start branching the code. (See Part 3 - What goes into a release once your product is wild and live?)
Lacks differentiation

Sometimes everyone else has worked out what the top features are too, so you're hardly differentiating yourself.

  • Either search for another crack in the market.
  • Or seek to combine your top features with another market requirement - in which case, you might consider a partnership with an existing player.
Screws up your current or potential partnership relationships

Implementing some features may have implications for your (potential) partners - you make sure that you leave some value on the table for your partners to provide.

The more you require a partner that has distribution power already (or the more attractive you are to them), then you become more of technology provider rather than a commercial partner. At the same time, you become less of a competitor. Your role in the value chain is something that you need to ponder over.

This is a mistake that I have seen many times in start-ups: when partnering, the little player need to be conscious that their piece of the jigsaw needs to mesh nicely into the mosaic of big partner's offering.

 

Determining Technical Implementation Route

Ah, the Nuances of Feature Interdependencies

So, with some confidence you ask the Head of Development or the CTO to come back with some detailed work estimates to permit accurate project scheduling - I assume that you have been working with ballpark figures to date.

If your Head of Development / CTO is any good, he (or she) will go through this feature list with a fine tooth comb. He'll most probably say 'Ah, well, if you want to have features A & B then we really need to do project K that I have been wanting to do for ages. Project K will be much harder to do if we do B first.' You look at the contribution that K makes and it's way down the list.

All of sudden, a simple feature request becomes compounded into a huge, complex project. I call these types of features 'snowballs'.


Managing Snowballs

So these projects have snowballed and have bled beyond these original boundaries, as a result of this daisy-chain of interdependencies. At some point, these 'snowball projects' cross the boundary for reasonable release cycles. (See 'Too Long' in 'Think Strategy & Tactics' above.)

The PM & the CTO look at the requirements again. This time, they are both looking at the product, not from the eyes of the market, but from the requirement to build the features. Features that the Product Manager assumed were easy to do prove to be too risky or expensive for the value-add that they provide (and vice versa).

With a clearer understanding of the implications, you should now try to insert intermediate milestones into the snowball projects. These milestones should be placed in such a way that the product benefits the most, but, at the same time, provides the most flexibility in the future. This is certainly a black art and is utterly dependent on the technology and the market objectives.


Road-mapping

Finally, you need to put these projects into a release plan - you have most probably done this mentally already. At this point, you want to look at the macro level:

Once you've juggled the answers to these questions, then the Product Steering Committee should be able to sign off the Road Map. This represents your 'metal road' through the jungle of product development - should a competitor's action or newly-crystallized market requirements become apparent, this represents the map that you can refer to before unleashing any shoot-from-the-hip response.


Conclusions

Well, it is pretty close to a project plan for the short- to mid-term: product features are the defined deliverables, product specs should be in the final review stages, interdependencies defined, resource estimates all mapped out. In the longer-term, the senior management has confidence in a well-defined Product Road Map.

Never has product management looked so organized, human resources has such a well-founded idea of hiring requirements and never has the CFO felt so confident about the future revenue and cost projections - that complex Excel sheet might actually have a grain of truth in it!!


Summary


Part 3

In Part 3, I'll cover:

Back to Part 1