13 min read

Product = Priority + People + Process

QUICK SUMMARY

Axiom: A product is made by people betting on priorities following an agreed-upon process. In reality, the three factors contained in this axiom are essential to succeed in any management role. This article zooms in on product development, as I will focus on real-life experiences and typical situations in the product management world. Product managers […]

Axiom: A product is made by people betting on priorities following an agreed-upon process.

In reality, the three factors contained in this axiom are essential to succeed in any management role. This article zooms in on product development, as I will focus on real-life experiences and typical situations in the product management world.

Product managers at the individual contributor level (including Apprentice Product Managers) are both players (in the product team, usually via the triad/trifecta of product/eng/UX) and managers. They have a lot of influence on people (their team) and processes, while their primary responsibility is prioritizing the team's efforts.

At more advanced levels, the prioritization efforts take precedence. The product leader manages direct and indirect reports and is responsible for more and more team outcomes. However, the People, Priority, Process model remains usable and valid at any level of seniority as a mental framework.

Here is a Venn diagram representation of the three concepts: People, Priority, and Process.

People

I sincerely believe this is the most critical predictor of success for any team. Having the right people in the right seat is especially vital for product teams that rely on a loosely coupled matrix of individuals reporting to different managers (Product, UX, Engineering).

To succeed, you don't need geniuses, Ph.Ds, and 10X folks. You need the right people in the right seat.

To ensure your team is well-appointed, here are the most common tools you can use:

Grow your team: Conduct 1:1s, craft development, career development, coaching, etc.
Redefine roles & responsibilities: This can be done within your department or globally. Be careful because, while a new organizational design is compelling, redefining roles is hard to master, and errors tend to be costly and long-lasting.
Internal mobility: If someone does not fit in your team, help them find another role in the company. If you think someone from another team would make your team more effective and exciting, make it easy for this person to join your team.
Fire people: Use the three strikes rule. Once you have tried three times and have been radically candid and explicit with the person, it is time to let them go. Once you’ve made this decision, act promptly and with empathy while following your organization’s process (PIP, etc).
Hire people: This is only available when your product area or organization grows. If this is not possible for your team: learn to do more with less and apply the first items in this list. Growing your team, redefining roles, enabling internal mobility, and firing dead weight should enable you to hire someone that will succeed and make an impact.

People: Signs that you’re winning

Folks from other departments/business units want to work in your team (internal mobility).
Team spirit and morale is high and folks are having fun working together.
Team members are vulnerable and share their mistakes and learnings with retrospectives, and the team consistently reflects, learns, and adapts.
Risk-taking happens consistently.
You receive positive feedback from other team(s)/department(s) for the work ethic and efforts of your team members.
Team members are intrinsically motivated; you only have to guide, highlight good behaviour, and play a coaching role.
Communication is easy—it is OK to debate, disagree and commit.
Folks on the team organize a virtual or in-person gathering when someone is leaving.

People: Signs that you’re losing

Great individuals are leaving the team, whether through internal mobility, involuntary or voluntary attrition.
Team adopts very conservative objectives or the team is risk-averse.
Team morale is low.
You have to consistently challenge the team to adopt ambitious or risky goals and objectives.
Teams do only exactly what they are told to do with very limited initiative.
You have one or more folks on the team with performance problems, be it negative feedback, resistance to coaching, or a personal improvement plan.
Communication is hard, debates are uncommon or unproductive.

Priorities

The priority component is the one closely associated with the product manager's craft. In general, the product organization is responsible for the prioritization efforts—such as the roadmap, betting table, 6 week cycles, et cetera.

While it sounds simple on paper, real life is usually much messier because the ability to prioritize depends greatly on the strategy and business context, such as the stock trajectory, funding events, pandemic, economic downturn, and the multitude of other factors that play a role. Lots of these are outside of the control zone of product managers.

From personal experience:

Smaller product team structures tend to have no strategy or a very undefined one. It was maybe useless while the team was <10–20 people, but by the time a product manager joins, it is necessary to have a strategy to empower teams to make excellent, and high-quality decisions. Play a leading role and write the strategy down for your group, product area, and organization.
Larger structures may have a high-level strategy that is, in practice, useless for your team: you will need to fill the gaps and translate the strategy into product principles that are meaningful for the product teams you are working with. You must validate these principles with the stakeholders before you can own any prioritization efforts.

A team without priorities behaves erratically and has almost no impact. Why? Because every player is playing for its benefit (local optimization) and is ignoring the big picture (global optimization). Citing my former CEO Karen Baker here:

Nothing is worse than a team running around like chickens with no head.

While this is a bloody analogy, I believe it makes a lot of sense.

As a Product Manager/Leader, this is your core responsibility! You have to make every effort to accomplish something meaningful for the business at the global level. Your primary tool to align teams is the prioritization of efforts.

Priorities: Signs that you’re winning

Everyone on the team has a good-enough understanding of the high-level company strategy and can connect the dots with their own priorities.
Team members refer to the priorities when making decisions.
Team members say no to each other and to stakeholders when proposals are not aligned with the priorities.
Priorities do not change at every sprint. 80% of the priorities remain stable for 6 weeks to a quarter, depending on your prioritization process.
Retrospectives consider the priorities and look back to check if we have met our goals or not.

Priorities: Sign that you’re losing

Highest Paid Person Opinion (HIPPO) syndrome. The team(s) do not decide—everyone waits for the highest-paid person to decide. If you lead multiple PMs, this person may well be you! As a rule of thumb, you should not decide for your team but try to fix the root cause of this problem.
Decisions are made ad-hoc, seldomly documented without any framework or reference to your company or team priorities.
Everything is urgent and vital—reactivity is the driving force. When the CEO, a VP, or a customer is angry, then we do something. Otherwise…we wait.
Priorities change every week. If your priorities change often, everyone will stop paying attention to any framework, including strategy/mission/vision/roadmap types of frameworks.

