A product roadmap is NOT a product backlog. So essentially it's not a prioritised list of tasks that you'd want to do. A Product Roadmap is Product Strategy. It entails, what is it that you are building, who for, and little insight about how? Are you going to cater to a wider audience in future or provide more value to similar set of customers that you are targeting now. I've tried to cover most of how one should be looking at the products (Problem-Solution Framework) in this video.
I've tried multiple ways of creating a Product Roadmap and have come to define a good way for creating a comprehensive one from which one can derive s.m.a.r.t goals. You know Goals need to be SMART (specific, measurable, attainable, reasonable, time-bound). And there is so much talk of being data-driven - just that not everyone has a clue of how to become data-driven. Most articles that I read about creating roadmap are about coming up with a laundry list of things and prioritizing them. You definitely need to do that but you might always miss out certain aspects when you go by that method. So, I came up with a framework to create a Product Roadmap that is both comprehensive and data driven.
Things I've tried earlier:
1. Doing a competition analysis and identifying list of features that need to be built. Prioritising it.
2. Collecting all ideas from every one, get every one to vote on them and then prioritise them based on Votes and Impact versus Effort analysis by tech team. E.g. Pandora does it really well.
2. Setting Goals based on the vision, deriving high level tasks and then create discuss, debate and decide priorities. This is actually much better than first one but it is not comprehensive. Your current set of goals may be too narrow or too wide.
You may still need to do some of it but these things have been very random.
Finally, to come up with a Roadmap that is both data driven and covers all aspects of growth I decided to draw it through the standard Metrics of Acquisition, Conversion, Money, Engagement (ACME). You'd still need to debate, discuss and document your vision, short term, medium term and long term goals. But, putting it in these broad categories gives you a good coverage.
Step - 1
Define your vision and tentative goals or themes in next few months typically next 1 month, 3 months and 6 months. This can be very high level -
E.g. 1 want to improve revenue
E.g. 2 want to optimise new user acquisition/conversion
E.g. 3 want to improve user retention
Bucket your goals in to ACME. You should have Acquisition Goals, Conversion Goals, Monetisation or Revenue Goals, Engagement Goals. In fact, if the vision is clearly defined you can just start noting your ACME goals. Start with high level as given in example and then break things down to smaller items.
Step - 2
This is good place to have lot of dependencies and conflicts. E.g. You might notice that you can't achieve target revenue without improving both acquisition and conversion. And hence priority of each goal would need to be analysed again. Similarly you may have kept engagement as short term goal but the tasks required to achieve it may not be complete in short term so that again needs you to shuffle your itinerary.
After this exercise you should have a list of of things sorted in a more feasible order. You'd again need to prioritise this list. One way of prioritising is to gather all stakeholders in a room and explain every one the task and get developer and QA guys to rate the effort - low, medium, high. I would define low as less than a day, medium as 3 days and high as 5 days or more. Similarly, product and business guys should rate the impact of that task as low, medium, high. Obviously, low effort high impact tasks would get priority.
Step - 3
Define how you will measure the success for each task. Define it to the metric and formula you'd use to measure the impact of that task. This can be complex and one may not be able to do that in a meeting like setup. However, assigning two stakeholders for each task and both of them working in pairs to come up with this works great. This is very important step.
Many times when you try defining the measurement metric for tasks you may realise how easy/tough or trivial it can be. In quite a few case it unveils what we are not measuring and we should. It also makes a case for better instrumentation of your product.
Step - 4
Go ahead and publish this to all stakeholders. Let every one be inspired by what's coming and what they are going to build for the world.
Thoughts? Questions? Please leave your comments.
No comments:
Post a Comment