Lead your product team to 4 levels of ownership
Product Managers are often described as being the "glue" between engineering, design, and business ... but this is the WRONG mentality. This mentality leads to a Product Manager becoming a bottleneck of information. There are 2 universal truths (A) people don't want to be micro-managed instead want to be empowered, and (B) when people feel responsible and take ownership it leads to better outcomes.
During my first Product Manager role (after being a consultant for multiple years), I wanted to be valuable by being this "glue" by communicating and structuring information between our engineers, designers, and CEO. I found that I was busy and my team always relied on me, but I worked many hours and didn't actually get much done. Most of my work was on execution and not on strategy; without me, my team wouldn't be able to operate. I ultimately learned I needed to leverage my time on more future-looking strategy and experiments while empowering my team to own the day-to-day execution decisions without me. This paid dividends as we pivoted our company during the pandemic which increased our revenue by about 400% in 1 year which would have been unlikely if I was still a bottleneck.
We can adapt the 4 levels of ownership (framework I used while I leading consultant teams) to lead successful product teams. You want to empower your team to master these 4 levels of ownership so you can transition from less execution and more strategy tasks.
These levels of ownership are universal to any role but can be applied directly with Product Managers who indirectly influence multiple teams. Product Managers have the unique role to communicate with more departments and layers in the company compared to other roles. Thus Product Managers have the ultimate responsible to drive these 4 levels of ownership across the company.
Level 1: My owns tasks / project
When someone feel responsible for completing tasks.
Some examples from developers, designer, or business stakeholders,
- Wanting to know how to do personal tasks successfully
- Focusing on how to grow their skills relevant to product requirements
- Asking for clear product functionality, user flow, and instructions (e.g., engineer asking to confirm details in a user story)
TIP 1: Documentation
Typically Product Managers receive a lot of inbound requests from customer support, sales, marketing, or engineers. If you find yourself spending a lot of time responding to similar requests or giving updates on the status of a task, then good documentation can save you a lot of time. Good documentation (both internal and external) means less time answering questions and instead redirecting towards documentation. It is critical to set your documentation in a clear structure so that others know how to easily find and add to.
For example, as soon as I received similar questions from a customer or customer support, then I would create a knowledge base document for them and setup some automation with a chat bot in our application to reduce support tickets. requests mean PMs spent a lot of their time sorting, triaging, or answering requests. When our data science team had lack of clarity about some technical details related to our platform, we created an expectation for our engineering team to create and maintain proper documentation on core infrastructure items. For bigger, longer-term features, I would often create details user-flow diagrams and core principles / metrics so that the development team could reference and answer their own questions.
Level 2: My own results
When someone feel responsible for the results / outcome of work. Seeing the impact of one's work is also fulfilling and brings more meaning to one's work as well.
Some examples,
- Wanting to know the result they need to achieve for product's success (e.g., engineer asking how responsive a feature should be)
- Focusing on finding effective ways and making suggestions to create desired outcome (e.g., designer suggesting feature or alternative user flow to improve a core metric)
- Asking for clear goals and targets from Product Manager
TIP 2: Metrics
Metrics easily available on a dashboard on a website are valuable for the team to rally around improving key business metrics. Sometimes this isn't always easy because if your team is constantly putting out fires, then it is hard to practically connect one's impact to business metrics. Other type of metrics (outside of core business metrics) are valuable as well -- such as tracking the number of fires put out each month and the number of bugs in certain parts of your product.
Level 3: My work’s impact on other team members
Feel responsible for having a positive impact on other people’s work. Level 3 is one of the most critical for a Product Manager to enable in an organization.
Examples,
- Wanting to know how their role contributes to other teams
- Focusing on communicating interdependencies or relevant items between team members (e.g., developer telling another developer about important change or bug)
- Asking for clarity about team processes and operating rules (e.g., Customer Success synthesizing feedback from customers to Product Marketing and Product Managers)
TIP 3: Daily Stand up / Weekly update
Daily stand ups are a great agile ceremony to ensure blockers are surfaces across the team and teammates are aware of each other's current progress. You don't need to attend these but you want to make sure your team holds these. More details can be found here.
Creating a weekly or bi-weekly update with links, gifs, images is helpful to share progress or new learning with people who are not closely familiar with your team but might ping you for an update. Having this ready-made information makes it super easy to pro-actively share instead of repeating your update.
TIP 4: Public Slack channels
Typically, a lot of information happens in various department silos that would be beneficial for other departments to be aware of. Access to this information helps others make better decisions and understand how their work impacts other departments. Even helpful for new hirers who are ramping up.
For example, customer feedback is some of the most valuable information for an organization to find product market fit or adapt to increase its growth. So I created a customer feedback channel specific to any feedback heard that was helpful to our Product Marketing, Engineering, Designer, etc. I would even directly tag and reference relevant information to various teammates for discussion.
TIP 5: User story sizing
Sizing tasks (estimating how much time is required to complete a task) is not only valuable to inform prioritize, roadmap timeline, and set expectation with external stakeholder, but also for ensuring an engineer critically thinks through all that is required to complete a task.
For example, I worked with some data scientists who would often not plan in advance for what was required to deploy a ML model and a new data connector. This often make those features take longer to launch and impacted other teammates to change their prioritization with short notice. When they started to size their work, this required them to critically think about required tasks and proactively define areas of help needed across the team without requiring me to escalate issues and communicate technical details on behalf of the teams.
Level 4: My product's contribution to the company’s success
Feel part of a journey to achieve a bigger cause, which supersedes personal or team’s work. A product manager should spend more of more mental bandwidth on how product will drive success. During your product career, you want to shift from 80% execution and 20% strategy ... instead to 20% on execution and 80% on strategy.
Examples,
- Wanting to understand in-depth the vision and strategy
- Focusing on knowing the strategic objectives of the organization
- Asking for clarity about the relationship between team’s objectives and strategic objectives (i.e., Marketer asking how a feature will impact a company objective's objective)
TIP 6: Connect everything to OKRs (Epics, Product Roadmap, etc.)
OKRs stands for “Objectives and Key Results.” It is a collaborative goal-setting methodology used by teams to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals. (more details here)
I have found that tying these together simplifies prioritization and communicating objectives across the team (from developers to business leader). For business stakeholders, tying priorities to OKRs saves me time to answer questions regarding how we will improve company objective by sharing our product roadmap (tied to objectives) -- the conversation turns more into what Epics or features should we prioritize based on their impact on business objectives (more valuable). For developers, tying tasks to an objective makes the work more tangible on its company on the company's growth.
--
Most of us tend to focus on our own job (level 1 & 2 ownership). However, the more we can improve autonomous collaboration tied to business objectives (level 3 & 4 ownership), the more effective the team can be without a PM being the "glue" / bottleneck.
Other helpful links on how to empower your team,
