An effective product roadmap is a must-have for any successful software development project. A roadmap helps the product manager define the trajectory of a product, communicate progress to stakeholders, visualize goals and justify changes to budget. Product roadmaps are where both strategy and tactics combine to help teams build better products.
Given that it’s such a vital part of successful software development, why do product teams struggle to implement product roadmaps? Because road mapping is complicated, software projects are complex and every product team is different.
PROBLEM 1 - MAKING ARBITRARY ESTIMATIONS OF SCOPE AND TIME
It seems sensible to put fixed dates and scopes on roadmaps, right? Wrong. Putting guess-timate release dates and scope parameters at various points along the roadmap is less likely to make you stay on track and more likely to force the team to sacrifice product quality just to stay within the roadmap.
Solution: The slick answer would be “stop fixing dates and scope, period”. But you still need to keep everyone on track. So a better solution is to replace dates with themes: decide on one focus theme per Quarter and work towards theme priorities without worrying about deadlines. You’ll have more flex to react to change without going off track.
PROBLEM 2 - FOCUSING ON SOLUTIONS, NOT PROBLEMS
When creating a product roadmap, it’s easy to get caught up in all the great solutions you and your team plan to build. The problem is that some product teams end up devising solutions without understanding the user problem in its entirety. When development starts in earnest no one goes back to check that the original problem is still relevant. To build an effective solution you need to understand the problem; to build a roadmap to that solution, you also need to understand the problem.
Solution: Build a problem roadmap, rather than a product roadmap. A problem roadmap focuses on problems to be solved rather than features or solutions: in Phase 1, teams research and validate the problem, and build out an MVP to use in market tests. Only in Phase 2, Build and Validate, do they move on to thinking about solutions, testing and iterating ideas
PROBLEM 3 - TRYING TO PLEASE EVERYONE BY GOLD PLATING
Everyone has an idea of what the final product should do and how it should do it. Product Managers have to listen to the requirements of all relevant stakeholders and incorporate them into the roadmap. But if you try to cater to everyone’s needs you’ll end up with a roadmap that’s more of a feature soup than a useful guide. Including unrealistic or overly detailed features in the roadmap is a recipe for disaster: sure, the team will feel more secure at the start of the project, but by the end features will have been dropped or lost, and stakeholders will be disappointed.
Solution: Resist the temptation to pack the roadmap with features, no matter how many requests you get. If you find it difficult to say no to stakeholders then consider organizing a dedicated roadmap visioning workshop, gather everyone’s feature ideas in that workshop and then include in the roadmap only those that complement user needs.
PROBLEM 4 - POOR COMMUNICATION WITH DEVELOPERS
Product developers and product managers need each other. Without PMs, the engineers on the team would keep cranking out features with little understanding of wider business or market strategy; without the engineers, PMs could apply all the strategies they want but they wouldn’t be able to code those strategies into a viable reality.
Despite this mutual dependence, product managers and developers sometimes forget to sit down and talk. Not surprising, considering they kind of speak different languages. Nevertheless, effective communication between PM and product team is vital when it comes to building a roadmap. For a roadmap to be realistic it needs developer input.
Solution: Stop assuming that developers don’t care or don’t understand the business side of things. Be transparent and involve the developers in defining product vision and direction. Agile development practices are a good way to introduce frequent communication and increase development team buy-in.
PROBLEM 5 - NEGLECTING TO BUILD RESEARCH, TESTING AND FEEDBACK INTO THE ROADMAP
Every product manager worth their salt knows that research, testing and feedback need to be built into the product roadmap to make it realistic. But for some reason, these crucial phases often get merged into general “design and iteration” tasks and dropped from the roadmap. The real impact of this is that vital information garnered from early-stage usability testing with wireframes and interactive prototypes is wasted. And feedback is not collected post-launch, meaning the reasons for a product’s success (or failure) are not documented.
Solution: The solution is simple - allow sufficient time in your roadmap to carry out research, testing and feedback. Wireframing and prototyping tools can help by cutting down the amount of time spent on each of these phases: requirements gathered from research can be stored within the prototyping tool and linked to specific prototyped features, and feedback from testing can be noted within this visual requirements documentation. Integration with usability tools means that user testing can start earlier and be done more efficiently as well.
PROBLEM 6 - NOT RESPONDING TO CHANGE OR FEEDBACK
If your roadmap is too detailed or restrictive it can become difficult to react to inevitable changes. This happens for several reasons: mentally, a possible divergence from ‘the plan’ can feel like failure; stakeholders or investors might apply pressure to deliver those promised features or deadlines; or there might simply not be time to respond adequately.
Whatever the reasons, failure to respond to change or discoveries made during feedback activities can result in launching a product that no longer meets user needs, or is obsolete.
Solution: Move as many details as possible out of the roadmap and into the product backlog. Janna Bastow has it right when she says that the roadmap doesn’t have to contain “every last nook and cranny of your development plan”: epics, bugs, wireframed scenarios and everything similar belongs in the backlog.
PROBLEM 7 - FAILING TO GET BUY-IN
This is a different sort of problem. All the previous roadmap problems are under the PM’s control. Buy-in, however, depends on the agreement of others. Product success is much more likely when all stakeholders - from internal teams to investors - have committed to the roadmap and are willing to do what it takes to see it implemented. Trying to implement a product roadmap without buy-in is hard, tilting towards impossible.
Solution: As a product manager you can’t 100% guarantee buy-in from everyone, but there are things you can do to maximize the possibility of getting it. One great idea for getting stakeholders to understand the necessity to compromise on priorities is to present them with a workload of all feature requests received, then covering some of the image to represent how much your team can actually realistically deliver. It seems basic but that way stakeholders are more likely to buy-in to the roadmap even if some of their cherished features have been dropped.
When designed right, a product roadmap can be a great tool to convey the product vision and high level direction to team members and stakeholders; but if designed incorrectly, it can become a stick with which to beat the product team. The main lesson from these common product roadmap problems is, less is more: cut out the restrictive dates and deadlines and relegate detailed features and tasks to the product backlog, and be ready to react to change. At the same time, keep talking to the team, keep listening to stakeholders, but don’t let them dictate the direction of the roadmap. By staying true to these tactics you’ll have a greater chance of building a product roadmap that actively boosts product success.
credit: Cassandra Naji
Does your organisation need world-class IT & Business Consultancy services?
Contact us at Jadetan Enterprises Ltd
Tel: +44 (0) 844 884 5311
Website: http://www.jadetan.co.uk or http://www.jadetan.com