RSVP FOR FREE | How Carpe Data Supercharges Roadmap Planning to Deliver Outcomes | Oct 3 @ 9 AM PT

Register

Tag: prioritization

4 Lessons Chief Product Officers Can Learn From Top-Performing CEOs About Resource Allocation

Posted on by Bill Cushard

Executive Summary

While simultaneously reading the book, CEO Excellence: The Six Mindsets That Distinguish the Best Leaders from the Rest, and watching each of Dragonboat’s CPO Series webinars, I made a few valuable connections between how top-performing CEOs handle company resource allocation decisions and what Chief Product Officers (CPO), or any CxO, can learn from these connections. 

CEO Excellence, written by McKinsey & Company veterans, Carolyn Dewar, Scott Keller, and Vikram Malhotra lays out six mindsets that top-performing CEOs possess that other CEOs do not. In this blog post, I intend to focus on one of the six mindsets. This mindset is equally applicable to a Chief Product Officer as it is to a CEO: the direction-setting mindset. After all, one of the core responsibilities of a Chief Product Officer is to set the direction for the company’s portfolio of products. And there is no better way to communicate the direction of a company or a portfolio of products than by communicating where resources will be allocated. High-performing CEOs know this.

Resource Allocation Puts the Money Where the Mouth is

Resource allocation is a direction-setting mindset that influences the entire company. This is because it is an act of putting the “money” where the “mouth” is. Doing so communicates three things to the organization:

  1. Where the company is headed
  2. What the priorities are
  3. What decisions the teams should make based on the priorities

For example, when a CEO says that the number one priority of the company is to expand into the EU, then hires a country executive to lead it, sets up a physical presence in a major EU city, and leads every company meeting with an EU progress update, people know what the priority is. They also understand what decisions to make in their areas. However, when a CEO says that new product development is a top priority, but does not add significant resources to R&D, people quickly see the lack of commitment. And as result, they might make decisions in their areas accordingly.

They lose confidence in the CEO.

In this article, I describe what I learned from how top-performing CEOs allocate resources, and what CPOs can learn from it too.

Lesson #1: Start with a Zero Base

In the resource allocation practice, the guiding principle is to act like an outsider. There is no better story to explain this idea than Andy Grove and Gordon Moore discussing the future of Intel, which was focusing on core products (memory chips) in a declining market. They asked themselves, “If we were kicked out of the company, what do you think the new CEO would do?”

That question gave Grove and Moore the freedom to answer, “We’d get out of the memory chip business immediately and shift to making microprocessors.”

The rest is history.

You and I might not be the co-founders of Intel, but we do have an opportunity at each planning cycle to ask ourselves a similar question.

So, why don’t we? 

Most traditional planning cycles start with last year’s budget and/or plan. From that baseline, we make decisions about what to add. As described in CEO Excellence, “[Annual planning] starts with last year’s budget or some other form of historical baseline (the ‘anchor’). We anchor ourselves to the past. This makes it difficult to break free and explore the question, “What would we do today if we started from scratch?” 

Top-performing CEOs start with a zero base. Instead of anchoring themselves to last year’s plan, “no investment is taken as a given – every investment is scrutinized, alternatives explored, and approval justified by how it helps deliver against the company’s strategy and vision.”

The mindset is the same as Grove and Moore: If we started from scratch, what would we do?

Lesson for the Chief Product Officer:

What if the Chief Product Officer brings her team together for annual planning and says, “Let’s start from scratch? It doesn’t matter if we are halfway through this 18-month data lake project. It doesn’t matter if we’ve already spent $800K building our own CDN. The mindset I’d like for today’s planning workshop is this, ‘With our current company goals in mind, what do we think we should do next?”

This doesn’t mean the team should actually scrap all current projects. It just gives the team the space to open up and innovate without being anchored to existing decisions. From a zero base, the product team can create a plan with innovation in mind.

Like top-performing CEOs, Chief Product Officers should set the stage with the team for starting with a zero base.

Lesson #2: Solve for the Whole

