Too Many App Features? Use the 2×2 Matrix to Prioritize

The longest journey starts with a single step. But that long journey becomes much more likely to fail if you don’t have a good handle on your destination, your cargo, or your method of transportation.

This is one of the truths of application projects, whether mobile- or web-based: the first step of your project can put you on the right path, or lead you immediately off-course. To make sure you keep headed in the right direction throughout the project, that first step needs to be this: ensure your project deliverables are aligned with a strong strategic vision, particularly during the early stages of product planning.

That can be easier said than done – in those early stages, organizations can face some common problems. In particular, the following four pitfalls occur frequently:

1. Project teams that have difficulty translating a laundry list of user needs and expectations into distinct application functionality
2. An ideal product vision that includes an overwhelming number of features that upper management, project leaders, or end users want included in the final product but that cannot be introduced given the available resources
3. Budget constraints that impact what features are included, or when (e.g. timelines for grants, or changes to funding/budget allocation year over year)
4. Rushing to get a product to market, while still ensuring that the primary features that are required to solve your users needs are met

The core of the above issues is a shared uncertainty around how to direct limited resources to maximize the value of the product. That uncertainty manifests itself in questions like “What should I build?” and “How do I know which features to include, and which to cut?”

Let’s figure out how we answer those questions.

The 2×2 Matrix

The secret ingredient to go from shared uncertainty to alignment on your web app or mobile app project is by following a proper feature prioritization process. In order to maximize the impact and value of your app, decisions around what to build (and what to cut) are best informed by a decision-making framework that gets everyone on the same page.

For our team, that framework is the 2×2 Matrix, also known as the 2×2 Prioritization Method.

The 2×2 Method is a simple method to plot features (or user stories) on a grid, the axes of which are designed to help you figure out what features to include in your app and which to cut based on their respective Effort and Value. Where your features fall on the 2×2 grid help determine, rationally, whether or not they should be built.

It is most effective when used collaboratively, with discussion and debate. Used effectively the 2×2 Matrix will help you determine which features should be included in your initial product launch, supported by reasoning for how they address the needs of your users.

Before you can start plotting features on the matrix, though, your team needs to come to a consensus regarding the definition for the axes on the matrix: Effort and Value.

Effort vs Value

The 2×2 Method allows us to map user stories on a grid, which provides a visual comparison of the time, energy, and resources required to implement a given feature (Effort) against the return (financial or otherwise) your organization has to gain from it (Value). This may sound simple, but spending the time as a team to define Effort and Value will set you up for success when it comes time to start product development.

Effort

At the core of every individual feature, there is an elasticity at play when it comes to the Effort required to bring it into reality. This push and pull is scarcity, forcing you to decide if there is enough time, person-power, and (most frustratingly) money to deliver everything you’ve promised. However, your team needs to define Effort for your project before we can examine how best to prioritize which resources can be stretched, and which can’t. For most projects, Effort comes down to the interplay between two factors: Cost and Urgency.

Cost

Budgets are probably at the front of your mind right now. From the perspective of application development, cost encompasses everything from person-power on the development and design team, to annual fees and licensing. Prioritizing features based on cost is simultaneously the easiest and most challenging decision because of the immediate impact it can have on the final project.

That being said, it’s important to be objective when examining features based on cost. Some features will seem like obvious go-aheads; revenue-generating additions like advertisements and premium subscriptions are high-value, low-risk inclusions in your application that (if used correctly) will pay for themselves over time. However, even the most innocuous and common features might include hidden costs that could tank your budget. Everything from payment gateways to email integrations can include recurring fees that can quickly add up year-over-year. Make sure you approach features from every possible angle now to reduce the risk of budget constraints while in the throes of development.

Urgency

Which of your features are must haves for launch day? Are there some that can wait for 6 months? How about a year? As much as we wish it were true, app development is not a static process. The most successful apps are constantly monitored and continuously updated based on user input and experiences, in many cases with major feature introductions happening regularly. For every product launched, there will be a host of features that are excluded because they’re supplemental to the app’s primary functionality rather than required for it to operate as intended.

