What Does a Product Leader Do?

So far, product leadership has been much less covered than product management. The role and how it varies between industries and companies are still poorly defined, including the skills required, the best practices and so on.

What are product leaders, what are their responsibilities and job titles? Predictably, the answer to these questions varies from company to company, as does the already quite variable role of the product manager.

Introduction

Factors that influence the state of product leadership and where it might be located in the company are organizational structures, company size, type of product, company culture and processes.

Notwithstanding these, a pattern we can see is:

• In younger startups, the CEO is generally the only product leader,
• in bigger startups, this role already shifted to a first product manager,
• In even larger ones, this role is held either by a head of product, VPs, directors of product and design, or CPO,
• in other companies, it might be product marketing managers or engineering managers.

Where does product management end, and product leadership begin?

The product manager role, while typically doesn’t come with line management responsibilities, also requires some leadership skills. It’s a confusing aspect of product leadership and a defining factor for what it means.

Certain activities and responsibilities that are required to successfully build a product and improve it in the long term are typically out of scope for individual product managers. They are part of the product leadership role, and whoever takes on a product leadership role needs to deliver on these responsibilities to be effective.

These responsibilities of product leadership can be divided into three broad areas:

• Owning the product direction
• Hiring the product organization
• Establishing the product processes

Let’s briefly summarize each of these areas of responsibility, and consider the following questions:

• How it differs from typical product manager work?
• What it takes to be successful in this area?

Responsibility #1: Owning the product direction

Every day, product managers and product teams take various decisions about how their product(s) should evolve.

However, these decisions need to be aligned with the broader overall product direction. This is essential for the product to :

• be successfully meeting customer needs,
• while being differentiated from competitors,
• and enabling a viable business.

Owning the product direction may be the first area of responsibility for product leadership but it doesn’t mean that every decision on the product direction is taken by product leadership, much less so in isolation. Ultimately, the responsibility implies that product leaders make sure the direction set for the product(s) is well communicated, clear to everyone and internally consistent.

Product direction starts with the product vision

The definition of product vision is one of the core responsibilities of product leadership:

• In startups and “single-product” companies, the product vision often equals to the company vision.
• In multi-product companies, product leadership is responsible to define the product vision for each product. Each product’s vision should outline, in an aspirational fashion, the long-term customer benefits that this individual product aims to provide, without going much into details on how it happens.

Product vision informs the product strategy

Unlike the product vision, the product strategy should be explicit about “how we will win”, and remain stable for time scale from several months to multiple years.

The product strategy defines

• how value will be delivered to the customer,
• how the product is differentiated from the competition,
• and how the business model is.

The product strategy also talks about the target customer group and possibly about a plan for expanding it over time.

Product strategy prioritizes the thematics in the product roadmap

Based on the product strategy, product leadership can prioritize the high-level themes to put on the product’s roadmap. Indeed, product leadership is responsible to decide what product themes must be developed “now”, “next”, and “later”. However, it should NOT drive the lower-level definition of the product roadmap, such as the “feature” level. Rather, this is the responsibility of each cross-functional product team.

Product strategy is then operationalized by settings goals

It’s how we can measure progress towards the product direction set.

For example, the framework of OKRs (aka “Objectives and Key Results”) is considered as a gold standard for goal setting in technology companies. OKRs are set on an agreed-upon frequency (i.e every quarter), at one or more levels, which varies from a company to another (company, department, product, team or individual level).

Product leaders own and drive the definition of product-related OKRs, prioritizing the (business and customer) outcomes to be achieved in the goal-setting period. They negotiate OKRs with the group that will own delivering on them, with leadership and with cross-functional stakeholders.

Beside defining, vision, strategy, and goals also have to be evangelized by the product leader throughout the organization, both cross-functionally and within the product development team. 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.

Product leadership communicates the product direction

Product direction is seldom over-communicated. Even though the product leaders tend to be steeped in it and get it, the rest of the organization should be reminded of it regularly, so that the decisions taken anywhere in the organization will be made with the product direction in mind.

Product leadership guides product decisions with regards to the product direction.

Once the product direction is defined and evangelized, product leadership should provide feedback and guidance on product decisions in terms of how they align with the product direction. To do so, product leaders should give a feedback about the product decisions made, to the respective product managers and the teams in charge, in 1-to-1 or product review meetings.

It’s good to note that when empowered, product teams are free to make their own decisions on how they think they can achieve their goals. Product leaders being often the most knowledgeable about the context of the product in the organization, they are expected to be opinionated about how the product should evolve and interact with the teams. Therefore. product leaders should NOT disappear once quarterly goals are set and only pop out at the end of the quarter.

Responsibility #2: Hiring the product organization

Serving as a guide for the product direction is likely the most high-level and visible responsibility of product leaders. Another one, and probably the most impactful one, is building the product team. Every organization has different boundaries for what constitutes “the team” that product leadership is responsible for building, though.

Reasonably enough. product leadership is often responsible for hiring the product-specific roles, related to:

• Product management (product manager, scrum product owners),
• product design (UI/UX designer),
• UX research (UX researcher).