We are all out there advocating for our functions, making the case for the budgets, headcount, and technology we need to do the work we think is necessary. Everyone cannot get everything they want. It’s not possible. Or practical. Yet, as functional leaders, we create plans and request budgets for our functional areas. 

Great CEOs are aware of this dynamic. They will work to bring the team together during planning sessions with the goal of solving for the whole. There is an excellent story in CEO Excellence in which Lockheed Martin CEO, Marillyn Hewson, is quoted:

“We’re going to look at your investment plan from top to bottom. We’re going to put all the plans together, and we’re going to shave off the stuff at the bottom and we’re going to double down on the things that we all collectively know we need to go after as a corporation. And it may mean somebody gives something up over here. Or it may mean that somebody takes the lead over there. But if we don’t do that collectively as leaders of the corporation, as leaders of Lockheed Martin – not just leaders of Aeronautics, or Space, or Mission Systems – then we’re not going to be as strong as we can be as One Lockheed Martin.”

Marillyn Hewson, Lockheed Martin CEO

Why can’t Chief Product Officers do the same?

Lesson for Chief Product Officers:

In the next planning meeting with all of the product managers in the room take what Marillyn Hewson said to her team, and modify it:

“We are going to look at each of your roadmaps and resource estimates from top to bottom. We’re going to put all the roadmaps together, look at the entire product portfolio, shave off stuff at the bottom, double down on things we all know we need to focus on. And it may mean somebody gives something up over here. Or it may mean that somebody takes the lead over there. But if we don’t do that collectively as product leaders in this company – not just leaders of Platform, or Mobile, or eCommerce – then we’re not going to be as strong as we can be as one company.”

Marillyn Hewson, Lockheed Martin CEO

I’d love to be in that meeting. Even if my product area got deprioritized.

Lesson #3: Manage by Milestones (Not Annual Budgets)

Remember the reason why organizations create plans and budgets: to achieve stated goals or milestones. The trap that many of us fall into is thinking that we have to stick to our budgets and plans. Top performing CEOs don’t put this constraint on us. We put it on ourselves.

In CEO Excellence, Jamie Dimon, CEO of JPMorgan Chase confesses, “I get so frustrated with business leaders who say they didn’t make an investment because it wasn’t in their budget. You have to say, ‘I want to do X. I want to add branches, I want to go to the cloud. I need to be competitive.’ You want to spend $500 million? Recommend it. Show me why.”

CEOs like this don’t let annual budget cycles get in the way of pursuing goals and furthering the company’s mission. The best CEOs use performance milestones (revenue, costs, market share, etc.) to make capital reallocation decisions.

Lesson for Chief Product Officers:

Chief Product Officers should use performance milestones to make resource allocation (and re-allocation) decisions. 

CPOs should set target allocations for each company objective based on priorities, so the product team can plan accordingly. As results come in and/or events change, the team may need to adjust. The Chief Product Officer needs to create an environment in which the product team can come to her and say, “What we are doing is not working. If we are going to achieve these two milestones, we need to try something new and move resources to do it.” The CPO cannot let the plan get in the way of pursuing goals. 

Lesson #4: Kill as Much as you Create

Each of the first three lessons describes high-level resource allocation strategies: start with zero bases, solve for the whole, and manage by milestones. As described in CEO Excellence, real allocation decisions involve more specific activities:

  1. Seeding: Entering new business areas
  2. Nurturing: Building up an existing business
  3. Pruning: Reduce resources in existing business
  4. Harvesting: Selling or spinning off whole businesses that no longer fit the company portfolio

The authors of CEO Excellence found that there is no difference in CEO performance between those that enter into new business areas (seed) and those who exit existing businesses (harvest). These are actually simple (not easy) decisions. The big difference is that the best CEOs spend nearly 3x the effort in nurturing and pruning their businesses in comparison to the rest of the CEOs. You might say, non top-performing CEOs allow existing businesses that are relatively successful to coast. Whereas, in contrast, top-performing CEOs focus on continuous improvement.

Lesson for Chief Product Officers:

