Creating and maintaining a product roadmap is often considered one of the biggest challenges for startups and well established software companies alike. Startups need to be able to rapidly build out new functionality and to pivot quickly based on customer feedback and changing needs. Companies who have developed a highly complex, enterprise-level product have to consider how each new feature would impact the system and a potentially wide customer base. Managing a product roadmap that strikes the right balance of foresight and flexibility requires an agile and a customer-focused mindset, as well as a lot of planning and research. Here are a few things to consider.
Capture all relevant feedback
There’s no shortage of feedback channels. Your users provide a plethora of direct and indirect input when they submit support tickets. You may also consider setting up an idea exchange on which users can make suggestions for both new features and enhancements to existing ones, and comment on and vote for other customers’ ideas. Hold feedback sessions with your customers and hosts focus groups. Make sure that all of your customer-facing team members relay things that they hear from clients. Listen to internal ideas from your Services and Support teams. Most importantly, store all relevant feedback in one place so that you’re able to detect patterns more easily. At Hannon Hill, we use Productboard, but there are many other tools available. Use tags for each item so that you can better categorize and find entries.
Always start with the objective
When you’re evaluating all of the suggestions you’ve compiled, don’t fall into the trap of immediately focusing on features. Instead, approach each idea and request with the question “What’s the goal?” You’ll always want to make sure you think about the best way to accomplish a certain objective, so if you jump into “What’s the feature?” mode, you run the risk of missing out on better, more creative, or more effective ways to help your customers achieve their objective and solve their problems.
Involve multiple departments
Don’t put all the responsibility of creating your roadmap on your product team. Many departments can and should be involved in gathering customer feedback, but don’t stop there. You may have one or more team members in each department who have a knack for asking the insightful questions or for coming up with creative solutions. Invite them to roadmap and sprint planning meetings.
Determine impact and complexity
Once you have determined the features that are candidates for your roadmap, assess the impact and the complexity of each one. Impact can be a number of things, such as added security, better user experience, fewer support tickets, or faster onboarding. Rate the impact on a numeric scale. How much of a difference will each particular feature make? Next, analyze the complexity of each feature. How difficult is it to implement? How much time will it take? What will be the impact on other parts of the system? Generally, the more things you have that have a big impact and a low level of complexity, the better. When planning your roadmap, finding the right balance is both an art and a science.
Who will work on what?
One of the aspects of roadmap planning that is often underestimated or not talked about at all is how the make-up of your product team and each individual can impact the roadmap. This is especially powerful if you have a team that’s small enough to afford you the luxury of fostering each developer’s interests and strengths and find alignment with your product goals. When putting together your roadmap, always capture who is most likely to work on what. And, of course, in an agile shop, let your developers self-assign items as much as possible.
Identify how you’ll measure success
It’s a cliché and it’s true. You can’t manage what you can’t measure. For each individual item on your roadmap, for every sprint, and for every release, capture the metrics you will use to measure success. This could include adoption/usage rates, Net Promoter Score, estimated versus actual development hours, or fixes needed.
Re-evaluate after each release
In order to maintain an agile roadmap, you have to be flexible enough to make adjustments as needed. After each release, hold a post mortem, discuss what worked well and what didn’t, and don’t be afraid to make changes based on your findings. In addition, always consider new trends, new technologies, and new problems that you need to solve. Reserve the right to do what’s right in order to deliver the best possible product to your customers at all times.
Talk about themes
Even if you are fairly certain about the features that you will add to your product in the next one to three years, be careful when talking about specifics that are too far in the future. When presenting your roadmap, only show and talk about features that are on the immediate horizon, that you know for sure are going to make it into the product in the way you describe it. You certainly don’t want to paint yourself into a corner and forego changes that make more sense at the time of rollout. Of course, you do owe your customers a roadmap, so “we’ll see what shakes out” won’t cut it. When presenting your roadmap, be transparent. Talk about themes and educate your customers about the advantages of an agile approach. After all, you want to be able to respond to current and upcoming trends in a way that optimally benefits your stakeholders rather than being boxed in by a promise you made a year ago at your user conference. When talking about themes that you will address in your product, be specific only when you can and be sure to talk about the big picture and the goals that you will help your customers achieve.
Creating and maintaining an agile roadmap can enable you deliver better products, but it requires the right people on your team and emotional intelligence when it comes to communicating with your customers. Don’t confuse “agile” with flying by the seat of your pants. Always, always be working on your roadmap. It takes a lot of research, a lot of listening, and a lot of planning. You have to be prepared in order to be make meaningful and impactful changes along the way.
What about you? What are your thoughts on maintaining an agile roadmap?