A powerful framework to deliver great products#

Product = People, Priority, Process#

A product is made by People betting on Priorities following an agreed upon Process.

These three factors are key to any management role. As a consequenece, most of this article is relevant for these roles as well but with a focus and real-life experiences originating from the product management world.

Product managers at the individual contributor level (including Apprentice Product Manager) are both a player and a manager. They have lots of influence on People (their team) and Processes while their main responsibility is the Prioritization of the efforts.

At more advanced levels, the Prioritization efforts take precedence and the product manager manages direct reports and is responsible for more and more team’s outcomes. As a mental framework, it remains usable and valid at any level of seniority.

People#

I deeply believe this is the most critical success predictor of any team. This is especially true for product teams that tend to be very diverse and with multiple hierarchies (Product, UX, Engineering). To succeed, you don’t need extraordinary people (genius, Ph. D., 10X folks, etc.): you need the right people in the right seat.

In order to achieve this goal here are the most common tools you can use:

  • Growing your team: 1:1, craft development, career development, coaching, etc.
  • Redefining roles & responsibilities: this can be done within your department or more globally. Organizational design is very powerful but quite hard to master and errors tend to be quite costly.
  • Internal mobility: If someone foes not fit in your team, help them find another role in the company. If you think someone from another team make your team attractive and interesting for this person.
  • Firing: I have a three strikes rule. Once I have tried three times and be explicit with the person, then it is time to let go. It is never easy but quite often a very slow decision. Once decided act promptly and with humanity & empathy.
  • Hiring: This is only available with growth in general and when there is no economic downturn. Learn to do more with less and make sure you maximize your team output before you hire.

Of course, as a product manager, you can only directly control these factors for your team inside the product organisation. For other crafts, you will have to influence and negotiate with other folks or their managers.

People: Signs that you are winning#

  • Folks from other department/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 & learnings
  • Risk taking happens consistently
  • Your receive positive feedback from other team(s)/department(s) for the work ethic and efforts of some 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 organize a [zoom] party when someone is leaving

People: Signs that you are losing#

  • Great individuals are leaving the team (internal mobility, involuntary attrition, etc.)
  • Team adopts very conservative objectives / team is risk-adverse
  • Team morale is low
  • You have to consistently challenge the team to adopt ambitious/risky goals objectives
  • Team do exactly what they are told to do / no or very limited initiative
  • You have one or more folks on the team with performance problems (negative feedback, coaching not working, personal improvement plan, etc.)
  • Communication is hard, debates are uncommon

Priorities#

The priority component is the one closely associated with product. In general, the product organization is responsible for the prioritization efforts (roadmap, betting table, 6 weeks cycles, etc.).

While it sounds simple on paper, real-life is usually much more messier because the ability to prioritize depend a lot on the strategy and business context (stock trajectory, funding events, pandemic, economic downturn, etc.). None of these are actually a product responsibilities.