Chief Product Officers should focus much more of their allocation activities on existing product functionality. There are times when resources should be added to OR removed from products and features that are performing well. There are also times when CPOs should add to OR remove from products and features that are underperforming. These continuous planning decisions between nurturing and pruning are the real tough decisions and the ones CPOs should learn from high-performing CEOs.

CPOs are CxOs first

During the Dragonboat CPO Series webinar, Trisha Price, CPO at Pendo, said she considers herself a CxO first, a CPO second. In another webinar in the series, Shelley Perry, managing director at Scalelogix Ventures and board director, told us that when CPOs deliver their section of a board pack, it should be delivered as part of the larger company performance narrative, not as a product update.

Of course, I thought. Why didn’t I think of that?

In order to succeed in the C-suite, Chief Product Officers need to stop thinking of themselves as product leaders. And instead think of themselves as CxO, who allocate resources to grow the company as a whole. 

Responsive Product Portfolio Management

The first two steps in the Responsive Product Portfolio Management (Responsive PPM) product operating system are 1) setting goals; and 2) setting resource allocation targets. Goals set the stage for what a company wants to accomplish. Resource allocation targets are an expression of how the company will accomplish those goals. At the Chief Product Officer level, allocating resources means setting targets for how the product team will estimate and assign resources to each of their respective roadmaps. Chief Product Officers and product operations teams can then look at the entire portfolio and make allocation decisions with the team to solve for the whole. 

To learn more about the Responsive Product Portfolio Management (Responsive PPM) product operating system, visit our certification site and join our community. Or talk to us. 

CPO Series Banner

4 Product Prioritization Frameworks & How To Use Them

Posted on by Kalei White

Due to limited time and resources, every product manager must make difficult trade-off decisions when prioritizing their roadmap. Inspiration for new product features may come from a myriad of sources, and as the list grows, it becomes increasingly challenging to separate the best ideas from the rest. Fortunately, several product prioritization frameworks enable product managers to create customer love and achieve the best business outcomes. 

In this article, we’ll focus on the RICE, MoAR, MoSCow, and Kano frameworks with examples of how to use each. But first, let’s ensure we are speaking the same language.

What is a Product Prioritization Framework, and Why Do You Need One?

A product prioritization framework is a methodology for deciding which product additions and enhancements to tackle, given your goals and constraints. 

Product management prioritization is incredibly challenging because you have multiple stakeholders, and the list of potential projects is endless. The customer comes first, but you must balance requests against your overall product strategy and vision without sacrificing business outcomes. In other words, you want to work on products and features that truly matter to the customers and your business. 

So the great thing about choosing a framework is that it allows you to rise above the noise and make sensible, data-driven decisions based on what will deliver the most value.

There is no “right” product feature prioritization framework. The appropriate one for you depends on your business. The important thing is to find a method your team can align to so you can make confident decisions. So without further ado, let’s dig in. 

The RICE Model

The RICE framework is a simple prioritization model created by the team at Intercom that many product teams have since adopted. It’s calculated as (Reach x Impact x Confidence) / Effort. 

When you prioritize your roadmap with RICE, the key is consistency across the portfolio or against goals.

Let’s break down the different components of the RICE prioritization model:

1. Reach

“Reach” denotes how many people you believe your initiative will touch within a given timeframe of your choice. 

When choosing the Reach value, teams may use the absolute value of x number of customers or a score range between 1-100. We recommend using 1-100.

2. Impact

“Impact” represents a goal to be achieved by this initiative. Initiatives can be anything, including something quantitative, like conversions, or qualitative, like customer satisfaction. 

When choosing the Impact score, use 0-3 to denote the amount. That will represent no, low, medium, and high impacts.

3. Confidence

“Confidence” is chosen based on the assumptions of the idea. It demonstrates whether or not you believe it will deliver on the Reach and Impact. For instance, if you have data to support the Reach score you predicted but no data to support the Impact score, you can reflect this in your Confidence score.

A Confidence score ranges from 1% to 100%. A good practice is to break it down into 50%, 80%, and 100% to represent low, medium, and high confidence. That way, you do not have to spend too much time deciding on a Confidence score.

4. Effort

