Product Roadmap Prioritization — You Asked, We Answered [280 Group]

This month, we presented the webinar, 5 Secrets to Prioritizing Your Product Roadmap (The Right Way!). You can view the accompanying blog post to learn about weighted scoring and the Kano Model. We received so many great questions on the topic and have included answers to the top questions down below. Thank you all for engaging in our webinar!

Strategy

Are Corporate Strategy and Business Strategy the same?

Yes and no. If the corporation is essentially one business unit, these terms would mean the same. If a corporation is made of different strategic business units, then corporate strategy and business strategy would be considered as different strategies. From a product management perspective, you’ll want to focus on supporting the business unit strategy. You can learn more with this helpful article.

Backlog

Should the backlog be used for team communication or can it be shared with business stakeholders? Oftentimes, I see a PM communicating a mix between a roadmap and a backlog, and I’m trying to figure out how to get them comfortable with sharing both.

I highly recommend that you share the roadmap with business stakeholders and use the backlog for planning within the development team. If you have created a trust relationship with the business stakeholders, they should be most interested in the business outcomes and the execution of your product strategy and not the details of the product backlog. You create trust by creating a roadmap based upon clear evidence, earning their buy-in, and delivering against business expectations. It’s when that trust relationship breaks, that your business stakeholders will start delving into the details of the backlog.

Please note, I’m not saying you should hide the backlog and refuse to show it if requested, I just would not create that expectation of them having a view into, or control over, the backlog. In addition, welcome business stakeholders to your sprint review sessions and let them see the visible progress that you are making, which is even better than seeing a backlog.

As a Product Manager, should we focus more on the Portfolio rather than Backlog prioritization?

As Product Manager, you want to focus on the overall strategy and driving business outcomes for your product. Ideally, you are working with a Product Owner who manages backlog refinement and prioritization. You can see more details on 280 Group recommendations for these two roles and how they can collaborate in our article, Product Owner vs. Product Manager. If you are the sole person responsible for both roles, make sure you manage your time so that you don’t get pulled so deep into Product Owner work that you don’t have time for the strategic work of the Product Manager. In this situation, share with the whole scrum team your full set of roles and responsibilities, and ask them to help out on Product Owner responsibilities, so that the whole team benefits from you having the time to work on product strategy.

Models

Any thoughts around Prioritization Models if one PM organization is responsible for both client-facing revenue-generating software, as well as internal business process software?

A lot of this depends on the team size. A larger organization should really divide the client-facing and internal business into separate teams. If you are a smaller organization, consider having a team member (or several team members) focus only on internal work and the rest of the team focus on external work. The same consideration applies to your development resources. The reason for this is the cost of context switching. Multiple studies show that task switching has a huge cost on productivity, especially for your development resources. Try to avoid that as much as feasible.

If your team is too small to divide as suggested above, then I recommend that you prioritize within workstreams – an external-facing workstream and an internal-facing workstream and allocate product management time and development team time accordingly.

In reference to the Kano Model, under Customer Delight, how is it measured? Do you look at the number of customers actually using the feature, or interview them to know what would delight them?

When using the Kano model to prioritize, you can measure potential Customer Delight via quantitative or qualitative methods. Qualitative insights are driven by your Voice-of-the-Customer activities and can be based upon the percentage of positive responses you receive, but you’ll want to ensure you have a reasonable sample size (7 to 10 is often enough) to give you a qualitative sense of delight. If you have the resources and time, there are many quantitative techniques, of which conjoint analysis and Outcome-Driven Innovation are some of the most comprehensive techniques.

How do you measure “confidence” in the RICE model?

Confidence is based upon the likelihood that your estimates of Reach and Impact are correct. This is expressed as a percentage between 0 and 100%. A common use of percentage (as recommended by Intercom): 100% is very confident, 80% is medium confidence, and 50% is low confidence. Anything below the 50% level of confidence will essentially negate any estimate of Reach and Impact. You can read more about the RICE model here.

Can you explain “performance features” in the Kano Model?

In the Kano Model, performance features are those attributes which can be offered in a potential range of qualities. These are features where “more is better”: if you put more investment in time and resources into performance features, this effort will in fact result in a linear or proportionate increase in customer delight. In software, we often think about these in terms of speed of action, ease of use, scalability, etc. In other products, this may relate to ranges of strength, battery life, durability, safety, etc. Remember, the satisfaction level for each performance feature is different based upon the target market segment.

Features, Roadmap Building, and Launch

What is the difference between revenue enhancements and enhancement requests?

There can definitely be some overlap on the interpretation of these two types, but when I think about revenue enhancements, I’m thinking about new features or capabilities which are part of your product growth strategy and that have a direct connection to increasing revenue. Enhancement requests are minor improvements to the product that enhance the overall customer experience, but typically do not have a direct connection to revenue, though they can increase customer loyalty over time.

Most often schedules/target dates fixed during roadmap development could change once we go for a detailed planning. Can you please suggest how we can avoid such issues? Can we go for a detailed plan for downward activities during roadmap development?