As an example, let’s imagine we’re developing an app that tracks speed and distance for runners using Google Maps. We need to decide if we should include a calorie counter for launch; the app doesn’t require this feature to function as intended, but it potentially improves the user’s experience with the app by introducing a convenience that eliminates the need to use a secondary application. However, a competitor is hard at work on a similar product, and the addition of the new feature would delay our launch by several months. During prioritization, we decide to exclude the calorie counting to ensure the core application functionality is rock-solid first and foremost, while ensuring we keep to our original launch date.

Trying to squeeze in every single feature can potentially spell disaster for even the best laid product plan, leading to delayed timelines or impacting the quality of killer features by diverting resources away from their development. The benefit, of course, is that secondary features that you exclude during project planning can be evaluated against user response and feedback to your application post-launch. This can pay major dividends for future prioritization. We may have thought that users wanted a calorie tracker, but maybe what they really need is integration with a brand new smart watch that blew up after the app’s launch. Now we have the budget and time to fry the bigger fish.

Value

Now that we’ve got Effort out of the way, we can start talking about the fun stuff: examining the Value of each feature to the success of your application. Like with Effort, the criteria for Value is remarkably varied depending on an endless number of factors, from your industry, intended audience, to the needs of your backend content managers and your firm’s 5-year business plan… you name it! We’ve outlined a few key metrics to determine feature value (which we’ve gone through in much more detail in a previous post on translating app metrics to business outcomes), though coming to a consensus as a team on  what metrics you feel are important is crucial at this stage.

User Expectations and Satisfaction

User expectations and satisfaction can create considerable value and differentiation. Another common prioritization method, the Kano Model, is built on a foundation of delighting and exciting customers by including those key features they expect from the app, but then going the extra mile to include features they didn’t even know they wanted – also known as creating value through user experience. This is an important step when examining features you determine to be required for the app to perform as intended. For our running app example, the inclusion of a Geolocated Map that shows the user’s location as they run is a necessary function, but visualizing user location with their profile picture rather than a generic avatar is something that yields excitement and delight. There is value here – is there enough to justify the effort? Meeting and then exceeding user expectations can be what separates the great applications from the rest.

Return on Investment

The most obvious financial value to base feature inclusion on, ROI is the direct line drawn from the cost to implement against the dollar benefit from its inclusion. Not all features are as cut and dry, but if your project is meant to deliver profits, features that generate revenue will be given high priority. Any number of financial metrics can be useful when examining each feature, like Ongoing Costs (e.g. does the inclusion of this feature mean maintenance costs go up for the application) or Total Cost to Implement (some functionality is exponentially more expensive to include than others, like choosing to release a mobile app on both iOS and Android, rather than just one).

Operational Requirements

These are the not-so-exciting, but still equally important features that are must-haves from the perspective of responsible business operation. Some features may not be particularly delightful to users, or provide a huge cost savings benefit, but are still must-haves for a variety of reasons. These could be internal security protocols to lower the risk of exposure to activities of ill intent, legislative privacy requirements (i.e. CASL), and any number of quirky organizational policies your Board is expecting you to meet. That said, it will save you all the headaches in the world if you prioritize the safety of your users over B-tier bells and whistles – so don’t under-value operational requirements.

Now that you’ve come to a consensus as a team on how you’ll define Effort and Value, it’s time to generate a comprehensive feature list for your application that will be whittled down to your ‘must-haves’ for inclusion (the ultimate output of prioritization). Here’s how we do this at Paper Leaf with our clients, using user stories (which can also be thought of as functional requirements, or “features” even).

User Stories

Early into our engagements, we work with clients to examine their application’s invested parties and user groups, from end users to content managers and everyone in-between. Then we compile an exhaustive list of experiences those users expect from the application. This can take the form of in-depth user interviews, or a brainstorming session with the subject matter experts. We distill this examination into what we call User Stories, or the high level requirements that make up the features that the application has. To put this into simpler terms, the stories follow the following format:

As a <user persona> I want <functionality> so that <benefit / rationale>.