When you prioritize your roadmap, there will be costs and benefits. As the numerator of the RICE model, “Reach,” “Impact,” and “Confidence” create an idea of your benefits. As the denominator of the RICE model, “Effort” creates an idea of your costs.

“Effort” is often measured in “person-months,” or the number of months it will take one person to complete the task. So if a project will take 1-2 weeks of planning and 2-3 weeks of engineering, we can score it in 2 person-months. This estimate will likely be imprecise, but we recommend keeping the numbers whole for ease of use.

Now Let’s Take a Look at an Example:

If Project 1 has Reach = 50, Impact = 3, Confidence = 80%, and Effort = 12, then the RICE score is 10:

(Reach x Impact x Confidence) / Effort

(50 * 3 * 80%) / 12 = 10

An example of using the RICE product prioritization framework in Dragonboat.
Applying the Rice Model using Dragonboat’s Product Portfolio Management platform

The MoAR Model

The “MoAR” model stands for “Metrics over Available Resources.” Among the different product prioritization frameworks, this one is unique to responsive product portfolio management, replacing the traditional ROI model. 

When you prioritize your roadmap with MoAR, you can directly map to company goals and strategies while also accounting for any urgent resourcing needs.

Let’s Take a Closer Look at What MoAR Means:

What you choose for “Metrics” can vary based on the initiative. Popular “Metrics” are often measures of product benefits such as user growth, referral rate, retention, or net promoter score. These are good ways to gauge future monetary returns, and if your company has adopted goal frameworks like OKRs, you can align these goals with your roadmapping.

“Over Available Resources” refers to the number of resources readily available or the effort needed. Put differently; it considers scarcity. Therefore, you can adjust as needed. 

How to Calculate MoAR

MoAR is calculated as MoAR = Benefit / Effort.

1. Benefit

In this case, “Benefit” demonstrates how much a given initiative contributes towards your organization’s strategic objectives. When using MoAR correctly, these initiatives will be mapped to an objective. Therefore, the Benefit score will prioritize all ideas mapped to that same objective.

When choosing a “Benefit” score, we recommend using a value between 1% to 100%.

2. Effort

Similar to “Effort” in the RICE model, here it refers to an initiative’s cost in terms of resources. Effort is most commonly determined by the estimated weeks needed to complete an initiative by the resource chosen.

Now, Let’s Take a Look at an Example:

Let’s say you are trying to prioritize several features toward a specific goal.

Feature A is expected to contribute 40% of your goal and requires eight weeks of front-end resources. The MoAR for Feature A is 40/8 = 5. 

Feature B is expected to contribute 10% of your goal and requires four weeks of front-end resources. The MoAR for Feature B is 10/4 = 2.5.

Feature C is expected to contribute 20% of your goal and requires five weeks of front-end resources. The MoAR for Feature C is 20/5=4.

You would then compare and prioritize features based on your MoAR scores. 

Feature A > Feature C > Feature B. Therefore, you would cut Feature B even though it takes the least resources. You can then address that Features A and C only make up 60% of your goal by reducing the target by 40% or choosing a new feature to cover the gap.

When you prioritize your roadmap with the MoAR framework, you can be responsive and proactive in addressing gaps. 

An example of using the MoAR product prioritization framework in Dragonboat.
Applying the MoAR Model Using Dragonboat’s Product Portfolio Management Platform

Recommended for you: Effective Feature Prioritization with Product Portfolio Management

The MoSCoW Model

The MoSCoW model is another way to prioritize your roadmap, which primarily focuses on ranking the importance of requirements. Created by Dai Clegg at Oracle, MoSCoW is an acronym for four categories: “Must-Have,” “Should-Have,” Could-Have,” and “Won’t-Have” (at least not in the short term) or alternatively, “Wish-to-Have.” 

To use the framework, it’s first important to be clear on the team’s objectives and factors for prioritization. You will need to devise a way to settle any disputes you may have about which category is best for each feature or initiative. 

Let’s Look Closer at the Four MoSCoW Categories:

Must-Have: These are the product needs that the team absolutely must work on since they are critical to the product’s success. 