From personal experience:

    smaller structure 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 join it is necessary to have a strategy in order to empower teams to make good and high-quality decisions.

      Larger structure may have a high-level strategy that is, in practice, useless for your team: you will need to fill the gaps and decline the strategy into product principles that are meaningful for the product teams you are working with. You need to validate with the stakeholders before you can own any prioritization efforts.

      A team without priorities behave erratically and has almost no impact with every player playing for its own benefit (local optimization) and is ignoring the big picture (global optimization).

      Citing here verbatim my wonderful CEO Karen: Nothing is worse than a team running around like chickens with no head. This is part of ShipperHQ Unflingchingly Honest value and yes, I am quite sorry for this bloody analogy!

      As a Product Manager/Leader: This is your core responsibility! You have to make sure every effort is done in order to accomplish something meaningful for the business at the global level. Your main tool to align teams is the prioritization of efforts.

      Priorities: Signs that you are winning#

      • Everyone in the team has a good-enough understanding of the high-level company strategy and can connect the dots with their 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 every sprint / remains stable for 6–12 weeks (depending on your prioritization process)
      • Retrospectives consider the priorities and look back

      Priorities: Sign that your are losing#

      • Highest Paid Person Opinion (HIPPO) syndrom: The team(s) do not decide. Everyone waits for the highest paid person to decide. It may well be you for some key decisions…
      • Decisions are made ad-hoc, seldomly documented without any framework or reference to company or team priorities
      • Everything is urgent and important: reactivity is the driving force. When the CEO, a VP, a customer is angry then we do something otherwise … we wait.
      • Priorities change every week: If your priorities change often, then, everyone will stop paying attention.

      Process / Agile Rituals#

      In the world of Agile, processes have usually a 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 forcing function to implement a process. Change your view point and language and … go improve your rituals!

      Processes can be documented or undocumented. They can also be deeply ingrained at the organization level and part of the organization culture. They are notoriously hard to change globally without using authority and quite easy to change locally.

      If you have no authority on other crafts or teams (which is the case for most product manager), your main 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 hel[p them improve the processes they are responsible of. Think locally so that you can have a global impact … via a serie of successfull experiments.

      Process: Signs that you are winning#

      • Reporting is high-quality, consistent and well understood inside the team but also all along the hierarchy (up to the CEO)
      • Escalation is working well and stakeholders are rarely surprised by key decisions
      • Most process changes come from the team and are not imposed by management
      • The team has strong rituals & tools that are stable over time (not changing tools, method, process every sprint!)
      • The team measures success or failure systematically (in the absence of measurement, it is impossible to define if a process is good … or bad!)
      • The team delivering the quality experiences they agreed to ship (minimal quality for POC → usable for MVP → production ready for new launches)
      • You can move and iterate fast (it really depends on your industry and company size)

      Process: Signs that you are failing#

      • The team does not spend time improving their rituals/process/tools
      • Onboarding is slow/hard/costly for new employees: they don’t know how it works and nobody can tell them!
      • No learning loops and no retro
      • Processes starts and stops at the departments limits: Prod/UX/Eng. A good product requires a great holistic user experience. The same team should be involved from beginning to finish
      • Very complex processes/toolkit/stack/information system (complexity is relative to your business domain: some industries are heavily regulated while other are more lightweight)

      What should you fix/focus on first?#

      I would argue here that you should always work your way through the pyramid: 1 — People. 2 — Priorities and 3 — Process.

      This is based on two well known mental models:

      1. Agile: The first tenets of the Agile Manifesto is very clear: ”People and their interactions over process and tools”
      2. Modern product development: the organization express a “commander’s intent” and define a priority so that the team can own the problem space, discover problems/solutions and make progress toward the desired goal(s) (outcomes).

      Why starting with People?#

      As a manager, if you can not make it work with one of your report, what are the chances you can succeed? The responsibility to work well together is your report main job. Clarify this early on and help your reports adapt to to your management style by providing regular feedback (1:1 and direct messages), creating your own manager cheat sheet, sharing your psychological profile and, more generally, make explicit your expectations to your reports.

      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 to have 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 report on the right seat … for them and for the company. This is hard emotional work that you have to overtake 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 report. Because you are not part of the reporting structure for this person, lots of folks will be comfortable sharing with you what they are not sharing with their managers or this person’s manager. Be careful not to propagate gossip: form your own opinion via your direct interactions with this person or via your direct reports. Ask them to come up with solutions and proposal to improve the situation.

      Consider a sport team analogy: multiple coaches are in charge of different aspects of the game. For instance in Rugby you have a forward coach, a back coach, an offensive coach, a defensive coach, a kicking coach, a mental coach, etc. Even with all this resources available, a people problem can derail the best possible sport 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 on the right seat: no exception.

      Once you have decided that this person is a problem and is not on the right seat, use the feedback loops that most organization have build: impact review, 360 review, solicited or unsolicited feedback.

      Make sure you express yourself and signal what you consider a major people problem to this person’s manager especially if it hinder the team’’s performance (and/or if you receive complaints from your reports!).Reach out to this person manager and share your views, come up with proposals and possible solutions.

      Why Priorities before Process?#

      If you can not establish a vision/mission for your team and then get this endorsed by your organizations (up to the CEO generally!) them I would argue that you should not invest into optimizing process.

      Why? Don’t even try to set-up a process while a few HIPPO are calling all the shots. This is the process. Changing this process require to align with the stakeholders and come-up with a different prioritization framework.

      You can improve, at the margin, the delivery process and some of the other process but, in my experience, you will face the same hurdles as for the prioritization process: HIPPOs that have set-up this process will be very reluctant to let “their” system/processes change and evolve.

      At a certain point, if you can not define 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 decide where the team is going next. You should either implement a prioritization process or … find another company.

      You may need to do extra-work to get to a point where you reach strong alignment: this is high-leverage and high-impact work. Don’t hire a consultant, don’t try to outsource this but use your product knowledge and management skills to help define your team’s vision and ownership.

      How to define priorities?#

      This is a hard one and numerous books have been written. This is not a definitive answer but it contains some useful pointers.

      Usually the prioritization process involve both long term goals (Mission, Vision) and a fixed timeframe (Year, Quarter, 6 weeks) and require the team(s) to review their backlog to balance somehow:

      • Net new features / product lines / big bets
      • Iterations
      • Tech Debt / Scaling projects (assuming growth and product market fit)

      Each team/business unit/company is at a different stage and the repartition of these efforts may vary widely even within the same organization. The business needs drive these efforts.

      Product Manager are usually key players (if not the leaders) of the prioritization efforts.

      Conclusion#

      This simple framework (People — Priorities — Process) is quite powerful in key situations like:

      • when you join a new organization
      • when you are not pleased with your team performance

      By applying it consistently (at any level: whether you are the most junior or senior member of the organization), you will have a unique point of view that enable you to have dispassionate conversations about any problem you want to fix at any level within the organization (from teammates to the CEO).

      It will also prevent typical mistakes like:

      • trying to fix a People problem with Process changes
      • trying to define the perfect system (Process) while priorities are changing every week based on various HIPPOs.
      • changing a tool and hoping for a people behaviour change, better process or better prioritization

      Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts

      Two ways to share your thoughts with me: