Why Feature Prioritization Will Always Be an Art

So you just got a fresh offer as a product manager in the new firm. Congratulations! However, chances are, that you will have no clue what you signed up for right until you start working on the role. And it doesn’t matter how many good questions you asked in the interview, how many years of product management experience you have, or how well you have learned all of the 12 principles of the Agile Manifesto.

Product management is more of an art than a science, and its unique deliverables depend largely on the personality of the product manager and the unique environment around the process. 

When I just got my role as a product operations manager at Google, I expected product changes to become a breeze. I would use all of my analytical power to make an exhaustive ranking of features and their monetary value and passionately pitch the top solution to the head of engineering once in a while. When the feature gets implemented, I repeat the job for the next thing on the list. Unfortunately, the reality is really much more complex than that.

Let’s say you did your homework and learned methods to prioritize features, including Feasibility-Desirability-Viability, Impact-Effort matrix, RICE method, Priority scorecard, Kano method, Impact-Urgency matrix, MoSCoW method, feature bucket, and Jeff Patton’s story mapping.

Even if you are analytical enough to fix such issues as “apples and oranges comparison”, “difficulty to quantify” and “lack of data”, there will be unique problems and dilemmas that require a personal judgment call from the product manager.

Here are a few main reasons why the personality of the product manager is very important and why thinking on your feet is so crucial in product management.

Every company, depending on its maturity stage, might have different priorities. If you are joining a corporation, it is worth learning about the mission and vision of your particular department.

When I joined my PM role at Google, our management renewed a complex vision for a variety of products to a simple statement: “Ease of use”. I believe that this simplicity of the mission statement is something that serves as a lighthouse during the product management storm. 

Should I fix this issue by building yet another dashboard? Or can this be fixed at the core of the user experience to consolidate the toolkit? It becomes easier to make the right decisions when you understand what kind of temple you are working in. If you joined a startup, maybe you don’t have the privilege of a mission statement. In this case, you can take initiative and work with a team to formulate one.

By definition, there are more senior stakeholders in the firm, no matter how empowered product development is. According to Product Management Prioritization Menagerie, there are a few senior stakeholders that can cause difficulty in product development. It is not always the same person, sometimes roles can switch, which makes feature prioritization difficult. Some of the stakeholders to look out for: 

What kind of person do you want to manage the development of the product in your company? The one that is strictly obeying the rules of the senior stakeholders, or the one that can say “no” to the senior leadership? Product evangelist or an opportunistic adventurer? Do you want product development to be a single-handed vision or a constant diplomacy at the cost of effectiveness? 

In-company stakeholder dynamics is a constantly changing environment that is also unique depending on the feature in question. You might feel like a product king, but when a feature change is related to legal risks, be ready for some valuable seagull management advice from your legal counterparts.

Working with UI designers sometimes might feel like working with ZEbRAs: this button has to be this color and shape right here. Why? Because they know design trends better than you. 

The importance of a PM's personality here is crucial: you have to be open enough to listen to all of the stakeholders, but be able to move the project at the corresponding pace, because listening to everybody can stall the changes. 

Every task of the developer is unique. Besides, the backend of the development is unique for each company too, meaning that the same feature can be much harder to implement for some prehistoric reason that nobody knows about. Was part of your company software acquired during the growth? Did you outsource part of the code that is not clear to the team today? Are you using third-party services that you have no control over? 

Quite often people in the company have a higher turnover than the solutions they implement for the software. That can easily leave you and your team in a situation where there is no proper documentation left to explain the mechanism of work. So before even changing something, you actually need to take a few steps back and learn the way it was built before. What might seem a small product change can be just the tip of the iceberg.

Besides product development, an equally important task is product maintenance. Usually, the team that is responsible for the development of the product is the one that is tackling the critical bugs in the system. How will your team find a balance between feature implementation vs bug fixing backlog? What kind of urgent bugs have to be prioritized over planned feature rollout? 

There is no one framework that can answer this question, and these decisions need to be done on every single day case by case. You can’t always prioritize the features that are the loudest (e.g. Sales and Support requests), so it takes a lot of guts to be ready to take the role of a “bad cop” and tell the leadership of these teams why certain changes won’t take place. Just have a look at the “This feature will close the deal” case study to understand the challenge a bit better.

All in all, I believe that hiring the right product manager is a rather complex task, which has to take into consideration his background, personality, level of independence, and not just technical skills and previous experience with similar features. What might seem like a technical job, is, in fact, more of an art, when you take into consideration organizational complexity. The role of “product manager” can mean literally anything from the most important person in the company to yet another operational support person. 

When HR teams make a job description to fill the role, they focus their attention on the product: “you worked with the payment system? Great, that’s what we are looking for”. While in fact, there has to be a transparent vision of what kind of personality type they are looking for: extraverted stakeholder manager, analytical machine, operational scrum master, PM with a marketing vision, or a documentation guru. All these different types of people could have worked with a payment system and they all fit the job description that is looking for a payments PM. It is tempting to say that we need all of the above-mentioned qualities in one person, but if you have a closer look at them, you will find that some qualities can’t coexist in one person and have to be delegated.

For Product Managers that are searching for a job, this can be valuable advice about how to position themselves on the market. There is no need to pretend to be what you are not: be transparent about your background and focus of interest in the CV introduction.

I came to the PM role from a marketing background and am excited about improving customer journeys. If you are not transparent from the start about what aspect of product management makes you excited about the job, you might end up in the wrong place, no matter how appealing the job description of the role seems to be.