Should-Have: These initiatives are not critical but would provide significant business and customer value. 

Could-Have: Once the “Must-Haves” and “Should-Haves” are taken care of, these are the initiatives to prioritize next. They would add value but aren’t absolutely needed.

Won’t-Have: These are the initiatives that the team excludes from the prioritization process. Including items in this category helps to prevent scope creep and keep the team focused. 

Let’s say a team is working on an MVP for a new social media app with a very limited budget and timeline. Here is an example of how it might prioritize its proposed list of features:

Example of prioritizing product features using the MoSCoW method.
Applying the MoSCoW Model Using Dragonboat’s Product Portfolio Management Platform

Any team can apply the MoSCoW model. For example, the QA team could use it to decide which test cases to prioritize in the next sprint. However, there are some potential drawbacks to just using MoSCoW for product prioritization. For instance, it might be susceptible to bias, and scoring could be imprecise due to a lack of the proper inputs to make the right decisions.

The Kano Model

Where the MoSCoW model focuses on the degree to which features are necessary, Kano is one of the product prioritization frameworks emphasizing features that maximize customer satisfaction and delight while weighing their costs. It argues that more is not always better. It also recognizes that some features might even lead to negative customer outcomes. On the other hand, it points out that, over time, features that were once considered a “nice-to-have” become a given.

You can use the Kano model to categorize features based on their predicted customer reaction. For best results, make sure to do some customer research ahead of time in order to bring data to the decision-making process. 

Categories in Kano 

Excitement: Features in this category contribute to the “wow” factor for customers. Using a hotel as an example, excitement features could include offering guests complimentary tours and transportation.

Performance: Also known as “satisfiers,” these are features customers notice and appreciate. Returning to the hotel example, offering free beverages in the room is an added benefit but not necessarily expected. 

Basic: These are the features that your product needs in order to be competitive, yet are so fundamental that customers wouldn’t think to request them. For example, hotel guests would expect to receive a room that has a bed with clean sheets. However, if a hotel fails to provide this feature, it will soon be out of business! 

Indifferent: These are the features that most customers would not have a strong preference for or against. In a hotel, this might be having stairwells in addition to elevators. While most customers might be satisfied with just using the elevator, the hotel owner needs to make sure to have adequate stairwell access in order to comply with fire safety standards. 

Dissatisfaction: These features, if implemented, would cause customers to be less satisfied with the product. For example, a hotel with has a clock tower, while perhaps architecturally pleasing, might wake customers at night and worsen their experience. 

To put this model into practice, first, formulate a simple customer questionnaire that consists of two basic questions regarding each feature:

  1. How would you feel if the product had X feature?
  2. How would you feel if the product lacked X feature?

For the answer options, you can use a Likert scale with five responses (indicating the strength of the respondent’s opinion) that correspond to each question. Based on the answers, you should be able to arrange the feature ideas into the different categories of customer delight.

Product Prioritization Frameworks for Better Decisions

There are other prioritization and product management frameworks using methods like weighted scoring, opportunity scoring, or even user story mapping. And creative options even incorporate the cost of delay or a game-like method where you “buy a feature.” But the four options above should be plenty to get you started on prioritizing your product roadmap. 

For outcome-driven teams, we recommend starting with MoAR since it directly addresses how to prioritize your roadmap by objectives. 

Remember that for every ideal way, there is an equally wrong way to prioritize your product development plans. For instance, is everyone’s opinion heard, or is it only the most vocal team members? Is data involved, or are you working off a hunch? So, be sure to evaluate how your team is making decisions today and be honest if things need to change.

To see how we use product prioritization frameworks in Dragonboat, sign up for a demo today. 

Effective Feature Prioritization with Product Portfolio Management

Posted on by Becky Flint

A product manager recently posted on a community group that she is looking to change her career as she feels exhausted from constant fire fighting in managing competing priorities and stakeholder demands. When I recommended Dragonboat, she was puzzled: “But we only have one product. Isn’t portfolio management only for large companies with many product lines?”