Process/Agile Rituals

In the world of Agile, processes have bad press and are perceived as negative/unnecessary. If you work in such an organization, don't despair: focus on the rituals. Rituals can be seen as a function to implement a process. Change your viewpoint and language, then go improve your rituals!

Processes can be documented or undocumented. They can also be deeply ingrained at the organizational level—at this point, we just call them “culture.” They are notoriously hard to change globally without using authority, and even then, it will take a long time to have everyone adopt a new process. However, they are quite easy to change locally.

If you have no authority on other crafts or teams (which is the case for most product managers), your primary way to change a process is to propose changes as an experiment within your direct team. Lead by example and demonstrate the value of the processes you own so that others can now trust you to help them improve the processes they are responsible for. Think locally so that you can have a global impact via a series of successful experiments.

Process: Signs That You’re Winning

Reporting is high-quality, clear and consistent inside the team as well as along the hierarchy, all the way up to the CEO.
Escalation is working well, and stakeholders are not surprised by crucial decisions.
Teams decide when to change the process, not the management.
The team has solid rituals & tools that are stable over time.
The team systematically measures success or failure and shares their findings.
The team delivers the quality experiences they agreed to ship.
You can move and iterate fast, though what “fast” looks like depends greatly on your industry and company size.

Process: Signs That You’re Losing

The team does not spend time improving their rituals/process/tools.
Onboarding is slow/burdensome/costly for new employees. They have a hard time understanding how the company works, and nobody can tell them!
No consistent and shared learning loops—in particular, few retrospectives, root cause analyses, five whys, or other learning mechanisms.
Processes start and stop at the department's limits: Prod/UX/Eng/Data/Marketing. A good product requires a great holistic user experience. To deliver this experience, the same team has to be involved from ideation to delivery, adoption and growth.
Your organization uses unusually complex processes/toolkits/stacks/information systems for the industry you are in. However, it bears noting that heavily-regulated industries (healthcare, banking/finance, security, et cetera) inherently require more processes than non-regulated ones.

What should you fix first?

Why Start with People?

I would argue here that you should always work your way through the pyramid in this order:

People
Priorities
Process

This approach relies on two well-known frameworks:

Agile: The first tenets of the Agile Manifesto states: "People and their interactions over process and tools."
Modern product development: the organization expresses a "commander's intent" and defines a priority so that the team can own the problem space, discover problems/solutions and make progress toward the desired goal(s) and outcome(s).

Start in your own house:

In my experience, having a conflictual relationship with a report that lasts for more than 3 months will consume most of your energy, prevent you and your team from having a significant impact and negatively impact all your other reports, as you will be less available and negatively impacted by the situation.

You have to get each of your reports on the right seat, both for them and for the company. This is hard emotional work that you must work on as soon as you get into a management position. Trying to shy away from it will only lead to disaster, regret, and terrible outcomes for all the involved parties.

What about people I don't manage directly?

If you manage managers or if you depend on other managers (say UX and Engineering), then you have a similar problem whether or not this individual is your direct report. Product management is a team sport, not an individual gig.

Consider a sports team analogy: multiple coaches are responsible for different aspects of the game. For instance, in rugby, you have a lot of coaches: a forward coach, a back coach, an offensive coach, a defensive coach, a kicking coach, a mental coach, etc. However, even with all these resources available, a people problem can derail the best possible team! It is your responsibility as a manager (especially as you become more senior) to do something about it and ensure that everyone on your product team(s) is the right person in the right seat—no exceptions.

Once you have decided that this person is a problem and is not in the right seat, use the feedback loops that most organizations have built: impact review, 360 reviews, and solicited or unsolicited feedback. In other words, express yourself and signal what you consider a significant “people problem” to this person's manager. This is especially important if it hinders the team's performance. The same is true if you receive complaints about your reports!

Why Priorities before Process?

If you can not establish a vision/mission for your team and then get it endorsed by your organization’s CEO, trying to change the processes in a meaningful way will bear little benefits to your team(s).

Why? If a few HIPPO are calling all the shots, this is the process. Changing this process requires alignment with the stakeholders to come up with a different prioritization framework. Start at the root cause of the problem, not on the consequences.

You will need to do extra work to reach a point where you get strong alignment and trust from the HIPPO—this is high-leverage and high-impact work. Don't hire a consultant, don't try to outsource this, but instead use your product knowledge and leadership to get there as fast as you can.

At a certain point, if you can not define measurable, clear-cut priorities, and if the HIPPO process is the one in use, I would argue that the product management function is not required. In Marty Cagan terminology, this is a “feature factory,” and a wind that you can not measure decides where the team is going next. You should either implement a prioritization process, or find another company.

Impact on Outcomes

This simple framework (Product = People + Priority + Process) is quite robust and works at any seniority level. It will help you elevate the debate and identify at which level you or your team are experiencing problems. It is especially useful:

When you join a new organization or when you set up the product function
When you or stakeholders are not pleased with your team(s) performance
To improve the outcome of any team

The proposed approach will also help you avoid typical mistakes like:

Trying to fix a People's problem with Process changes
Trying to define the perfect system (Process) while Priorities are changing every week based on various HIPPOs' opinion
Provide consistent perspective to your team by reframing discussions and goals with your reports or teammates

By applying the People-Priority-Process framework consistently, you will have a unique point of view that enables you to have dispassionate conversations about any problem you want to fix at any level—with your teammates, stakeholders, leads and up to the CEO.