Applied to our application example above, a User Story would look something like this: “As a high-performance runner, I want to be able to track my speed in kilometers per hour so that I can benchmark it against my best recorded time.”

You can follow our User Story generation process for your application. Gather your project team, users, and as many other invested parties as you need, and have each participant generate as many user stories as they can, written on sticky notes. Place them off to the side.

Then, go through the pile of user stories one-by-one as a group and determine where each story would fit on the matrix, based on your definitions of Effort vs Value, and place them in the appropriate quadrant.

Remember, the value here lies in the discussion around each user story and where it should be placed on the 2×2 matrix. In the end, you’ll have a 2×2 that looks something like this:

Finalizing Features for Inclusion

At Paper Leaf, prioritization isn’t complete until we’ve determined how the user stories fit into one of three categories: Must Haves, Nice-To-Haves, and Won’t Haves. These categories can be defined as such:

1. Must Haves: user stories that must be included in the final requirements list for the application to be viable,
2. Nice-to-Haves: those that could be included if resources allow, and
3. Won’t Haves: those that aren’t ready for inclusion in the app’s initial launch.

In order to start figuring out which user stories fall into which of the above categories, we can simply look at the matrix and what the matrix tells us. We can think of the matrix as having a few groupings or “zones” – we’ve labeled them as A through F below, and have provided definitions for each zone further down.

Zone A = High Value, Low Effort

Features or user stories that fall in this zone can be thought of as features that lend themselves to the primary functionality of your application, and are expected by your users to be included at launch. These Must Have features can be implemented without compromising your budget, launch date, or draw energy away from other important app requirements.

Zone B = High Value, High Effort

A Feature or user story that falls in this zone can be thought of as a Must Have feature that will delight the user, and is worth expending more resources to ensure it’s included. It’s important to recognize that all projects carry some degree of risk, but with careful evaluation, you can ensure that high-risk, high-reward features won’t fall through the cracks unnecessarily.

Zone C = Low Value, Mid Effort

You could think of features in this zone as Nice-to-Haves. These are those slightly un-sexy operational features we mentioned earlier. They aren’t flashy, or explicitly valuable to your end users, but just need to be there. An example would be meeting WCAG 2.0 accessibility requirements for a web app, which capable shops can integrate with little effort.

Zone D = Mid Value, Mid Effort

A feature in this quadrant is likely a piece that your users identified as potentially important, but might be too costly for inclusion in the first round of development. These items might depend on further examination of the post-launch application to decide if they’re worth including down the road, and can fall into either Nice-to-Have or Won’t Have categories.

Zone E = Low Value, Low Effort

These features just don’t really fit the bill in terms of value, but aren’t much trouble to put in if resources allow. A good example might be an improvement to the backend to make content editing more efficient for your staff, but doesn’t really impact the front-end user experience. These can fall into either Nice-to-Have or Won’t Have categories.

Zone F= Low Value, High Effort

These features are just straight no-go’s – aka Won’t Haves – in their current state.

It’s important to remember that time might change the placement of any feature on this matrix. A feature that was too expensive or time consuming 5 years ago might be commonplace now thanks to advancements in technology. Never throw out these ideas, but put place them in your backlog for re-evaluation or inclusion in future sprints.

Take the First Step

Narrowing your feature list and gathering consensus among your invested parties is among the most impactful early-stage steps you can take to ensure your project starts on the right foot. As you progress towards the start of your next digital project, you can take the 2×2 Matrix method and put it to the test following the steps outlined in this article:

1. Collaborate with your team to come to a consensus on what Effort and Value mean within the context of your project
2. Create a comprehensive list of the User Stories or features that your application would contain in a perfect world
3. Discuss each User Story through the lens of both Effort and Value, and place them on the 2×2 matrix accordingly
4. Compile your Must Haves and Nice-to-Haves to form the first Requirements List for your future application

With the last step, you’ll have populated your 2×2 Prioritization Matrix and, in the process, generated a feature list supported by logic and consensus. These factors are the indicators for a project that is aligned with your organizational strategy.

Now all you have to do is follow through.