Not necessarily! According to Investopedia portfolio management boils down to three things:

  1. Determining strengths, weaknesses, opportunities, and threats in the current market
  2. Selecting investments and allocate appropriately to a set of parameters
  3. Rebalancing periodically

You can see that it is not so much about managing the size of your portfolio, but managing your choices. This is not too different from what a product manager does — you are constantly thinking about the product investment mix to maximize your desired outcomes.

This is exactly what responsive portfolio management is. Applying portfolio management principles, allows us to reframe how we think about product roadmaps. Every product, even if it is the only one in the company, is essentially a multi-dimensional portfolio of priorities and demands.

A Product Manager’s Portfolio

Like the finance industry, we often use SWOT analysis (strengths, weaknesses, opportunities, and threats) to chart our market and product plans. 

However, that is where the comparison ends. While financial advisors work with clear monetary values — such as profit, revenue, or market share — product managers have a wider set of variables and a broader definition of “the best outcome”.

That means we can derive multiple types of portfolios depending on how we view the roadmap. For some broad examples:

  • Objectives
    These can be long- or short-term objectives such as acquiring or retaining customers, reducing operational costs, or expanding into new markets.
  • Customer Segments
    New, existing, enterprise, or partners.
  • Investment Categories
    Such as deciding between product innovation and tech platform refactoring.
  • Stakeholder Needs
    Both internal and external such as customer feature requests, realigning the product for the market, or addressing tech upgrades and debts.

Why Would You Want a Multi-Dimensional View?

A multi-dimensional view lets you:

  1. Address multiple elements of “product success”; and
  2. Make the right allocation decisions faster (i.e. focus vs. support).

Imagine you have a new product. The sign-up numbers look good but, after a week, these users stop coming back. As a result, the team must shift their focus on how to improve retention. Once that is under control, you can shift back to user acquisition, efficiency improvements, and so on.

Many conventional prioritization frameworks are based on a fixed formula such as scores or ROI, and do not reflect the changing needs of the customer or market.  Over time, it may lead you into a “peanut butter” situation where the product simply fails from the company’s resources being spread too thin.

By looking at it from a portfolio perspective, product managers are empowered to understand the current state of the product and market to decide on a responsive prioritization method for identifying areas that truly need your limited resources.

Think of it as trying to fight a forest fire — you look at it from the ground and the top, analyze the situation, and then prioritize, allocate, and deploy. That is what it takes to be a forward-thinking product leader. 

Responsive PPM CTA

We Need A Portfolio Program Manager Not Just Scrum Masters

Posted on by Becky Flint

A dedicated scrum master is essential for new Agile teams. They are the glue that holds everyone together, ensuring that members adhere to best practices and agreed processes. Much like glue, it will take some time to set. Once everyone understands the makings of a good scrum – from planning to tracking – they are on their way to becoming a well-oiled, self-organizing team.

At this point, the scrum master will no longer require a full-time role because everything works for the most part. So now what? Now, is the time for an up-leveling because

Enabling an Agile engineering team is just the start of an Agile company.

Agile execution via scrum helps build quickly and iteratively. However, it does not automatically enable higher-level alignment of our strategies towards our goals (OKRs). Additionally, it does not enable cross-team cross roadmap collaboration to build synergies or iron out dependencies.

To unlock greater agility, companies need to also practice responsive portfolio program management. Responsive PPM dynamically connects objectives, initiatives, and resources with Agile execution. It also calls for people with the right skills to help move the organization forward.

The Responsive Version of Program and Portfolio Management

Traditional program management focuses on large, cross-functional, and complex programs with many projects. Moreover, the traditional portfolio management focuses on planning, budgeting, and tracking a suite of programs. Both are mostly practiced in large organizations with complex structures.

In small to mid-sized companies, your entire product roadmap is a portfolio.

Many fast-moving companies today may have only a few, if any, large programs. However, they usually have many smaller moving pieces carried out by one or more agile teams. As the agile teams are continuously iterating on product enhancements, there is a missing “glue” to connect them together. This is a recipe for chaos. Promised features go undelivered, support teams are left in the dark, and everyone is sending urgent feature requests filling up the roadmap pipeline.

