How to Prioritize Product Features and Improvements

This article is a collection of insights prompted by discussions from our several Product Roundtable Breakfasts hosted at our offices and supported by passages from the upcoming book Product Leadership: How Top Product Leaders Launch Great Products and Build Successful Teams.

I’ve added a summary at the end if this article falls in the TL;DR category.

What Is Keeping Product Teams Awake at Night?

What gets done first? How do you decide what features or experiences stay and what gets cut or postponed? Should I listen to customers or my boss? How does the product team get consensus on which direction to follow? Should they even need to get consensus? If the product manager doesn’t always have the final say or authority to make that decision, then what?

These are some of the most frequently discussed questions in product teams today. This article attempts to answer these questions and provide a process for decision making and prioritization.

In a recent survey, Mind the Product and Christian Bonilla, Product Manager and Founder of UserMuse, asked product managers and leaders to name the biggest challenges facing them. The results indicated that prioritizing roadmapping decisions without market research was by far the biggest, followed by being stretched too thin, dealing with executives, hiring and developing talent, and aligning strategy.

In the Mind the Product survey, 49% of product managers said their foremost challenge is being able to conduct proper market research to validate whether the market truly needs what they’re building. When we add the responses from enterprise software PMs, this figure jumps up to 62%. That means that two thirds of enterprise product leaders are currently worrying about which projects are needed. Extrapolating from this, an enterprise product leader will have to dedicate the necessary amount of their time prioritizing and communicating to others about the next product release. That’s a lot of tough conversations with a lot of unhappy people.

Prioritization is Personal

The difficulty of prioritization is not due to a lack of process to prioritize work, but that these processes involve people. People problems are not as easy to solve as technical problems. It’s not surprising then that prioritizing features rates high among the challenges faced by product leaders.

Any product manager knows that the most difficult part of her job is determine which things deserve the team’s time, money, and energy. These are not just unattached ideas or ownerless features, they are reflective of people’s personal hard work.

Rejecting, postponing or ignoring someone’s idea or request can sometimes feel like the very person is being rejected.

In any organization, small or large, a wide range of stakeholders also need to be considered or informed. Often in senior positions, these people hold the ability to insert their choices or opinions without the necessary data or understanding and consequences. One derogatory term for these people is HiPPO — Highest Paid Person’s Opinion. As common as this term is, it doesn’t really give these unfortunate situations the context they deserve. Senior people are rarely malicious and referring to them as thoughtless animals only reinforces the stereotype. If anything they are probably trying to help by adding their opinions. After all, isn’t having a senior role also representative of your expected judgement or decision making?

Dealing with Out-of-Nowhere Requests

The reality is that stakeholders clouding decisions without evidence can derail even the most well thought-out plans. Nobody likes it when high-level ideas are added to the roadmap as must-haves, especially when they are not backed up with validation. “The team just experienced another executive swoop and poop,” says Jared Spool, Founder of UIE and CoFounder of CenterCentre, likening these executive decisions to a seagull attack.

“The executive swoops into the project and poops all over the team’s design flying away as fast as they came, they leave carnage and rubble in their wake.” As humorous as this sounds it’s also Spool’s hyperbole. Teams and their leaders are more often working towards common goals and have no desire for anything ending in the aforementioned carnage and rubble. The absence of evidence is addressable without drama.

To many product professionals, having their roadmap hijacked from time to time by other pressing issues is an unavoidable situation that must be tolerated. Tom Greever, author of Articulating Design Decisions, calls these hijacking decisions the CEO Button. “An unusual or otherwise unexpected request from an executive to add a feature that completely destroys the balance of a project and undermines the very purpose of a designer’s existence.” We acknowledge that these situations can be often be harmless but if these interruptions continue unchecked they will ultimately derail the product. Fortunately there is a solution, but it is not a quick fix.

Proof Points

One way to avoid future disappointment, is to create a testable prototype of the idea, feature or interaction that is being planned. This can be done for most design features and interactions and currently, the easiest way to do this is with Design Sprint or Directed Discovery.

Both these approaches are based on the scientific method of developing a testable hypothesis and then running the appropriate testing cycles to generate results, providing immediate evidence either for or against the hypothesis. “When the team invites real users to try a prototype, they’re collecting data about the users’ needs, which provides a solid footing for the design” says Jared Spool about Design Sprints. “When the executive shows up, the team can present the data along with the design that emerged from it. Demonstrating the data behind the design decisions, reduces the potential for negative influence the executive can assert, and smart executives will embrace the approach.”

