The Three Responsibilities of Product Leadership
What the heck does a product leader do, anyway?
In the past years, a lot has been written about product management: about the role definition and how it varies between industries and companies, the skills required, best practices and so on. Product leadership is much less well covered, and even less well-defined.
Who exactly a product leader is, what their responsibilities are, and what job title they may have varies even more from company to company than the already quite variable role of the product manager. Org structures, company size, and company culture and processes all influence where product leadership might be located.
In small startups, the CEO may be the only product leader, in bigger ones it might be VPs and directors of product and design. In other companies it might be engineering managers, (product) marketing managers, or general managers.
An additional confusing aspect about product leadership is that the product manager role, while it typically doesn’t come with line management responsibilities, also requires leadership skills. So where does product management end and product leadership begin?
To me, this last question can be used as the defining factor for what product leadership means. There are some activities and responsibilities that are required to successfully and sustainably build and improve a product that typically are out of scope for individual product managers. Whoever has these responsibilities is part of product leadership. On the flip side, someone with a product leadership role (like VP Product or CPO) needs to deliver on these responsibilities in order to be effective.
The three broad areas of product leadership responsibility are:
- Owning the product direction
- Building the team
- Establishing the product organization and processes
In the remainder of this article, I will give a short summary of each of these areas of responsibility, how it differs from typical product manager work, and what it takes to be successful in this area.
Owning the product direction
Every product manager and every product team takes decisions about how to evolve the product almost daily. However, to build a successful product that meets customer needs, is differentiated from competitors, and enables a viable business, these micro decisions need to be aligned with a broader overall product direction. Owning this product direction is the first area of responsibility of product leadership.
Owning the direction doesn’t necessarily mean that all the decisions on the product direction are taken by product leadership, much less so in isolation. However, it’s the responsibility of the product leader(s) to make sure that the product direction is clear to everyone and internally consistent.
Product direction starts with the product vision. In startups and single-product companies, the product vision can often be equal to the company vision/mission. In multi-product companies, it should outline the long term, aspirational customer benefits that an individual product aims to provide, without going into details on how they will be achieved. In the multi-product company case, product leadership own defining the product vision for each individual product.
The product vision then informs the product strategy. Defining the product strategy is one of the core responsibilities of product leadership. The product strategy should stay stable for several months to multiple years, and in contrast to the vision, should be explicit about “how we will win”. The strategy should define how value will be delivered to the customer/user, how the product is differentiated from the competition, and what the business model is. It should also talk more about the target customer group and possibly about a plan for expanding the target customer group over time.
Based on the product strategy, product leadership needs to prioritize high-level themes to put on the product roadmap. Product leadership should not drive the definition of a product roadmap at the feature level; that is the responsibility of individual cross-functional product teams. However, product leadership does have the responsibility to decide what themes to work on now, next, and later.
The strategy is then operationalized through goal setting. Objectives and Key Results (OKRs), often set on a quarterly basis, are considered the gold standard for goal setting in technology companies. At which level these OKRs are set (company level, department level, product level, team level, individual level) varies from company to company. Product leadership owns and drives the definition of product-related OKRs, prioritizing the (business and customer) outcomes to be achieved in the goal-setting period. Defining OKRs is always a negotiation process, both between leadership and the group that will own delivering on the OKR (e.g., the individual team), but also among leadership and with cross-functional stakeholders.
Vision, strategy, and goals also have to be evangelized by product leadership throughout the organization, both within the product development team and cross-functionally. The direction of the product needs to be communicated consistently and frequently to ensure that the whole company is aligned on where the product is evolving, and this communication needs to be tailored to the respective audience. It is hard to overcommunicate the product direction — product leaders tend to be steeped in it and find it clear as day, but for the rest of the organization it is important to be reminded of it again and again, so that decisions taken anywhere in the organization will be made with the product direction in mind.
Another more optional way to guide product decision making as a product leader is to implement product or product design principles. Product principles encode fundamental value decisions and beliefs that make the vision and strategy actionable throughout the discovery, design, and development process. These principles shouldn’t just be general rules and best practices, but they should be specific to the product with its vision and strategy.
Once the product direction is set and evangelized at the level of vision, strategy, goals, and principles, product leadership has the role of providing feedback and guidance on product decisions in terms of how they align with the product direction. Empowered product teams should be free to make their own decisions how they think they can achieve their goals, but that doesn’t mean that product leaders should disappear into a hole in the ground once quarterly goals are set and only reappear at the end of the quarter. Product leaders are often the most knowledgeable about the context of the product, and should be opinionated about how the product should evolve. Product leaders therefore should give feedback about product decisions to the respective product managers and their teams in 1:1s or product review meetings.
Building the team
While owning and setting the product direction might be the most high level and visible responsibility of product leadership, building the product team is probably the most impactful one (at least once you get past the “a handful people in a room” startup stage).
What constitutes “the team” that product leadership is responsible for building, and where are its boundaries? The answer varies between organizations. Often, product leadership is responsible for hiring product specific roles: product management, product design, UX research. The engineering team may be part of the product development team but have its own leadership, especially because the engineering team generally outnumbers the product specific roles (but has to be well aligned with product leadership, of course). Data science / analytics may be considered part of the product development team or be separate in a data team.
Building the team starts with hiring. Without going into too much detail about how a good hiring process looks like, a few essential elements are clear criteria for decision making, testing for how the candidate might contribute to the team and its culture, and involving all product disciplines in the hiring process (e.g., a product manager candidate should be interviewed also by designers and engineers). Many companies require homework assignments / case studies from their product candidates.
Once a candidate is hired, they also have to be onboarded. It is important for product leaders to spend sufficient time providing context about the product and its direction, explaining the processes and tools, and outlining the organizational context and the culture of the team.
The majority of the work in building the team consists of developing the team members. This should start with setting clear expectations what is expected of each team member. It’s not so important whether that is in the form of a role description, a formal career ladder which describes required competencies for each level of seniority, or simply an agreement between leadership and team member — what does matter is that the team member knows what their responsibilities are. In addition to these expectations, career development goals should be agreed with each team member, based on the needs of the company but also based on the interests of the individual.
Based on expectations and career development goals, product leaders then should spend a lot of time providing feedback and coaching in one-on-one meetings or formal feedback forums. A lot of very practical tips and guidelines for coaching product managers can be found on the Silicon Valley Product Group blog.
The last important aspect of building the team is establishing the right culture (within each functional team, within cross-functional product teams, and across the company). Of course, product leadership can’t change the company culture single-handedly, but there are some elements of the company culture that are essential for effective product development: empowerment of cross-functional product teams to discover and deliver solutions to customer problems, acceptance of failure and willingness to seek feedback and learn, ownership of problems and the drive to solve them, a focus on actual business and customer outcomes instead of “success theater”, customer centricity, and collaboration instead of competition.
Culture, of course, can’t be just “set”. The most important part that product leaders can play with respect to culture is role modeling the expected behavior, providing feedback on areas for improvement, and praising desirable behavior. For more information on shaping company culture, check out Ben Horowitz’s book “What You Do Is Who You Are”.
Establishing product organization and processes (across product teams)
The last area of responsibility is setting up the organizational structure and processes across the different teams involved in product development. Typically, formal reporting lines in product development organizations are functional — engineers report to engineering managers, designers report to design managers, product managers report to directors of product or similar. This functional reporting line ensures that discipline specific coaching and career development can happen.
The actual work, however, is done mostly in cross-functional teams consisting at least of product management, design, and engineering. These teams are typically called “product teams”. How these teams are set up and organized varies between organizations, and defining that is a key area of responsibility for product leadership: How do these teams come to be? How long to they live? How big are they? What is the process to decide who goes on what team? How are objectives or themes of work allocated to teams? Is there some form of super-structure over the teams? All of these questions need to be answered by product leadership, and the answers may change over time (especially as the company grows).
In addition to the organizational setup, product leadership needs to define the processes, especially the ones that cross team boundaries.
Firstly, this means defining processes along the product development lifecycle: research and discovery, design, development, release management, as well as experimentation and validation. In addition, product leadership owns the selection of tools to support these processes, for example task management (e.g., Jira), product design and handoff (e.g., Figma or Sketch + Zeplin), and documentation and knowledge sharing (e.g., Google Docs or Confluence). It is important in defining these processes to set minimum standards where it is necessary for effective collaboration across team boundaries and the ability for employees to move from team to team, but also leave room for self-organization. For example, it might be required for all teams to use Jira for task management, so that it is easy to delegate sub-tasks to service teams (for example, an infrastructure team), but it might be okay for one team to operate in sprints and another more in a kanban-style continuous flow. Likewise, sometimes inherent differences in the work of different team will drive different processes: an app that has a web and a mobile version will typically have different release management processes on the web (where deployments many times a day are common) and mobile (where releases have a multi-day lead time due to app review and slow adoption).
The second set of processes are the ones that support the first two responsibilities: product direction and team building. Processes in this category include strategic planning and goal-setting, functional team collaboration and development sessions, feedback on opportunities and solution design by leadership and peers, performance management and career development, etc.
The last category of processes that product leadership needs to set up are processes that by their nature span across teams. One example of processes in these category are ones that involve teams outside of the product development world, such as for handling requests by sales or customer support. Another set of processes that fall in this last category are not about interfaces with the rest of the organization, but about dealing with “negative externalities” of team work: how is capacity and responsibility allocated to fix bugs, reduce technical debt, or improve infrastructure components? These topics can be “internalized” to the teams (for example, through goal setting), or specific processes (or even organizational structures) can be established for them.
In summary, anyone in an organization who owns the overall product direction, builds the product development team, and establishes the product organization and processes is part of product leadership, and anyone in product leadership needs to ensure that they cover all of these areas of responsibility.
I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles about product management and leadership.
