product management

8 tips for managing an agile product roadmap

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?

Saying “no” for the greater good

Being responsible for the success of your company means that you strive to achieve maximum happiness levels for your customers, employees, and stakeholders. So of course, your first instinct tells you to say yes to each and every request. Saying no is so much harder, but there are many cases in which a “no” is indeed in the best interest of your company and, in the long run, for everyone involved, including your customer base. Let’s take a look at situations in which a “no” makes sense and really shouldn’t be this hard.

No to a feature

“If we only had this feature, we’d win every deal”. I’m sure you’ve heard similar statements from your sales reps. And yes, your reps are the ones who directly interact with your prospects, so it’s only natural for them to share a prospect’s comment during a demo with your product manager or leadership. Feedback from your reps is vitally important and you should always hear them out. But it’s equally crucial to teach your reps to ask questions with regard to the prospect’s objectives rather than about their preference of a specific feature. Sometimes, another vendor may have sold the prospect on a certain feature but there may be better ways to accomplish the prospect’s goals. Or maybe the flashy feature that your competitor made sound so appealing just doesn’t fit into your vision of your product and the future of the industry or isn’t even in the best interest of your customers. Understanding your prospects’ goals and identifying the ideal way to help them achieve those goals should be at the core of your road map. And that may very well mean saying no to a feature request. Take all feedback seriously but to stay true to your vision and always have the best interests of your customers at heart. Don’t dilute your product with features that might result in a quick win (as in increased sales) in the short term but that make your software hard to maintain, don’t drive the desired results for your customers, or prevent you from working on better, more impactful features.

No to customizations

Similarly, your prospects may approach you with customization requests. Typically, the younger your company and the more prestigious the potential customer is, the more inclined you are to say yes. Be cautious. Once again, consider the long term impact. How hard will it be to maintain the customization? Is a SaaS based model what you ultimately strive for? If so, how will you handle clients who have their own customized product? Does it even make sense for the client? Customization requests can spawn a lot of great ideas for your road map, so be sure to listen and ask questions. But don’t be afraid to say no to something that will hamstring your engineering and support team.

No to projects

At Hannon Hill, we’re lucky enough to have a thick pipeline of project requests from our customers, ranging from small implementations to content migrations and even large scale integrations. Occasionally, the scope of a request falls outside of what we typically provide. Clearly, we would never take on a project if we thought it to be a bad fit for our areas of expertise. We want to focus on what we do best. We will consider saying yes if a) we fully understand the scope and the risks, b) it’s something that will make future projects and helping other customers easier, and c) it helps our team members grow professionally. However, if the answer to those questions is no or if we believe that our partners are better suited and can deliver better results, it’s a no. After all, would you want your plumber to install your hardwood floors?

No to terms and conditions

Ah, contract negotiations. They sure can be tricky. As a software company, you protect yourself by having a license or subscription agreement in place which clearly states your and your users’ responsibilities. It defines warranties, liabilities and indemnification and outlines processes for remediation in case of a dispute. Sometimes, your potential customers want to negotiate the terms of your agreement or even provide their own contract. What do you do? You can either stand firm or negotiate. In certain circumstances, it may be okay to make a concession, while in other cases, you need to assess whether the level of risk of agreeing to a change is worth it. As you know, even the most rigorous QA process can only reveal the presence of bugs, but not their absence. If the potential customer’s terms specify warranties and liabilities that open your company up to a potential financial loss that is disproportionate to the value of the deal, saying “yes” would not make sense, but narrowing down the definitions of the terms would. At the end of the day, a customer who is a good fit will shy away from working with a vendor who will agree to just about anything to get the deal, even if that means jeopardizing the longevity of the business.

No to a prospect

Arguably the hardest “no” happens when you have to walk away from a potential customer. But sometimes, a prospect is simply not the right fit for your product, your service, or your company. This can have a variety of reasons. The prospect may not have the proper staff to be successful with your product. They may have unrealistic goals or expectations. They may actually need a completely different type of product. They may not even really understand their own needs or need something that is not your area of expertise. Regardless, reject the idea that any new customer is good for business. Wouldn’t you rather provide good guidance to your prospects by saying “no” than to lose them once they see for themselves that it wasn’t a good fit to begin with? The wrong fit is bad for all parties involved. It can have a negative impact on team morale and on your reputation (and thus, future business).

At the end of the day, you want to deliver the right product to the right customers under the right conditions in order to ensure long term success and happiness. And that’s why a quick yes isn’t always the right answer. Say no when it’s for the greater good.

What about you? When do you find it unnecessarily hard to say no?