How to Prioritize Features For Digital Products
Let’s get our priorities straight! In this guide, we share how to prioritize features for digital products and services. Doing this in cycles can help you manage stakeholder expectations, keep budgets and timelines in check, and improve chances for long-term success.
When you’re tasked with executing a large digital project, all the up-front planning in the world won’t guarantee success. In fact, plan too much and you’ll actually work against your chances for success. Plan too little and your project could go over budget, or worse, won’t resonate with target users. Managing a successful project means striking a deft balance between stakeholder needs and project realities. You must prioritize—and re-prioritize—project tasks so your team is always focused on the most important thing. But how, specifically, do you do that? We’ll cover that and more in this handy guide.
Every Project Has Risk and Uncertainty
Your job is not to prioritize and document feature requests. Your job is to deliver a product that is valuable, usable and feasible.— Marty Cagan
Many web design agencies and their clients still take a traditional “waterfall” approach to digital projects: lots of estimating and negotiation up front, then trying like hell to make good on those estimates within a pre-specified timeframe and budget. This approach, which is often run through a standard RFP process, is inefficient and filled with risk. It rarely takes into account that each project has a unique set of challenges that lead to new learning.
The new learning, in turn, drives insights that will result in a better product. This often requires shifting priorities, revising your approach, or, occasionally, prototyping something new from scratch to test with your users. However, if your project is tied to a detailed plan, contract, budget, and timeline—each of which were created up front before any of this learning occurred—things tend to fall apart quickly. This is why so many digital projects go off the rails, but it doesn’t have to be this way.
Prioritize Features by Adopting This Mindset
By prioritizing features during regular communications with project stakeholders, you can better manage expectations and improve your chances for success. But first, you have to get everyone in the right mindset to think differently about how projects are run. This requires a few important things.
Collaborate . . . with Humans
If you want to go fast, go alone. If you want to go far, go together.— Unknown
At Mightybytes, we believe so strongly in the power of good collaboration that we have put it at the heart of our company’s processes and practices. It’s why we run discovery workshops at the outset of any project and continue in-person collaborations throughout a project. This moves things along faster and helps everyone reach consensus on priorities quickly, then maintain them over time. It also helps us build quality relationships with our clients that are based on trust and transparency about everything from project budgets and deadlines to mistakes and cost-cutting innovations.
In a world filled with digital tools meant to help you manage every little thing, it can be easy to get caught up in completing checklists and responding to notifications rather than interacting with people. Remember, there are good people behind every great product. Prioritize them accordingly.
An Agile Mindset values learning and change over planning and control. It is deeply intertwined with our ability to be resilient and responsive.— Pamela Meyer, author of The Agility Shift
As noted above, there is no way to execute a risk-free digital project, yet organizations still pursue this fantasy even though their systems work against organizational agility. Instead, help your project team fully understand the uncertainty that comes with these projects and embrace an agile mindset that bakes learning cycles right into the process.
Identify Your Most Important Stakeholders
Outsourcing your product strategy to your customers is a mistake in nearly all situations. An inexperienced product manager will, with the best of intentions, rank feature requests by frequency or size of customer. A seasoned product pro in contrast will seek to understand customers and their needs — but this is fundamentally different than asking customers what they want.— Product Roadmaps Relaunched
Organizations have many stakeholders. Each will understandably prioritize their own needs first so project teams must know how to balance stakeholder requests with what will actually improve a product. In other words, prioritization must come from key stakeholders, not all stakeholders. While requests from your sales team, outside analysts, or even your CEO should be considered, project teams must have the freedom to reject these requests or apply the brakes when agreed upon priorities are threatened.
Running a stakeholder mapping exercise at the start of any project can help a team better understand whose input is required for approval and what level of commitment each is willing to take in order to successfully prioritize features and execute the project. Of course, it goes without saying that users or customers are any project’s most important stakeholders and should have internal advocates for their needs.
Outcomes Over Outputs
Outputs are easily quantified things that we produce—number of products or features, number of releases, or velocity of development teams. Outcomes are the things that result when we finally deliver those features and the customer problems are solved. True value is realized in these outcomes, both for the business and for the user or customer.— Escaping the Build Trap: How Effective Product Management Creates Real Value
People get hung up on features, which is understandable. They’re tangible, easy to grasp, and, in a traditional business setting, allow people to cover their asses should something go wrong. But a feature is output-based, often included in a long list of project requirements that may or may not succeed once your website or digital product launches. A change in user behavior, however, is an outcome. This is far more desirable.
Here’s an example:
- Output: every blog page should have a donate button on it.
- Outcome: our organization will increase donations by 15% this year.
It’s an important distinction to make, especially at the beginning of any large project. A button on every blog post might very well increase donations by a specific percentage, but you won’t know for sure until you test it. A good product team should prioritize key outcomes versus checking features off of a list. By fixating on outputs, we often overlook the more important question: are we really creating value for our users while also meeting organizational goals in the process?
Test and Measure Often
If you are not doing the most important things right now, you risk not having the opportunity to do them in the future. In fact, this concept is so important to prioritization and roadmapping, that we’ve developed a rule, nay, a law to reinforce it: Always assume you may have to stop work at any time.— Product Roadmaps Relaunched
In a perfect world, every prototyped feature, layout, or piece of content would be tested with target users prior to and after release to see how they perform against desired outcomes. Test results could drastically impact how (or whether) you continue developing and improving them.
The prioritization process in itself can help you decide which features should be prototyped and tested. Is this feature critical to our success? Based on results from our last test, how certain are we that customers will understand it? You can answer these questions by testing the highest priority features first.
Methods to Effectively Prioritize Features
Once your team understands the importance of prioritizing features, how do you actually find the tasks required to make your project successful? And how do you do so in a way where key stakeholders can buy into your methods? There are many prioritization frameworks out there. Here are some popular examples. I’ll share what we use here at Mightybytes at the end.
The methods below aren’t the only ones available. For seven other options, check out Product Plan’s 7 Strategies to Choose the Best Features for your Product or download their Product Manager’s Complete Guide to Prioritization. There is good stuff in both.
The Kano Model
The Kano Model helps teams make design decisions and prioritize features based on two important criteria:
- Their potential to satisfy user needs
- The investment needed to complete those features
The model categorizes customer needs and expectations into three, four, or five categories, depending on who you ask:
- Basic or Expected Features: those necessary for your product to be competitive and allow users to accomplish expected tasks
- Performance Features: those that customers know they want and that increase their satisfaction as you also increase your investment in them
- Excitement Features: often unexpected features that create delight or excitement in users
- Indifferent Features: as the name implies, these features don’t evoke any feelings in users and their value is often not apparent
- Reverse Features: those that annoy or increase dissatisfaction in users
Implementing the Kano Model involves a set of questionnaires and a mapping process meant to ascertain the potential for desired product features to meet the criteria above. For detailed breakdowns of the Kano Model, read this post, this post, or this post.
In project management parlance, Critical Path is a step-by-step process used to identify the activities and schedule required to complete a project. A project is broken into a variety of work tasks along with their dependencies, which are displayed in a flow chart. These are used to calculate a project’s overall duration based on individual estimates for each task. Traditional waterfall projects, as described above, often use this approach. To maintain Critical Path relevancy, teams must regularly update flow chart tasks and their dependencies as new learning and project check-ins occur.
This same approach can be applied to prioritizing product features as well. For example, if you have completed a customer journey map, you’ll learn a lot about how your customers feel as they interact with your products or services. The journey mapping process, when coupled with Critical Path analysis, can help you prioritize customer pain points and identify potential features or solutions at points where users are most frustrated. Then a plan can be devised to prototype and test those solutions with real users.
This simple but effective model, which originated at IDEO, scores product ideas on three criteria, which can help you prioritize features for your digital product or service:
- Desirability: How valuable is it to solving a user’s problem or helping them perform a critical task?
- Feasibility: How difficult will it be to execute in terms of time, resources, cost, etc.?
- Viability: How will it contribute to your organization’s success via profit, revenue, or other indicators?
Using a simple scoring process (one for low, two for medium, three for high), project teams score ideas in each category. Higher scores get higher priority. This method is great for small projects. Challenges can arise, however, when products have hundreds of features to weigh priority on.
While each of the methods described above have their use cases, at Mightybytes we prefer a grid-based model that focuses on impact and effort. Also referred to as Value vs. Complexity Model or a Value/Effort grid, we like this exercise because it is easy to comprehend and really helps our clients understand the potential impact or value a given feature could have, cross-referenced with the level of effort needed to execute it. This process helps us have frank discussions about timelines and budget.
We have some prerequisite exercises to this prioritization exercise, including:
- Aligning business goals with user needs or “Jobs to be Done”
- “How Might We…” brainstorming to generate potential feature ideas
For this prioritization exercise, each participant reads their feature ideas aloud to the group. During this process, we ask several questions, like:
- What effort will it take to execute this idea?
- What value can it bring to the organization? (This could be monetary or other value drivers.)
- What is the risk or cost to the organization if we don’t execute this feature?
Participants place each sticky note into a grid quadrant based on the level of organizational impact and effort to execute. Duplicate ideas are set aside during this exercise and by its end you should see patterns emerge: upper right quadrant items should be your team’s top priorities, followed by those in the bottom right quadrant. The bottom left quadrant will make up “nice to have” features that aren’t critical for success, while top left are ideas deemed not worth pursuing.
But you’re not done yet! We then give each participant four small circle stickies—two red and two green—and ask them to vote on the two highest (green) and two lowest (red) priorities. If you don’t think four is enough, add one or two more, but don’t overdo it! This voting exercise helps people distill the most and least important items in their heads.
By the end of this exercise, you should have a pretty clear idea how your group wants to prioritize features for the project. We capture this list and get started on executing the most important deliverables—those in the top right quadrant with the most votes—first.
Finally, re-prioritizing will help keep your project on track as you learn new things. Common reasons to re-prioritize features include:
- User testing insights reveal that an organizational priority is not actually a user priority.
- Leadership decides that feature x is most important but feature z is not (it happens).
- Organizational change (or, sometimes, lack thereof) dictates new priorities.
- The project budget is out of sync with feature development velocity.
- Assumptions are revealed to be incorrect.
- Data shows that launched features aren’t moving the organization toward desired outcomes.
On any project, you can and should set expectations up front that continuous learning and agility are important for project success, and that this often requires revisiting priorities often. At Mightybytes, these conversations happen during regular project check-ins. Frequency is proportional to project scope, but they are absolutely critical to our goal of creating mutual success with our clients and launching successful products.
We hope you found this guide useful. If you have questions or want to suggest an addition, please drop us a line. We would love to hear from you.