One of the hardest and ironically the most important thing a product manager has to do to be successful, is to develop and maintain a roadmap. There are many books and articles in roadmap development but they are usually too complex to integrate into your organization and are usually waterfall based because all executives like predictability. Below are some practical methods to define and maintain a roadmap.
Roadmap Strategy: Value vs. Effort
- In the value versus effort feature evaluation model you directly compare business value to effort/complexity in a visual matrix or using excel grid.
- Obviously the ones that are high value to low effort should be the higher priority features
- There are 3 types of monetization impact that you can use for the business value: Revenue Gain, Operation Cost Savings and Revenue Loss Avoidance
- For effort: You can estimate relative implementation and operation cost estimates otherwise just use High, Med, Low Effort
- Note: Features that can’t be monetized directly or are strategic in nature can have a high value even without direct impact to revenue
- Consider doing a little bet on your feature or new product (explained below) so that you can better assess the value
Roadmap Strategy: Weighted Scoring
- In the weighted scoring, identify weights which can often be subjective and compare to effort
- Possible value weights can be: Revenue gain over a period, operational time/cost savings, revenue loss avoidance, customer delight (subjective), Strategic or tech debt value
- Possible effort (price) value weights can be: Cost to build, Operation Cost addition (to deal with the product)
- Just like the value vs. effort this is best done in excel or a tool
Roadmap Strategy: Little Bets or Tests
- This is probably the best strategy for new product categories, new feature categories or for a business assessment of new product. Usually you do this if you are not sure you want to go all-in or it is unclear if it can be developed from a technical feasibility perspective
- Remember you are often assessing the customer need than testing the solution. So upfront you should clearly identify what you are trying to learn and define and develop customer need tests and/or solution tests to meet your learning objectives
- Possible Bet Idea
- A wireframe prototype which show to your target customers
- Screen shots in a powerpoint deck that you share and get feedback
- You can even buy related keywords and product a quick and dirty website to see the amount of searches that exist that relate to the customer need. The keywords can be both solution related or can be customer need related
- A little bet for technical feasibility can be a small prototype or just iterative tests of the technology that would be used to build the solution. Without this you may find that you clearly have a customer need for a product that you can't actually build (at least not yet).
- A/B testing. You can statistically test your idea if you have a new feature that is an improvement of an old feature. In this case you can release the new feature to a small but statistically significant group of users and measure the impact of the new feature compared to the old one. In this case the old feature is A, and the new feature is B.
Roadmap Strategy: Weighted Scoring
- Force Ranking: First thing to remember is that all features must be force ranked. Force ranking is needed otherwise the temptation is to just group all the high priority ones together and start each high value feature simultaneously thinking that is the best strategy. Remember you have limited resources of time, money and product team members. You will end up doing all your high value projects in a piecemeal fashion and it will be slow going
- Shared Roadmap: The roadmap should be easily visible to at least the executive and product teams. Ideally this should be public within the whole organization. If there are secretive products in the works, it should be shown only to the direct contributors of the project and the executive team
- Use your roadmap tools consistently: There are many tools out there to organize features, pick one and learn it. Remember an average tool properly used consistently is better than a great tool that you use inconsistently
- Feature Naming: Careful on the naming of initiatives or features. Ideally the name should convey the value to both the user and to the team that is evaluating, building it or marketing it. Make sure to get your marketing team and product team to come up with possible names that relate to the need that it is solving or helps explain the solution clearly
- Evangelize!: Remember if you can't maintain or evangelize your roadmap someone will end up doing it and you will slowly lose your autonomy as a product manager.
- Little Bets: I can't stress the importance of the little bet strategy written above. You will quickly find that everyone in your company will come up with features and since everyone on the executive team wants predictability and clarity on the product roadmap, you will end being forced to make decisions on product features without fulling understanding their value and their effort. So little bets or tests gives you a systematic way to prove things before going all in on the feature development.
- Measure!: Ideally all features, initiatives and tests need to be measured so that you can learn . Identify the measurements up front and start simple and make sure to add the measurement capability within the implementation scope. Otherwise the temptation is to plow on forward to the next feature without adding measurement capabilities to your software platform.
I hope that you were able to glean some practical tips on roadmap development. Let me know if you have any questions at Michael.irschick@gmail.com