Solving this takes portfolio management skills.

What Portfolio Program Managers Do

In a nutshell, portfolio program managers ensure the best-desired outcome for an organization over a relevant time period, within the constraints of resources. Scrum master leads scrum cadences while portfolio program managers lead quarterly (or month/ bi-monthly) portfolio roadmap cadence. Their duties can be summed into three key areas:

  1. Quarterly Strategic Planning for Portfolio Allocation
  2. Roadmap Delivery and Trade-Off
  3. Progress Communication

A portfolio program manager works with key stakeholders to create a clear and holistic process for defining priorities responsive to the time-frame. They also lead trade-off discussions between the product areas or teams using portfolio principles to allocate the right resources towards various objectives and initiatives.

Lastly, after deciding the product features and initiatives to undertake, they transition delivery to the agile teams knowing the key-elements of the plan are in place for the team to execute.

Then they track the progress and outcomes, and keep the stakeholders informed.

When changes inevitably happen – for example, when a new high priority feature request comes to the team – portfolio program managers lead roadmap trade-off discussions to minimize the impact on in-flight features while still accommodating new requests in a way that best achieves the company’s desired goals.

In Responsive PPM, We Believe All Factors Are Dynamic

This is precisely where a portfolio program manager comes in to connect the moving pieces in a holistic and dynamic way.

This transition from being a scrum master to a portfolio program manager represents both professional growth for the individual and also a strategically impactful role to every organization.

Responsive PPM

Forget ROI, Use MoAR for Product Portfolio Metrics

Posted on by Becky Flint

Nearly every department has a KPI to measure short-term success. But what about your product team? What one metric measures product’s effectiveness and impact? Return on Investment (ROI) measures monetary value, but there is more to effective product portfolio management than ROI. So, instead, we recommend using Metrics Over Available Resources (MoAR) to directly evaluate opportunities to maximize your product investment and business outcomes.

The Shift From ROI

Portfolio Management is a finance concept that refers to allocating investments across different asset classes (based on the assumed risk and reward) to optimize the overall outcome. Product Portfolio Management (PPM) applies that same approach to your organization, allocating scarce resources to the work that yields the most value.

Years ago, I led strategic planning for PayPal’s product portfolios. We needed to evaluate opportunities that could help the company achieve specific objectives, such as improving engagement, launching into a new market, reducing transaction costs, and taking risks on emerging trends. 

How could we compare these diverse product initiatives across revenue growth, cost reduction, and risky innovation?

We tried using ROI but quickly ran into limitations. It was nearly impossible to clearly and consistently tie initiatives to specific outcomes. We needed a solution to measure and evaluate opportunities more directly than ROI. That led us to develop a new approach – MoAR, or Metrics Over Available Resources.

The Trouble With ROI

Return on Investment (ROI) is a ratio between net profit (over a period) and the investment cost. It is a performance measure often used to evaluate or compare the efficiency of different investments.

ROI works well in traditional industries or functions where benefits and scarce resources can easily be measured in money. But ROI becomes elusive when you need to measure outcomes that are not clearly associated with money or have other forms of scarce resources.

Smart Roadmap Planning with Dragonboat MoAR
Replace ROI with MoAR – plan your portfolio roadmap the modern way

Product Portfolio Metrics: Measuring Benefits

In the world of manufactured goods, measuring a product’s financial impact is relatively straightforward. For instance, we can easily track how much revenue a newly designed cup generates in 1 year and compare that to the costs to calculate its 1-year ROI.

In contrast, a software product consists of many features. We can infer the monetary benefit of a proposed new feature by estimating its relative contribution to a business metric. But it is nearly impossible to directly measure and attribute the financial outcome of individual product features. 

An Example

Imagine that you are a SaaS provider. Based on experience, you know that increasing sign-up conversions by 5% will result in $100k in quarterly profit if everything else remains unchanged. Feature A aims to increase sign-ups by 2%, so we can infer that launching this feature will result in a $40k bump in profit.

However, although we can measure the change in profit, we cannot attribute the change to a given feature unless we do nothing else to affect sign-up conversions during that time. That isn’t a reasonable expectation for an agile company.