Collaboration, Not Consensus

Prioritization can be polarizing because it’s often perceived as choosing one person’s ideas over another’s. When people have something personal invested in an idea or feature that’s on the chopping block, emotions can run high. The solution is collaborating at several levels. It is the product leader’s job to connect with all the stakeholders and communicate to each of them why certain choices have to be made. It starts with developing a shared vision and purpose for the product.

If the team doesn’t agree on the big picture, then they certainly won’t agree on a single feature.

Getting buy in to the company vision and the ‘why’ driving that vision are essential. Agreement and understanding of both the company and product vision give the team a North Star. What it doesn’t do is give them a method for prioritizing each task and feature. Stalemates can still occur even when the team is aligned on the vision. The key to breaking the potential stalemate is to not set consensus as the goal. Collaborating towards a solution doesn’t require consensus. This concept is not new to leaders but might be new to the realm product leadership.

Herminia Ibarra and Morten Hansen suggest in their article “Are You A Collaborative Leader?” (Harvard Business Review, July 2011) that collaborative leadership is the “capacity to engage people and groups outside one’s formal control and inspire them to work toward common goals — despite difference in convictions, cultural values and operating norms.” In collaborative teams, leaders still retain the authority to direct their teams if and when resolutions can’t be found. As necessary as it is to treat everyone in the team as equal human beings, there is a tendency to conflate this with equality in ability to understand the context. The UI designer on a team might have a strong understanding of their domain but will probably lack the industry experience and scope of knowledge that a seasoned product leader has.

It’s easy for the members teams to get hyper-focused on their interests and domains. After all, we hire people for their specialities and focus. The job of the product leader is to help the team rise above thinking of only their individual contributions and consider higher goals. “As product managers it’s our job to make sure that the company is building the right product, but many (possibly a majority) of us don’t feel like we’re doing that,” says Christian Bonilla.

Connecting Vision To Practice

What not to prioritize is as important as what you’ll be prioritizing. Mina Radhakrishnan, the first Head of Product at Uber says, “a big part of product leadership is thinking about why are we doing this-and-that to set the basis for saying no, we shouldn’t do that.” If something doesn’t make sense in the context of your larger strategy then consider shelving it for another time.

The vision also serves as a filter to de-prioritize the things that won’t make a meaningful difference to the value of the product or experience.

Linking the product vision to the practical work can feel unnecessary when you’re trying to meet a shipping deadline. In reality, making this connection makes the work easier to understand, and can save time in the long run. For leaders and managers, reminding the team why you’re building that feature or making that improvement gives the work meaning. Seeing the connection between a task and the purpose behind it can also be motivating.

How Not To Prioritize The Work

Before we dive into the process for prioritization, let’s talk about how not to prioritize your strategic goals and activities. Specifically, we need to address the influencers, filters and lenses that are used to direct this kind of decision making. Knowing what filters not to use is as important as knowing what filters you should use.

1. Gut Reactions: Your CEO’s gut reaction to a feature is not a good way to determine if something makes it onto the priority list. It’s not that your CEO isn’t smart or that they don’t have great insights, but all subjective opinions are frequently influenced by personal bias. Find a way to back up any opinions with evidence.
2. Sales & Support Requests: Similarly, requests from sales teams or support teams reacting to one or two customer requests need to be checked for consistency and relevancy to the broader customer base. Prioritizing a feature because one customer says they need it will set a precedent for this kind of interruption to the workflow.
3. Analyst Opinion: We also recommend not relying too heavily on analyst opinions either. These industry pundits are basing their suggestions on either historical or aggregate sector data so use them with caution. If you lack any other sources of data then back up this data with your own user testing.
4. Isolated Economics: The ROI on a feature doesn’t tell you the value of the outcome for the customer or for the company. Value is harder to measure and will require additional conversations and testing to establish than financial data alone. Financials are very important but cannot be used as the only metric for decisions on priorities. We advocate for the use of economic calculations and the analysis of unit-economics when determining priorities, but with the caution that a feature ROI doesn’t necessarily translate to company ROI or customer value.

Of course all of these are valid sources of information, just not in isolation and never at face-value. Knowing where the data or opinion comes from is as important as the information itself. Being conscientious about checking the origins and context of data helps make better use of that information.

A Better Way To Prioritize The Work

“Too often we think we have a good idea, but we’re starting on the supply side. We’re looking for excuses to build the thing that we want to build, and the real trick to going deeper with product is to learn to move backward and get into the demand side and ask: Why is this the right time? Why is this important? What matters right now?” says Ryan Singer, Product Manager at Basecamp.

