FUNDAMENTALS OF PRODUCT LEADERSHIP: FROM STRATEGY TO ACTION
A product leader’s guide: from product strategy to execution and outcomes
Once a product vision and strategy are in place, product leaders need to execute the strategy and create value. To succeed with execution, there are 10 steps and principles that product leaders should consider:
1. Build your empowerment mindset
2. Provide ample strategic context
3. Set relevant ambitions for each objective
4. Assign objectives
5. Help teams construct Key Results
6. Align teams and KTLO
7. HICs are to be addressed
8. Improve collaboration via shared objectives
9. Actively manage teams
10. Hold teams accountable, but help them grow
The 12 rules of managing teams using OKRs
Product leaders must move from product vision and strategy to execution and implementation. To succeed in this transition, it’s essential to utilize techniques such as OKRs to build empowered product teams that consistently deliver outstanding results.
To succeed with OKRs, below are 12 essential guidelines for product leaders:
- Objectives need to be directly linked to the product vision and strategy (which they in turn link to corporate and business strategies)
- Objectives need to empower teams by giving them problems to solve and being outcome-driven and not output-oriented
- It’s best to match a team’s motivation and passion with an objective, although this may not always be possible
- Objectives should be for the whole team; having separate objectives for managers and individuals, for example, will only create confusion and reduce team effectiveness
- The product leader bears the ultimate responsibility of choosing and assigning objectives to teams, while the team comes up with its key results
- For meaningful key results, teams need to know the level of risk they are taking on and how ambitious they need to be (e.g., ‘moon shots’, ‘roof shots’, High Integrity Commitments, or Keep The Light On)
- Teams need to understand that they will be held accountable for achievements on their Key Results — however, failure is not the end of the world but an opportunity to learn and grow
- It’s normal to negotiate over OKRs — it’s a back-and-forth process that requires product teams to understand the strategic and business context for buy-in
- When Key Results are set in, the role of the product leadership is to coach and actively manage teams, facilitate resolutions to issues, bottlenecks, and dependencies, and improve collaboration levels. The more product leaders stay away from a team’s daily operations, the better the team perform
- Multiple teams can share or have the same objectives, especially when solving complex problems
- Objectives are set for +12 months, while Key Results are to be revised every quarter
- While empowerment and OKRs are important to meaningful value creation, product leaders need to plan for Keep the Light on and High Integrity Commitments
From product strategy to action
Once a product vision and strategy are in place, product leaders need to execute the strategy and create value. To succeed with execution, there are 10 steps and/or principles that product leaders should consider:
- Build your empowerment mindset
- Provide ample strategic context
- Set relevant ambitions for each objective
- Assign objectives
- Help teams construct Key Results
- Align teams and KTLO
- HICs are to be addressed
- Improve collaboration via shared objectives
- Actively manage teams
- Hold teams accountable, but help them grow
1. Build your empowerment mindset
Tasks, projects, and work need to be assigned to product teams in a manner that empowers them and that’s where team objectives play a significant role. Team objectives empower product teams by:
- Giving them problems to solve rather than features to build, and
- Explain to teams the necessary strategic context of why a problem has been chosen so that they can make value-creating decisions
This means that product leaders need to give product teams
- Clarity about the problem space, and
- Give them space to come up with solutions to the problem
This is an outcome-driven approach that is in contrast to traditional feature or output-driven roadmaps that deny problem-solving opportunities from product teams and relegate them to support roles.
This means that in action, for example when there is a need for a mobile app, rather than telling product teams to build one, it’s important to provide them with the problem and context and let them figure it out
Product leaders must empower teams because:
- Those best positioned to determine how to solve a problem are closest to the customers (i.e. the team) and carry a variety of skill sets across design, user research, product development and delivery, project management, marketing, etc.
- With outcome-oriented objectives, the initiative and responsibility are taken by the teams
- If teams are told which features to build, and if those features fail, it would be difficult to hold teams accountable
- It will make teams feel ownership of their work
- When features do not deliver the desired goals, objectives, and key results, then the team will still have the motivation to iterate, experiment, and push forward
2. Provide ample strategic context
If we are to give product teams difficult problems to solve, it’s crucial to give them strategic insights and context needed for decision-making. This will require the product leaders to clearly and fully deliver the product vision and strategy to their respective teams so that they:
- Have a deep understanding of their ultimate goals and why the goal and the problem they are solving are important to the organization
- Build insights and figure out how each could contribute to solving the problem
- Plan their work, understand implications, realize dependencies, etc.
- Can contemplate the problem space and choose those that they are more passionate about so that we can build teams that are on a mission
With the context provided, it’s time to assign objectives to problems and teams.
3. Set relevant ambitions for each objective
Product leaders are portfolio managers, they manage risk
When giving product teams objectives, product leaders are placing a series of bets based on risks they perceive each team or project will bear. Therefore projects will fall somewhere within the low-risk-low-reward (i.e., roof-shot) to high-riks-high-reward (i.e., moon-shot) risk profile.
Bets made on each project will depend on the people, technologies, changing competitive and market environment and customer behavior, and the strength of the insights that the product strategy is built on.
Furthermore, based on the importance of the project (e.g., high churn rates), product leaders can choose multiple teams to tackle the problem from different angles with varying degrees of risks and outcomes. The degree of risk a product teams take can be defined as that team’s ambition levels (i.e., roof-shot to moon-shot) and it’s important that product leaders clearly define and communicate it with their respective teams.
There’s an agreed consensus that roof-shot projects refer to a conservative result deliverable such as optimization work while moon-shot is a 10X improvement, breakthrough, or disruptive project that will result in exponential growth. It’s advised to attach an expected level or percentage of achievement to every project so that teams and the larger organization understand the associated risks and align expectations. For example, while a roof-shot project is expected to have 100% achievement, a moon-shot project may only be expected to achieve 70% of its KRs.
It needs to be mentioned that a product team’s ambition is about being aware of the risk the team is taking and managing it, which is different from having a sense of urgency or putting a lot of effort into work, which is mostly related to the team/organization’s culture.
In essence, teams that work on “roof-shot”s are different from those on “moon-shot”s in terms of their skillsets, age, and the nature of techniques and processes they use for product discovery.
4. Assign objectives
While the specifics of objectives will differ based on the function, nature, and business context of the product and the responsibilities of each team, good objectives have the following characteristics:
- They are about problems (outcomes) and not features (output)
- They are all qualitative
- They require the product teams to collaborate with other teams and functions for success
- They have many potential solutions
- They are the result of a back-and-forth interaction between the leader and their teams so that all parties are fine with the wording, scope, context, emphasis, ambition, specificity, etc.
Examples of such objectives include:
- Grow the number of unique users
- Increase customer engagement/purchase rates
- Reduce customer churn rate or increase retention rates
- Grow basket size per unique user
- Grow the lifetime value of the customer
- Grow referral rates
- Reduce customer acquisition costs
- Reduce time to fulfillment
- Reduce average onboarding time
- Reduce the time needed to deploy new features
- Reduce time to first purchase
Therefore, objectives are high-level and can be quickly grasped with little cognitive load. Assigning objectives to teams is a delicate process and is built on 3 principles:
- First, it’s the responsibility of the product leader to decide which problems need to be worked on (product strategy) and by which teams (depending on team topology or scope). Therefore, it’s the responsibility of product leaders to assign objectives to teams and not the other way around — meaning that asking teams to come up with their objectives will result in a lack of direction and results
- Second, the goal of assigning objectives is to align teams with respective product strategies. In other words, objectives are set to connect teams to product vision and strategies
- Third, assigning objectives to teams is not a top-down process but an iterative top-down-and-bottom-up one whereby teams buy into their objectives
Regarding the first point, it needs to be noted that there may be times when teams are motivated to pursue a certain problem and while that is welcomed, it’s still the product leader that should make the final decision based on priorities, resource availability, and team topology.
When the objectives are set out for teams, it’s time for product leaders to collaborate with teams on assigning key results.
5. Help teams construct Key Results
While the objective defines the problem to be solved, the Key Results define success from the lens of business results (e.g., 20% growth in subscriptions) and not by activity or outputs (e.g., number of tests run or features launched). And the reason is that it’s quite easy to curve out work for people and ship out features and not solve for or improve on any meaningful business metric.
Characteristics of great key results include:
- They are quantitative and mathematically specific
- They are timebound with realistic deadlines
- They are set in place because it's easy to measure them but rather because they are meaningfully impactful to the business
- Each objective will need 2–4 key results. One (or a maximum of two) of the key results is the primary measure of success and the other key results, called backstop KRs, are measures of the quality and health of the success of the primary measure; meaning the success attained in the primary measure has not come at a loss on some other outcome
For example, imagine the objective of growing overall revenues from podcasts on Spotify. The key results for this objective could be:
- Primary measure: Grow podcasts revenues in the coming 6 months by more than 15%
- Backstop 1: Grow the total hours listened to podcasts in the next 4 months by more than 10%
- Backstop 2: Grow the average revenue made per listening minute on podcasts by more than 5%
- Backstop 3: While not resulting in a reduction in time spent listening to music
- Backstop 4: While not growing costs that decrease net podcast profits
When building the above key results, very similar to the case of the objective, all aspects of the success factors and measures including the wording, numbers, timeframes, etc. need to be agreed upon through a back-and-forth dialog and negotiation between the product leader and the product team. This will ensure buy-in, motivation, commitment, accountability, ownership, and proactivity from the team.
In action, product leaders must ensure they check the following 4 principles when assigning key results to objectives:
- First, the Key Results have come from the team (bottom-up) so that members feel ownership of their work and results
- Second, if teams have had previous exposure to similar OKRs, it could be a straightforward process with available know-how. However, if teams are provided new objectives with little organizational knowledge, then some time will be needed to learn the space, collect data, establish a baseline, and get a sense of possibilities for KRs
- Third, product leaders and teams must have a thorough conversation regarding the ambition levels of defining targets and success and the level of risk that needs to be taken. Depending on this conversation the scope of work, number of objectives, and targets can change
- Fourth, while Objectives are longer-term goals, Key Results generally have a 3-months scope of success in mind. If any key result goes longer than that, it’s best to divide it into smaller chunks and have teams account for a smaller deliverable success metric
6. Align teams and KTLO
With Objectives and Key Results in place, product leaders need to:
- Make sure that product teams are aligned with the broader organization such as various platform teams, Sales, Marketing, Legal, Ads, etc. so that all related and involved teams help deliver value to the market
- Teams continue to monitor “keep the lights on” (KTLO) work that can entail fixing critical problems, responding to customer issues, assisting other teams, technical debt work, etc. If at any point KTLO grows larger than presumptions and begins to consume resources, then it might be time to think about growing the team or making structural changes such as the code architecture
7. HICs are to be addressed
While product leaders desire to build aspirational and ambitious visions and goals for their product teams and empower them to solve big problems, there are always cases where teams are required to make High-Integrity Commitments (HIC)— which is separate from KTLO work.
There are occasions for every product team where something important must be delivered by a specific deadline driven by partners, marketing commitments, customers, legal factors, etc. In these circumstances, empowered product teams need to sign on dates that leaders can count on.
It needs to be noted that HIC projects should be the exception and not the norm of projects that product teams have to deal with
However, depending on the complexity and scope of the deliverable, degree of dependencies, or the number of commitments asked, it could be difficult for teams to come up with high-confidence dates and commit to them.
The right way to commit to HICs
In these situations, product leaders need their teams to perform product discovery to determine the risks of the commitment regarding creating value, usability, feasibility, viability, and ethics. The output of this product discovery exercise should be a prototype that can help scope the commitments and make estimations realistic and with the utmost integrity.
The right way to track (HIC)
Furthermore, when the commitment is made, delivery managers need to track the progress of work separate from the usual OKRs that the team has set out for the year and every quarter. And at the sign of trouble in meeting the timeline, teams need to raise issues with product leaders.
Commitment to the delivery of a HIC project is highly dependent on the technical leads and they should scope, assess and commit to timelines. Team leads should use HIC projects as opportunities to build trust with leadership and ask for more ownership, empowerment, and accountability.
8. Improve collaboration via shared objectives
There are situations where multiple product teams are required to work on the same objectives. To maximize autonomy and empowerment and minimize communication confusion and conflict, product leaders need to clarify situations where multiple teams have either shared or common objectives.
Shared objectives
When solving complicated and challenging problems, large initiatives that require many resources, or problems that require various skill sets to combine for resolution, multiple product teams could share objectives.
For example, when an experience and platform team come together to deliver a new experience in the form of an API and each side works on their side of the project before joining collaboration on testing and final delivery. In these situations, teams tend to collocate in settings called swarms for intense collaboration and deep dive into product discovery and delivery.
In such circumstances, it makes complete sense to have shared objectives among the teams so that they work towards delivering the same outcomes.
Common objectives
This is when multiple teams have the same objectives as each pursues to solve the same problem but in their manner. This is used when product leaders are ambitious in solving high-risk problems and the solution is not clear and they are trying to tackle the problem from different angles. For example, when user churn rates are high, there could be several reasons that require multiple teams to work on solutions from various touchpoints.
In these situations, the teams need to communicate transparently to minimize conflicts, however, it’s the responsibility of the product leader to divvy the teams and set objectives so that independence is maximized.
Furthermore, product leaders need to clearly define the attribution of progress and every team’s share of it, and how they will be held accountable. Product leaders need to find logical and acceptable ways of dividing team contributions to the progress and the best methods are generally outcome or customer related such as traffic changes and the source of that change.
9. Actively manage teams
With OKRs and other tasks in place, product teams need to continuously track and managed their KRs and their performance. To best manage responsibilities, product teams:
- Need to stay on top of their KTLO and HIC projects
- Depending on the type of work and speed of progress, product teams should have weekly check-ins for what they achieved the previous week, what is upcoming, what they hope to achieve, and the potential need for leadership help. This could happen during a standup, or among team leads and can vary depending on the type of project; that is for product teams to figure out
- To stay on track, teams must communicate issues, risks, and dependencies with their leaders and ask for ongoing coaching on the job so that they develop
- Inner team coaching is also important — hence product teams should have active sharing of learnings with one another and help each other achieve team goals and objectives, whereby all succeed or none do
10. Hold teams accountable, but help them grow
Empowered teams should be held responsible and accountable per the degree of ambition and risk they have taken. This means that failure is acceptable if their OKRs were based on high-risk projects and difficult problems to solve while — for example, with HICs, very little failure is accepted.
Product leaders need to understand that failure at empowered product teams should be treated as a learning and growth opportunity. Therefore it’s important to have OKR post-mortem meetings for coaching, team development, and organizational growth.
Hope you enjoyed reading this article! :)
If so, then:
- Follow me on Medium
- Become a Medium Member
- Subscribe to hear more
- Let’s connect on LinkedIn