I was just speaking with a colleague today about this topic. There is a cone of uncertainty that correlates to how detailed your requirements are. The less detailed your requirements, the larger that cone of uncertainty is. As you refine your requirements, as part of your planning and backlog refinement process, that cone of uncertainty will decrease.

My recommendation is to use estimation techniques that reflect that uncertainty. So, instead of stating story points or development hours when the uncertainty is still high, you should have your team estimate on a less granular level, such as t-shirt sizing. Instead of communicating specific dates, speak of quarters (or even a year range). This approach clearly communicates that there is uncertainty. Then, as you refine the requirements and scope, you can start adding more precision to your estimates and dates.

Great information for prioritization of “off-line” product development. Do you have some guidance on prioritizing these roadmap items alongside accepting short-term, specific customer demands in order to capture business to meet short term financial commitments for the company?

Welcome to the real world (LOL). Here are several considerations to help you address this challenge.

First and foremost, always evaluate if the customer request is aligned to your product strategy or not. If it’s not aligned to your strategy and it’s going to divert you in the wrong direction, you should do all you can to avoid doing this customization. If the cash is more important to your executives than following the product strategy, or the customer is too important to the company, you may lose this battle—but, at least you presented strong rationale for not doing it.

Another consideration is to use the workstream or theme model that we discussed in the webinar. This is where you allocate a certain amount of development resources to client-specific work, which keeps you on track for your roadmap, but also enables the team to consider client-specific work within your defined resource constraint.

Ask the question if you can hire outside resources to support the customization. If the customization revenue has good margins, it may be quite feasible to hire a lower cost team to support this work.

Do not be afraid to ask a premium price to do the customer specific work. This has two potential benefits. One is that it can cause the client to reconsider the custom request and accept your standard product direction as-is. And if the custom work is valuable enough for them to want it, they’ll accept the price and you can use that additional margin to fund the extra resources. Remember, any custom work takes your team away from doing more scalable product work and that has an opportunity cost to it, so be willing to charge to cover that cost.

Do you have a best practice or method for prioritizing features by quantifying it (i.e. matrix using customer impact, profit impact, etc.) rather than its sometimes subjective nature.

One of the approaches I have seen companies take is to clearly identify what each score (0 to 5) means for each of the criteria. These definitions are dependent upon your business. For example, for revenue impact, I can define the following:

• 0 – adds less than $500 thousand new revenue
• 1 – adds up to $2 million new revenue
• 2 – adds up to $10 million new revenue
• 3 – adds up to $25 million new revenue
• 4 – adds up to $50 million new revenue
• 5 – adds greater than $50 million new revenue

If you do this for each scoring criteria, you have a much more quantifiable approach. Each product will be prioritized by the same criteria and you reduce the debate in why a particular score was assigned.

What do we need to consider when prioritizing features/benefits for an MVP or Pilot?

Minimum Viable Product (MVP) has become a term with many definitions. 280 Group’s definition of MVP is the smallest and most tightly defined product that will generate initial sales, and allow you to gather customer feedback to inform the next version of the product. To prioritize the requirements of your MVP, you must clearly identify your first target market segment (usually early adopters), define the most important problem(s) (not every problem) that you can solve to motivate them to use it, and clearly define what you want to learn from the MVP. These considerations will put you on the right path to prioritizing for your MVP.

Here is a recent article on the Marketing MVP, which ultimately drives the Product MVP.

What do you think about “zero bug strategies” where you don’t deliver a product with known bugs. That also means that you can’t place a fixed limit on engineers working on the “bug” workstream.

Here are the key reasons to consider a zero-bug strategy:

• The longer bugs sit in the bug backlog, the more they cost to fix
• Bugs create technical debt that decreases productivity as developers work on new features
• Bugs get in the way of evolving your product architecture to support your product strategy
• Bugs cause customer dissatisfaction and, if serious enough, reduce customer loyalty and increase customer support costs

If you take on the strategy of zero bugs, do not expect to reach zero bugs immediately. You should allocate a bug reduction workstream that may take a number of months until you reach your zero target.

Once you reach your zero target, you must continue to enforce that strategy by being ruthless about adhering to your Definition of Done. At this point, you won’t have to allocate a bug workstream as bugs are being fixed as found and your sprint velocity for new feature development will reflect the fact that bugs are being fixed within the standard development sprints.

The trade-off here is that with a “zero bug strategy” your time to market both for the first release and subsequent releases will likely be slower. You’re trading off time-to-market for quality, which is always going to be difficult to reconcile. I suggest considering the quality expectations of your target market to inform you on whether this is a good approach for you to take.

Is there a way to validate if your hypothesis has really worked out post product launch? Any recommendations on measuring the actual Reach?

In digital products, you can and should measure the actual Reach of the feature or capability. This is done by embedding the appropriate analytics into the product and tracking Reach metrics. In non-digital products, you can measure the approximate Reach on a more qualitative basis via Voice-of-the-Customer techniques, like surveys. You might be able to infer Reach based upon increased sales (or other business metrics), though there are so many other variables that influence business metrics, that it is difficult to confirm a cause-effect relationship.