Singer reinforces that feelings and personal bias can often lead us astray. So if those sources of information should be either distrusted or double-checked, what sources should you trust? Prioritization is best done through the lens of the following objective criteria:

1. Feasibility
2. Desirability
3. Viability

Feasibility is a technical consideration and will need the inputs of the technical team members. This would include back-end engineers, UI designers and front-end developers. It might also include technical partners that are providing services or support to the tech stack. Product leaders are not looking for personal opinions here, rather just what is technically possible versus impossible or highly improbable.

Desirability is the customer-experience focused part of the analysis. This takes into consideration the needs of the end user, the interaction elements, affordances and how these are to be marketed or sold. This information can be gathered from the researchers, UX designers, marketing and strategists. In turn this information would have been derived from user tests, prototype validation and analytics.

Finally, the viability of the work needs to be considered as a function of the overall business. This insight is provided by the product manager’s and relevant executives. Viability also includes factors related to the industry, regulatory environment, and financial oversight, or legal considerations.

Outside research or data would be a relevant to any one of these three criteria, assuming it was validated and relevant.

Constraints as Prioritization Filters

Within each one of the three criteria above will be the consideration for constraints. For example, feasibility doesn’t just mean to answer the question “is it possible?”, it means to answer “how will this be made possible?”. Constraints like time, people, money and process serve as filters for prioritization too. Leaders and managers can filter their decisions through constraint-specific questions like, “will we have the time to do that?” or “do we have the skills right now to make this happen?”

You can organize constraints into two large buckets; people and process. People is self explanatory. Process includes all the non-human things that contribute to the work being done. Let’s explore constraints further:

1. People
2. Process (Time and Dependencies)

People: The first people question you need to ask is “do we have the right people for this work?”. If yes, then the next question is “which of our people would provide the best results?” This second question aims to align the best skills and personalities with the work to be done. Certain people work better under pressure and would be better suited for this time intensive work. They are not necessarily better strategists, designers, or developers than those people who work better when given more time. They simply operate better under pressure. The goal is to align their personalities and working styles with the outputs and outcomes being planned.

If you answered “no” to the first question of whether you have the right team, then you’ll need to determine if hiring full-time people or using external people, like freelancers or outside firms, is the best option. This topic is covered in detail in another article I wrote on on hiring product people.

Process (Time and Dependencies): There are lots of different processes for product teams to use. Some use a home-grown process, others use a standardized process, while most use a hybrid. For our purposes of product design projects we have a rigorous hybrid process forged from 12 years of experience. It’s hard to say if there’s a perfect process. I’ve certainly never seen one but I have noticed that the best processes are rigid enough to keep the team focused while flexible enough to deal with ambiguous reality.

For a process to be effective, it needs to be deeply understood by the team. Apart from quality of the people, the process is the single biggest determinant of the success of a project. It’s less important what the specifics of the process are than the fact that the team has agreed to work in a way they generates successful outcomes. This agreement encourages the right kind of communication and speeds up decision-making.

A key component of this process is the ability for the team to emphasize a part of the process over others. Every project is different and thus priorities are different. Using inputs from the initial problem-solving work the team can dynamically change the size of each part of the project, thereby showing relative weight and resource requirements of that part of the process.

A project that requires more research (Explore) due to a lack of data or knowledge, and requires more prototyping (Solve) and iterative improvement (Refine), might look like this:

Like an algorithm, a good process is made up of a series of steps that guides the team from a starting point to a predictable outcome. It’s important to know what steps make for the best outcomes. I’ve heard it said that any process is better than no process, but the truth is that bad processes can derail the best people’s intentions. Invest some time developing a good process that works for your team than battling through a bad process.

Like an algorithm, a good process is made up of a series of steps that guides the team from a starting point to a predictable outcome.

The two biggest components of any creative or technical process are time and dependencies.

Time Constraints: The time constraint will be split into containers (sometimes called time-boxes) or cycles that make the most sense for what your team is trying to achieve. As a product design firm we prefer weekly or sprint style containers as it aligns nicely with our client’s product development processes. Your company’s cycles might be shorter or longer depending on the size of the team, delivery framework (e.g. Agile or Lean), or what budget you have available.

