Developing a Roadmap for a New Product
If you’re a Business Analyst or a Product Manager, chances are you have been responsible for developing a business/product roadmap at some point in your career.
In some organizations, particularly those that either (1) have growing or mature products or (1) those that are predominantly waterfall, product roadmaps are developed with crystal vision and high precision for 2–3 years down the road. There’s also a little room for change (i.e. scope creep!) primarily because the roadmap is developed keeping in mind market & innovation trends, competition and profitability and hundreds of resources are already actively working on stuff.
However, what do you do when you’re managing a new product, particularly in a large & established (process-heavy) organization, where everyone’s after you for crystal clear product vision, and you’re barely trying to make the only customer you have, happy?
There are several challenges to developing new products, particularly in the enterprise space, when your first few customers are extremely key to the future of your product and much of the product shapes from the requirements & needs given to you by them. As a business analyst or product lead, you’re often caught in the battle of building features for that first customer, even if you don’t particularly think this might help you scale. Moreover, everyone in the team is looking to you to figure out what to build, both in the near term and the long term and when this get’s particularly challenging is when the customer asks you for a huge feature or integration that requires a lot of ground-work upfront — and also wanted it yesterday!
Nevertheless, as a business analyst, it always helps to plan your roadmap to the best of your knowledge in order to keep your product vision and strategy aligned at all times while giving the rest of your team & organization a preview of what’s likely to come. Here are some roadmapping methods I’ve learned & executed as a PM through my experience in developing new products and solutions while trying to put some method to the madness!
1. Reduce as much ambiguity on the ‘now’, while setting some context on the future.
A roadmap does not necessarily have to span over multiple years or even a full year. And it also does not necessarily have to be time-based. Particularly for new products that are yet to see the light of the day, or are just beginning to, a now-next-later framework works great — the key is to create something that everyone can understand and get a sense of your product vision and why you’re building something.
Source: https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/
I have in all-honesty built roadmaps with my team that look something like this, mostly because of varying release cycles and business priorities:
Source: Self-illustrated
2. Take your stakeholders along the ride.
I’ve been in many roadmap planning sessions where the product & design team have put down all of the things we think we want to build on sticky notes, brought the key stakeholders into one room (usually KOLs representing sales, marketing, business development & engineering teams), and had them group things either by product category or by ‘must-haves’ and ‘nice-to-haves’ and dot vote on the top 3 things they would like built. This technique works well particularly when a product is still in stealth mode and you as a PM is figuring out what the MVP version should have.
Source: http://dotmocracy.org/dot-voting/
An even more methodical and quantitative approach to roadmap planning & development can be to define evaluation metrics and identify a rating & score for each feature in consideration. You could either come up with the rating based on your own knowledge of the space or let your team determine a rating for each category. As a next step, you could either self-score all of the items in the list and review with your stakeholders for feedback and changes (which can be more time-efficient) or you could have each stakeholder score the items individually or together as a group. At the end of the process, you should have your prioritized roadmap based on the weighted totals.
Source: Self-Illustrated
3. Resource based roadmapping
Another way to plan your product roadmap can also be from the bottom-up — i.e. resource based roadmapping. Perhaps you work in a large organization and there are offshore resources who are available and allocated to work on your product (because it’s going to be the next big thing!). When this happens, you could use your team’s help to figure out (1) how big a feature is (Large, Small, 1 sprint, etc.) (2) what components does it involve (i.e. client, server, UX, etc) and (3) what value it could bring to your product & customer. This approach is great for those “big ticket items” that your customer would like to have in your product — like an app or service integration or a new algorithm — that need more time & resources to develop and could potentially be done in parallel to your “now & next” items.
Obviously, there are pros and cons to all of these approaches, and a lot of factors go into planning new products besides just customer needs — like competition, growth, revenue generation, etc. and sometimes PMs are also simply “told” to develop products as a response to the market or your competitor. In any case, roadmaps are a great way to visualize your product journey while enabling the rest of your team better plan and organize their work.