Setting the hiring process for every product role

Building the team starts with hiring and product leaders have to set up a good hiring process. It means defining a few essential elements such as:

• several clear criteria for “hire” or “no-hire” decision-making
• testing candidates regarding how the candidate might contribute to the team and its culture (commonly, PM candidates meet with team members such as by designers and engineers),
• testing candidates for all the product disciplines involved in the hiring process (many companies require homework assignments/case studies from their product candidates).

Onboarding new “product” hires properly

Once a candidate is hired, they also have to be onboarded. A well-designed onboarding will pay back handsomely, enabling new hires sooner to be operational. Product leaders must spend enough time with new hires to provide context about the product and the direction set, and explaining the processes that were defined, the tools used, and outlining the organizational aspects and the culture of the team.

Making clear what’s expected, and setting career development goals

A good chunk of the work in building the product teams consists of developing the team members.

The best way to start is by setting clear expectations from each team member. Each team member must know what their responsibilities are. The form doesn’t matter though, it can be an agreement between leadership and each team member, a role description or a formal career ladder (which describes required competencies for each level of seniority).

Coming to that, the career development goals should be clear and agreed with each team member. For a long-term fit, they must be based not only on the needs of the company but also on the interests of the individual.

Based on expectations & career development goals, product leadership should spend enough time giving providing feedback, advice and coaching in one-on-one meetings or formal feedback forums.

Foster the right culture for product development to thrive

Another important aspect of building the team in establishing and maintaining the right culture.

• The right culture within each functional team,
• The right culture within cross-functional product teams,
• The right culture across the company.

Of course, product leadership can not change a company’s culture just by itself. Though, it has to be aware of certain elements of the culture that enable an effective product development:

• cross-functional product teams that are empowered to discover and deliver solutions to customer problems,
• a certain degree of failure is expected and accepted by a willingness to seek regular feedback and learn from errors,
• strong ownership of problems is encouraged and the drive to solve them,
• a focus on actual business and customer outcomes over-focusing on making things look good, even if actual performance isn’t good or getting better,
• customer centricity,
• and collaboration/teamwork instead of competition.

Culture, of course, is not something you can simply “set” but product leaders can play an important role at modeling the expected behavior, providing enough constructive feedback on how to improve certain areas, and praising the desirable behavior.

Responsibility #3: Establishing the product processes

The last area of responsibility of product leadership is setting up both of the organizational structure and processes across the different teams involved in the product development.

Typically, formal reporting lines in product development organizations are functional, to enable both discipline-specific coaching and career development (engineers report to engineering managers, designers report to design managers, product managers report to directors of product or similar).

But, the actual work is done mostly in cross-functional teams made of product management, design, and engineering experts. This is what we usually call a “product team”. How these teams are organized varies from a company to another, and defining just that is the responsibility of product leadership.

To do so, product leadership must consider few things:

• How do product teams come to be?
• How long do product teams live?
• How big product teams are?
• What is the process to decide who joins which product team?
• How are objectives or scope of work allocated to each product team?
• Does some sort of super-structure exists on top of the product teams?

Product leadership defines operating “product” processes

In addition to the organizational setup, product leaders must define most of the processes, especially those that are crossing team boundaries.

Firstly, it encompases the processes along the product development lifecycle:

• product discovery,
• product design,
• product development,
• product release management,
• experimentation & validation.

Secondly, it includes the selection of tools to support these processes, for example:

• project/task management (Jira, Trello, Asana, etc.),
• product design & handoff (Figma, Sketch, Zeplin, etc.),
• documentation & knowledge sharing (Google Docs, Confluence, Wikimedia, etc.).

Defining standard while leaving room for self-organization

When defining all the “product” processes, it’s important to leave room for self-organization. Setting some minimum standards is important though, for effective collaboration across team boundaries and allowing team members to change from team to another with minimal adaptation.

For example, it might be required for everyone to manage tasks with Jira so that it is easier to delegate certain tasks to another team (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 because everyone in the team is comfortable with that and it makes sense for the product they are responsible for.

Contextual differences will call for different processes

Indeed, an app that has a web and a mobile version will generally need different release management processes on the web (where deployments many times a day are common and quick feedback is possible) and mobile (where every release has a lead time of several days due to app review and where users only slowly adopt the newest release).

Processes for product direction and team building

The second set of processes are the ones that support the first two responsibilities: product direction and team building.

They include:

• strategic planning & goal-setting,
• functional team collaboration & development sessions,
• feedback on opportunities and solution design by leadership and peers,
• performance management and career development, etc.

Processes to interface with the rest of the organization

The last category of processes that product leadership needs to set up is processes that by their nature span across teams. For example, the processes that involve teams outside of the product development world, such as for handling the requests that come from the sales, marketing or customer support.

Processes for dealing with certain “negative externalities” of teamwork

It includes the processes for determining how to allocate capacity and responsibility to fix bugs, reduce technical debt, or improve the infrastructure or the technical performance.

The themes can be “internalized” to the teams through goal setting, or specific processes or even organizational structures that can be established for taking care of these things.