Other complicating factors include the following:

  • Monetary-based benefit measures have a negative bias against innovation and risk-taking. Investing in a cash-cow mature business always generates a higher ROI than developing products, at least initially.
  • Money isn’t the only scarce resource. Sometimes the most limited resource is human capital. If you need software engineers with highly specialized (and in-demand) skills to build the product and achieve your growth metrics, you must factor that into your thought process 

So, What are Metrics Over Available Resources (MoAR)?

Metrics Over Available Resources (“MoAR”) is the ratio of the expected contribution of a product feature towards a measurable business outcome over the number of resources needed to achieve that contribution.

MoAR provides a more direct and holistic measure for portfolio planning and a clearer visual of product portfolio metrics than ROI. Let’s look at MoAR in action to show you what I mean.

Using MoAR for Product Planning

To use MoAR, start with defining the appropriate metrics to measure benefits towards the desired business outcomes or objectives.

  • Metrics such as user growth, referral rate, retention, and Net Promoter Score (NPS), are the direct measure of product benefits. And they are often leading indicators of monetary-based returns. Furthermore, companies that adopt an OKR or V2MOM framework can easily connect outcome targets with product portfolio roadmapping. MoAR enables an outcome-driven portfolio roadmap.
  • Available Resources indicate scarce resources, like Scala Engineers or the UX designer who designed your last app.

During portfolio roadmap planning, compare features that require the same resources using MoAR to prioritize. Then add up the contribution of all planned features toward the goal. The total contribution should be 100% or higher to ensure the goal is achievable based on the current plan. Anything less indicates an outcome or resource gap. 

For example, assume a key business goal for the next quarter is to increase conversion by 10%. Three features are coming to the team, and only 16 weeks of front-end resources are available.

  • Feature A is expected to contribute 40% of this goal and requires eight weeks of front-end resources. The MoAR for Feature A is 40/8 = 5.
  • Feature B may add 20% of this goal and requires eight weeks of front-end resources. The MoAR for Feature B is 20/8 = 2.5.
  • Feature C contributes to a cost-saving metric but not towards the conversion goal. And it requires four weeks of front-end resources. Thus, the MoAR for Feature C is 0.

Using MoAR to Prioritize Conversion-Boosting Features

 Feature AFeature BFeature CTotal
Contribution (%)4020060
Resource needed
(in weeks)		88420
MoAR52.50/

Let’s evaluate these features.

First, the total resource requirement is 20 weeks. We only have 16 weeks available, so we have a shortage of front-end resources to support these three features. We will de-prioritize Feature C as its MoAR is 0.

However, this plan is not ready to go yet because there is an outcome gap – Features A and B will contribute to only 60% of the target metric, so we will not achieve the desired outcome. 

The team needs to either reduce the target outcome by 40% and get stakeholder buy-in or start over to design a different feature set to achieve 100% of the target.

Although this is not what the team hoped to see, the information is vital. Identifying gaps during the planning phase gives the team time to address them before it’s too late.

Metrics Over Available Resources: Key Takeaways

The Metrics over Available Resources (“MoAR”) prioritization method allows companies to readily incorporate a direct measure against goals into their roadmap planning and dynamic alignment process. That enables better product decisions, easily visualized product portfolio metrics, and improved overall outcomes.

MoAR is a key element of Responsive PPM – the new portfolio management approach for outcome-driven organizations. Book a demo today to see MoAR in action.

Responsive PPM CTA
RESOURCES
SOLUTIONS
COMPANY
READY TO GET ROWING?
Subscribe to our newsletter
Twitter Facebook-f Medium Linkedin Youtube
dragonboat logo
AICPA-Logo
Dragonboat Inc. is SOC 2 Type 2 Certified
ani-logo

This site uses cookies. Some of these cookies are essential, while others help us to improve your experience by providing insights into how the site is being used. For more information, please check our Privacy Policy. You can disable or remove cookies in your browser settings at any time. By clicking "Accept" or continuing to use this site, you consent to our use of cookies across the site.

Accept