Feature Prioritization & Product Road Mapping (Part 1)
The first in a three part series on product management: prioritizing features and putting them onto a product roadmap.
The Problem: so little time / resources, so many cool features to add to the product. But in what order?
Overview of this Feature Value Matrix
This technique gives you the ability:
- to prioritize potential features in your product
- to reduce 'my favorite feature bias' from development, marketing, product management etc
- to lay out a product road-map - and how it can balance the market requirements (ie table thumping-CEO) with realistic development (frightened, hard-pressed developers).
What motivated me to write this document
I've often been asked, '... so how do YOU do product management?' Yep, product management remains a black art - particularly in smaller companies and especially in start-ups.
I answer - then after about 2 minutes, I notice people reach for a pen and paper and start to scribble furiously. I then worry a little - because I see the glimmer of determined, slightly misplaced hope, like a drowning man sees an able-bodied swimmer passing by.
This document saves the scribbling, explains some of the nuances of a practical technique that I have developed and used on a number of occasions. It indicates this technique's strengths and why you shouldn't stick it too rigorously.
Who should read this document?
My ideal user is a product or development manager in a (small) software company that has:
- huge heap of potential requirements that could be added to his / her product
- limited time & resources
- the commercial prerequisite to produce something 'cool' and 'now'
- that can be developed by mere mortals in reasonable timeframes
- and that the Product Manager doesn't really have enough information from his/her own research or from focus groups to uncover what the market considers to be desirable.
This concept exists in sophisticated product management software packages (or at least I hope it does!). In small companies, such products aren't used because they require money and effort to implement, but more importantly, discipline and centralization to make work.
Assumptions
Fragmented Requirements
I can honestly say that I have never seen a bug database, a customer support ticketing system, a feature request system and a development workflow tool or code management system ever work together to be (a) useable and (b) give all the stakeholders the right level of information (c) when they need it. Perhaps a long time ago, in the Garden of Eden or when release cycles were measured in years....
Product management by committee
Product management is 'owned' by one person, but I believe a Product Steering Committee that guides the product machinations is essential in all but the tiniest software development companies. In a start-up, it might be the founders or the CEO, CTO and the COO with the PM. In a larger organization, the stakeholders might be representatives from product marketing, partner management, customer support, release management, corporate marketing as well as development and product management.
The Feature-Value Matrix
This is the heart of it.... and every product manager who has been a PM for a while will have done something similar, I'm sure. Download the Excel spreadsheet below.
 |
Explanation:
- Down the sheet: the list of potential features of your product. (Cells A6 to A20)
- Across the sheet: The list of attributes of your product. (Cells C5 to M5)
The matrix contains the relative contribution that each feature provides to the product (Cells C6 to M20). I have divided the attributes into approximately into Risk and Return. The titles of the attributes are arbitrary (others may call these product metrics) and clearly when you do this exercise yourself, you should edit as appropriate.
To use:
- List all the potential features that could be added to the product. (Cells A6 to A20)
- List the attributes that management considers valuable - limit it to 8 or less ie the ones that actually matter - see later for more on this. (Cells C5 to M5)
- Rate the contribution that each feature makes to the attributes:
- For Return attributes, then features that add lots of value should score highly (ie >5). Those that don't add value should score 0.
- For Risk attributes, then a high figure (7, 8 or 9) represents a low risk feature and 0 or 1 represents a high risk feature.
Unweighted Column (Cells C6 to M6)
This is simply the totals of the each contribution. See the first Bar
Chart (Value of Features Unweighted).
Hmm some problems...
Problem 1: What attributes matter?
The easy answer is 'the ones that are listed in your business plan'!
However many start-ups (and even established businesses) are run with little day-to-day thought on these metrics... and next to none on their interaction.
Of course we want growth, revenues and profitability - in fact double helpings of both, yesterday. These attributes, at best, demand compromises, at worst, conflicts. Giving away goodies for free will stimulate growth, but won't help profitability!
Attributes are dependent on the Product Life Cycle
Different attributes are more important at different stages of the maturity of the product.
Consider the Product Life Cycle Diagram (a plot of sales over time), indicating the stages of growth of the product.
As a guideline, I would suggest that the following attributes are emphasized, based on the product life cycle stage:
|
Stage
|
Significant Attributes
|
|
New to Market
|
Growth, Hygiene features (ie features that
everyone expects), PR stories
|
|
Mass Market Attack
|
Revenue, Features that open up partnership or
distribution opportunities
|
|
Established Player
|
New Markets, Profitability
|
In many cases, the relative importance of these attributes is not widely understood throughout the organization (even in a start-up). This can cause improper trade-offs when making product decisions and even programming decisions.
Changing the weighting of product attributes
These attribute weightings are not something that can be flipped for each release, as doing so can destroy all your marketing positioning to date and 'shock' your existing customer base. Clearly, an 'x.0' release is good opportunity to update (but not radically overhaul) these weightings, but even then modifying these more frequently than once a year needs some extra special justification!
Problem 2: Weighting of each attribute
After you consider a couple of features, you'll come to realize that some attributes are more valuable than others. The matrix allows you to accommodate this.
Decide on the relative value that each attribute makes to the product. Example: So, if you think that the 'Partnership' Attribute makes twice as much contribution to the product as the 'Revenue Generating' Attribute then set Partnership to 8 (Cell G4) and Revenue Generating to 4 (Cell D4), for example.
Enter values into the Weighted Row (Row 4), which in turn, gives you the Weighted Summation for each feature (Cells O6 to O20). See second Bar Chart (Value of Features Weighted) at the bottom of the sheet.
RESULT!
So with the bar charts at the bottom of the page, you can meddle with the figures and see the resultant change. All of a sudden, your favorite features are in places that you wouldn't expect, so you start to play around with the figures and working out the relative sensitivity.
If you show the chart to any other product stakeholder, they will mess with the figures to try and make their 'most wanted' feature bubble up to the top.
Let the bun fight begin
Once the key attributes have been decided for the product, then you'll realize that the relative weighting is the most important thing that the Product Steering Committee needs to agree on. If this hasn't been properly discussed before, then you can anticipate a good ol' bun fight. This is generally a good thing, because it uncovers all sorts of assumptions that may not have been expressed before.
Conclusion
This is the basics of the Feature-Value Matrix - hopefully some of the conflicting interests that surround Product Management start to become apparent.
Part 2
In Part 2, I'll cover the next stage in the process:
- Which features to eliminate
- Buy vs Buy & Partnerships
- What happens when your development manager sees this - and the ensuing trade-offs
- Road Mapping