Thinking Like a Leader — Part 1 of Becoming a Product Leader
This is Part 1 of the “Becoming a Product Leader” series. In this series, I’m tackling different outcomes and traits that individual contributor Product Managers can practice and cultivate to become a Product Leader. This article focuses on shifting one’s perspective from a team level Product Manager to an organization wide Product Leader.
The biggest obstacle I faced when trying to move from Product Manager to Product Leader was my own mindset. I had a number of attitudes and beliefs that were counterproductive and held me back:
- Leadership is responsible for solving organizational problems and strategy. I’ll take on these kinds of initiatives when it’s my job to do so, or if it means I’ll get promoted.
- How am I supposed to drive these initiatives as an IC? There’s so much uncertainty and I don’t have the authority to change things.
- I can’t focus on organizational initiatives, I have a responsibility first to my team.
You may or may not suffer from any of these misconceptions. But I’ve seen other experienced individual contributors making the same mistakes, banging their heads against the ceiling of management and leadership.
Changing my perspective was difficult and is an ongoing struggle. But pushing myself to a new mindset has made all the difference in my ability to be a leader.
Leadership is responsible for solving organizational problems and strategy. I’ll take on these kinds of initiatives when it’s my job to do so, or if it means I’ll get promoted.
Don’t Wait to Be Invited
People can hold themselves back by thinking it’s not their place to take on organizational initiatives. Whether they think it’s not their responsibility or not in their authority, they can find reasons not to try to tackle large problems.
For a while, I had a pretty rigid hierarchical view of how organizations worked. I believed that each role had a specific area of responsibility and authority, and operating outside of those bounds wasn’t appropriate. So when I saw problems in organization wide strategy or gaps in major processes, I’d complain to my manager or leadership.
And I got frustrated, because the problems would generally persist, and it felt like nothing that I said mattered.
More than anything, my beliefs about having the authority to drive large initiatives was holding me back. I had no problems driving changes for my team or even working with my peers to make small changes in our process. But larger, organizational changes felt outside of the authority of a simple team-level Product Manager.
Talking to my manager and other leaders helped me to challenge this thinking. Yes, there were some decisions that would be difficult to involve myself in. But there were countless other initiatives and problems that needed driving that any individual could take on.
And there wasn’t any magical authority that came with moving up to a higher level that suddenly changed how things needed to get done. I wanted to be in a position where people would have to listen to me. But being a great leader isn’t about relying on your title to ram changes through; it’s about building trust through effective collaboration and swaying hearts and minds to align on goals and a direction.
It was obvious in hindsight, but it was helpful having someone point it out to me: I didn’t need the title to do the work.
But why should I take on all this extra work if I couldn’t be certain it would mean a promotion?
Don’t Look For Guarantees
Moving into a leadership position can require taking on a number of responsibilities above and beyond your day to day role. And few people embrace the idea of doing extra work without some kind of compensation and recognition. I often looked at it from a transactional perspective: if I did this work, was I going to get promoted? How many features did I need to launch? How many initiatives did I need to drive? How many people did I need to mentor?
It usually doesn’t work like that. Your manager and senior leaders won’t make such promises, because 1) these roles are filled based on business needs, and 2) just because you checked some boxes doesn’t mean you've proven you can thrive in the new position.
People need to trust that you have the attitude, aptitude, and capacity to be great at the next level. They need to believe that they should continue to invest in you. There are a lot qualities that your leadership team is looking for. Many of which they won’t or don’t know how to articulate. Doing the work provides an opportunity for you to actually discover, practice, and demonstrate those qualities.
And if you really want to be in the role, you should want to do the work. If your only interest in taking on a complex cross-organizational initiative is to have the title, then you’re going about this backwards. Moving into the role makes those kinds of challenges your job. If you don’t enjoy mentoring and coaching other PMs, why do you want to be a manager? If you don’t embrace the value and impact of driving alignment with multiple leaders, why do you want to make that your day to day responsibility?
If you want to do the work, you should do the work.
How am I supposed to drive these initiatives as an IC? There’s so much uncertainty and I don’t have the authority to change things.
Embrace the Uncertainty
The initiatives and problems you drive as a Product Leader are much more complex, much less certain. Building confidence and alignment across an organization in the face of such uncertainty is difficult. But it’s all the more important because of that uncertainty.
When taking on larger initiatives — whether new product discovery, a major operational shift, or a change in strategy — there is not going to be an obvious right answer. You may never know the correct answer. No one will. But a plan needs to be made, and the job is creating and selling it in a way that folks will believe in it.
On larger organizational initiatives, you will rarely be able to get to the same level of confidence as you were able to reach at the team level. There are too many variables. Once you involve multiple products and multiple teams, the complexities increase exponentially. Greater dependencies between teams means reduced confidence in technical approaches and delivery dates. Making a change to your product offerings can have ripple effects on customer purchasing decisions.
Driving bigger changes means accepting you won’t have the perfect data to justify a decision. Instead, it increases the need to build confidence in that decision across an organization.
Collaborate to Build Confidence
Collaborating with more leaders reduces uncertainty. It increases the likelihood that a plan will succeed. And critically, it increases other people’s confidence in the plan.
As a seasoned Product Manager, you should have honed your product instincts to identify major opportunities and risks. Other leaders across your organization likewise will have built up their own instincts that you should leverage.
Their instincts and experience can help fill gaps in your knowledge or identify risks that you didn’t see. They’ll connect you with data or individuals who can answer critical questions. And they’ll help you build a stronger case to get buy in from other stakeholders and the leadership team.
Effective collaboration is the foundation for the success of any major initiative. And the bigger the initiative, the more important that collaboration is.
I can’t focus on organizational initiatives, I have a responsibility first to my team.
Prioritizing the Team and the Organization
Leaders often have to make hard prioritization decisions that impact multiple teams. Sometimes one team’s goals has to be deprioritized in favor of a more critical organizational goal. It’s not pretty, and it can hurt morale— but it sometimes needs to be done.
Learning how to balance the needs of the organization against the needs of your immediate team can be a difficult challenge. But your job isn’t just to be a great Product Manager for your team; it’s to be a great Product Manager for your organization. As a Product Leader, you need to prioritize your time and your teams’ time wisely to ensure the highest impact for the business and your customers.
There are two key challenges here:
- Putting the organization’s objectives ahead of an individual team’s objectives.
- Balancing your time and effort between serving the organization vs. serving the team.
Prioritizing the Roadmap to Serve the Organization
There are often opportunities to support goals that don’t directly benefit your team, or slows your team down from achieving its goals. But taking these opportunities can drive better outcomes for the business, rather than if every team operated selfishly towards their own goals.
My team was working on a brand new product area, while most of the rest of the organization was working on unifying our core products. Our project was new and shiny, serving the goals of exciting our customers and driving new business opportunities. By contrast, the rest of the org’s work was less glamorous, but absolutely essential to the overall success of the business.
One of the teams we were partnering with — and were heavily dependent on — was falling behind on its roadmap. This team’s product area was a foundational piece of the unified offering, and a platform on which many other teams would be developing.
We could have protected our own goals and roadmap — eating down other features in our backlog while we waited for them to catch up, or building on their platform with narrowly scoped solutions that worked only for us. Instead we collaborated with them to take on several initiatives that unblocked our team but would also serve to expand their platform for other teams.
We cost ourselves some of our velocity towards our own goals, but we accelerated adoption across the organization. And we demonstrated that we could put the good of the organization ahead of ourselves.
An important part of making this kind of decision is being highly visible. Your manager and leaders should have insight into the decision making process to ensure that this is the best course of action for the business. And your leaders should be fully aware that you’ve put the needs of the organization first.
Prioritizing Your Time to Serve the Organization
As a Product Manager, it can be difficult to move your focus away from the team and towards side projects. But your time is a valuable resource and prioritizing that time ruthlessly is a necessary part of being a Product Leader. Over-investing in a single team becomes a waste of your skills as you grow more seasoned and capable of impacting an organization.
I had to find my own balance in taking on side projects for the organization and doing the work for my team. As the PM on a team, you need to continue to deliver results and ensure progress and challenges are communicated up to leadership. But a lot of the invisible work that PMs do to ensure the success of the team can become unnecessary or even counterproductive. In my past, I’ve pulled a lot of teams together through grit and duct tape. I’ve been the definer, driver, and maintainer of processes that kept the team moving fast. I’ve done a lot of QA to ensure features were delivered with high quality. I’ve pulled data to make decisions on minor interactions. At a certain point, all the extra work starts to have diminishing returns.
Additionally, taking on too much responsibility can actually hamper the team’s ability to succeed. You don’t want to be the bottleneck for every minor UI decision, or not be able to trust your devs to make sure that their work meets the design and acceptance criteria. You don’t want a release to become chaos just because you were out sick. You can infantilize a team by taking away all responsibility outside of committing code. Instead, aim to find a balance that ensures the whole team is responsible for the success of the team and the product.
When my team shifted from product discovery and prototyping to production of a beta MVP, I made a decision to be less involved in the details. This meant putting the responsibility of defining and maintaining processes on the developers. I set high level expectations and provided feedback, but left it to the team to work out how they wanted to operate. This resulted in a lot more sprint iterations to find the best way forward, but it empowered the individuals to own the process and the improvements. Likewise, I tried to find a balance in the detail of my specs and in answering questions vs. ensuring everyone understood the customer problems we were trying to solve and trusting them to come up with good answers on their own.
This is an entire topic of itself, but I sought an approach of “minimum viable product management” for day to day execution. I did enough to ensure that the team and product would be successful, without chasing the last 10% of optimal product execution. It wasn’t easy to find a balance, but my team was understanding. They respected and appreciated that I was trying to drive larger improvements across the organization, and many of the devs on my team appreciated the opportunity to take more ownership.
Summary
I had to shift my perspective in a number of ways before I embodied the qualities of the kind of leader I wanted to be. And it’s still a struggle. I can fall back on bad habits and negative mindsets. But I have a constant intention to live these values — to be more empathetic and collaborative; to embrace uncertainty; to take on the challenges that need solving. And this intention has changed the way that others see me and how I see myself.
Each individual will face their own internal struggles in becoming a leader; these were mine.
Next in the series, I start digging into the actual outcomes and impact you should aim for as you transition to Product Leadership. Next up, Driving Business Outcomes and Impact — Part 2 of the Becoming a Product Leader series.
Do you have similar stories in shifting your perspective to be more effective as a leader? Are there are other mindsets that you think are worth calling out? Please share them in the comments! And be sure to follow me if you want to stay updated on future articles.