The way in which you divide your time for delivery cycles is not arbitrary. For example, in startups, where the amount of funding often determines time available, a shorter delivery cycle is necessary. Selecting a faster cycle signals to the team that you’re going to need to ship features faster. This also means that there will be less time for research and testing, forcing the startup to adopt mechanisms for faster validation, i.e. the Design Sprint. Choose your time containers wisely.

Dependencies: In the simplest terms dependencies are both the links between the steps and the relationships between the inputs and outputs. Managing the inputs through the process should produce the outputs you need. For example, if you determine you need 4-weeks to create and test a feature you’ll need time, money and people to do that work. Sounds like simple math doesn’t it? In the real world this is a little more complicated.

Every time you add a feature you’re creating another object that is dependent on other things. As your product grows and adds more features, so to do the dependencies grow. In all complex systems, changing one thing leads to a domino effect on how other things work or behave. For example, if we spend money on one thing then there’s the opportunity cost of not spending it on another thing.

We try hard to organize features into experiences and themes to understand their relationship to each other. What’s often missing in roadmaps and planning are the people dependencies. As you’ll see from the matrix examples in this product roadmapping article, it’s essential to acknowledge when people are going to be directly impacting the outputs. The designer that still needs to be hired, or the engineer that is on honeymoon for a few weeks, are going to impact your plans. Don’t ignore these people dependencies. Prioritize with the delays, flaws and inconsistencies in mind.

Mapping Priorities

Once the list of priorities has been developed create a visual artifact of those activities. We’re big fans of drawing and sketching the priorities into some kind of roadmap. Traditional roadmaps don’t work for us as they tend to be overly specific. We prefer themed visualizations that show immediate verses less urgent features and experiences.

Some companies use a matrix to map out the priorities. By mapping criteria against the features in the prioritization list you can develop a matrix. Each feature or element is then scored in terms of its feasibility, desirability and viability. The final column, representing the total scores, represents the priority. Ultimately, the matrix aims to objectively focus on the most important theme and the order that they would be sequenced. If you’d like more details on how to do this check out this article on Building a Product Roadmap.

Overlaying considerations for innovation can also be done with a this prioritization matrix. When there is a high value for each of the criteria there is high overlap and therefore a strong indication that this will also be a candidate for new innovation.

Summary of Prioritization Considerations

1. Prioritization is Personal: Don’t overlook the subjective attachments and emotional value of choosing features.
2. Executive Button: Senior leaders, investors, stakeholders and executives have something meaningful to add. However, whenever possible make sure this input is supported by context and data.
3. Proof Points: Seek methods to shore up your data and research with evidence about what is valuable and what is not. Priorities are easier to filter when you have the facts.
4. Collaboration, Not Consensus: Get input from all the interested or invested parties, but not at the expense of progress.
5. Rooting Vision To Practice: Ensure your company or product vision remains at the forefront of all prioritization conversations.
6. How Not to Prioritize: Gut reactions, isolated sales and support requests, analyst opinions, and out-of-context unit economics are relevant but not critical to prioritization.
7. Prioritize With Purpose: Feasibility, desirability and viability are the product leaders core principles. Use these guides to help filter and prioritize.
8. Constraint Methodology: Use a finely-tuned process to help filter the work ahead. Constraints are powerful lens to focus outcomes.
9. Visual Clues: All journeys require a map. Use themed roadmaps to clarify the steps ahead and remind team members where you’re headed.

Final Thoughts

Prioritization can’t be done in isolation. It’s part of the strategic planning process of any product business. Furthermore, it’s essential that teams tie the resulting release schedules and roadmap back to value of the product. In the most customer-focused organizations, the team will collaborate with the executives to ensure the prioritization of work is mapped to the company vision and go-to-market plans.

It follows that any prioritization work is dynamic. Prioritization doesn’t really end. As soon as you are done, you need to start collecting new data, analyze changes and review plans. Anything that has to do with humans is inherently temporary. Plan for a ongoing prioritization activity. Set this expectation for a rolling prioritization schedule with your team and you’ll find things run just a little smoother.

Enjoy what you’ve read? Good, because there’s an entire book full of this stuff. I’ve been working with two masters of product Martin Eriksson and Nate Walkingshaw on writing a book that all product professionals can benefit from. Partly out of curiosity and on the back of our own experience, we’ve interviewed almost one hundred product leaders. Their insights and experiences will open up the conversation and take the lid off the mystery of great product leadership.

You can follow us on the twitters at @rmbanfield @bfgmartin and @nwalkingshaw

The book will be published by O’Reilly and on shelves in May 2017. You can pre-order the book on Amazon or directly from O’Reilly.