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 anslided 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 roadmapping is complicated, software projects are complex and every product team is different.
Despite these difficulties, product mapping is far from doomed to failure. In this post the Justinmind product team outline some common challenges they’ve come across when building roadmaps for our product (an interactive prototyping tool), plus tactics to solve those problems and build an effective product roadmap.
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. Or as
lean UXer Jeff Gothelf has it:
Pulling 80 hour weeks or continually pushing release dates back results in low team morale and buggy products. The product team needs to focus on the needs of the user, not arbitrary deadlines.
Solution: The slick answer would be “stop fixing dates and scope, period”. But you still need to keep everyone on track. One solution, as explained by
Janna Bastow on ProdPad, 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.
If for some reason you can’t jettison product deadlines altogether (say you work with a lot of big enterprise clients and they need reassurance about planned product releases and updates), apply looser ‘
time horizons’. Instead of focusing on a specific date in the future, time horizons focus on loose blocks of time - Now, Near Future and Far Future, for example. Horizon 1 encompasses what you need to do today for existing customers, Horizon 2 is the work that needs to be done for future deliverability, and Horizon 3 is where the innovation happens.
Another workaround for product deadlines is to introduce project milestones or significant events, by which time you hope to have certain tasks accomplished. For instance, completion of new UI assets for updating the blog’s mobile experience by the first scheduled review. Using milestones as goals will help to make progress visible for the team and stakeholders, without giving precedence to firm scheduling.
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: Product Manager Melissa Perri suggests building 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. Find out more on building a problem roadmap on Perri’s blog.
Problem 3 - Trying to please everyone with a feature soup
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. Christina Perfetti of Perfetti Media provides some tips on running product visioning workshops in
this Slideshare.
Remember, this is not merely a way to stroke egos; roadmap visioning workshops allow you to tap into the knowledge and expertise of everyone involved with the product.
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.
Onespring’s JAM sessions are a useful way to get developers to think creatively about the product they’re involved with: originally a methodology to elicit software requirements in real-time, JAM sessions can also help define product roadmaps and get to the heart of a product’s functionality. Sit down with the development team and build rough wireframes or even prototypes in real-time, iterate and build again. Note down the hidden requirements that the developers uncover; you can use these to define the direction of the roadmap later on.
For more general advice on PM-dev communication, Brian de Haaff has some great (and funny) tips on
how to communicate better with developers.
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.
Your product roadmap scope should remain wide enough so that if changes are needed, they can be implemented without drastically changing the roadmap’s terrain , your team’s day to day activities or stakeholders’ expectations.
Agile Product Management master, Roman Pilcher, suggests that you
shape your roadmap’s themes into a story about the growth of your product. By focusing on the story - rather than diving into each task - your roadmap will remain intact despite adaptations. This will allow you to comfortably switch in and out the product backlog items where needed.
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. Kelley Sebes offers lots of sage advice on
UserVoice’s blog. One great idea for getting stakeholders to understand the necessity to compromise on priorities is to present them with a wordcloud 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.
Tactics to solve common product roadmap problems - conclusion
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 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.
Author: Cassandra Naji, Marketing Content Editor,
Justinmind
Cassandra Naji is Marketing Content Editor at Justinmind, a prototyping tool that allows you to prototype web and mobile apps so you can visualize and test your software solution before writing a single line of code.