Any tips on how to strongly defend the choice to have multiple workstreams and not just one bugs stream?

To me, the idea of workstreams defined for different types of work on the same product reduces the tension and time to debate priorities. So much time can be wasted and so much ill will created when you have different stakeholders fighting for their priorities every development cycle or sprint. By defining workstreams of different types of work and allocating percentages of resources to them, that prioritization is debated only on occasion and it’s much less time consuming to prioritize within each workstream. Also, don’t assume this means adding more resources to support multiple workstreams. It’s more about a clear strategy for allocating resources.

Stakeholders

How do you recommend overcoming objections from an executive team that doesn’t see the value in taking the time to objectively prioritize?

The key points I would make are about team productivity and the ability to better focus product development work on business results. Without an objective approach to prioritization, you can bog down your team and executives in endless debates based upon opinions, which kills team productivity and morale. Without an objective approach to prioritization, how do you know that you are impacting the business results that matter most to your organization?

If these arguments don’t work on a company-wide basis, try to convince your executives to let you pilot an objective approach on one product, then measure the results and compare them to how well other products are achieving their product goals.

When using the $100 buying technique, if you ask several stakeholders, how do you determine the final order? Is it which ones people assigned the most total dollars to?

Yes, that’s right. The final order will be based upon the sum of the values assigned to each requirement by the stakeholders. It’s helpful to use some objective criteria as to how much money each stakeholder receives from the $100 fund. For example, if you’re using this technique to get input from Sales, you could give each Sales leader a share of the $100 proportionate to their revenue forecast for next year.

How do you manage a Roadmap effectively which is dependent on third parties/external vendors by a factor of more than 50%?

I’m going to assume the question is about a third party that develops and commercializes a product that you are integrating or embedding into your product. In a situation like this, your ability to influence their roadmap is highly dependent on how important of a customer you are to them. If you represent a strong percentage of their revenue relative to other customers, then you can have significant influence on their product roadmap. If you are another fish in a big pond, you are dependent upon their reliability in delivering against their roadmap and being subject to the influence of their larger customers.

In the process of selecting a third party vendor, you should carefully evaluate the alignment of their vision and strategy against your own vision and strategy. Think too about how much influence you will have on their roadmap, via direct contact with their product management team and participation in their customer councils.

If you’re not getting the results you need with your current vendors, make it clear to them that you’re considering changing them out, and see if they step up their service in response.

Metrics

I hear this a lot – outcome vs output. Is outcome essentially metrics/OKR’s?

The simple answer is yes. There are both business metrics and product metrics that a Product Manager should track and take initiatives to improve. The product metrics are those metrics that your product decisions visibly and directly impact with the expectation that improvement in product metrics will also positively improve the business outcomes that your management team cares most about. The key is identifying your key business drivers and selecting the metrics that align to those drivers. For a more detailed exploration of this topic, check out the book by Josh Seiden, Outcomes Over Output.

Value

I think one of the biggest challenges is when product teams are determining the value themselves. Do you have good examples of products/orgs that actually involve customers in this “Value” score?

I do know of several companies that post all enhancement requests on a customer portal and allow the customers to vote on enhancements. I have also used customer councils to help prioritize product enhancements. Many companies conduct experiments with A/B testing or Beta trials to watch what customers really want rather than just hear about what customers want. And more recently, a number of services from companies like Pendo and Apptentive allow you to both measure and ask customers about what matters most to them.

As in any customer-driven activity, the most vocal customers’ wishes can get prioritized over what the majority of customers really need. And remember that while your customers’ input is invaluable, they do not ultimately own your product strategy, and may prioritize things differently than your product strategy. This is the fun (and challenge) of being a Product Manager – being able to listen to customer inputs to help determine value, but also considering other dimensions of value to come up with the overall view of what’s most important.

(Road)map it Out

Although, roadmap prioritization is one of the hardest jobs for a Product Manager, there are multiple approaches you can take to identify priorities. We hope some of the tips above can help you gain buy-in on your proposed prioritization from the many stakeholders you must consider. Our key principles of the roadmap prioritization process will help you face the task with confidence. Still need help? Jot down your question in the comments below.

Watch the Webinar On-Demand

WATCH NOW

About the Author

Tom Evans is a Principal Consultant and Trainer at 280 Group.
Tom Evans is a Senior Principal Consultant and Trainer at 280 Group and is an internationally recognized authority in product management, product marketing, international business, go-to-market strategies, business partnerships, and entrepreneurship. In his extensive experience, he has helped start-ups through Fortune 500 companies create and launch winning products and has led business development efforts in the US and global markets. Tom has been responsible for successfully developing and implementing Product Management & Product Marketing methodologies at multiple companies.

280 Group is the world’s leading Product Management training and consulting firm. We help companies and individuals do GREAT Product Management and Product Marketing using our Optimal Product Process.

The post Product Roadmap Prioritization — You Asked, We Answered appeared first on 280 Group.

Source: 280 Group https://280group.com/product-management-blog/product-roadmap-prioritization-you-asked-we-answered/