Summary

A new product lead is usually overwhelmed with high expectations and a wide range of responsibilities. Mental models, frameworks, technical knowledge, and domain expertise are certainly important during this transition, but the skills of persuading, aligning, and building decisions in a fast-paced environment can be much more important to keep your mind sane and make you more effective in this new position. In this post, I share some of the challenges, learnings and reflections from my journey in a new product leadership role.

About this

I wrote most of this post when one of the PMs at my former company (Geekie) started her path of leading higher-impact projects and Product areas. She was asking herself the same kinds of questions I faced myself some years earlier, so I tried to put together my thoughts about the biggest challenges that I've faced, and my learnings from my experiences. I tried to organize these as a set of general principles and areas to reflect and diagnose where you can be more effective when responsible for a "product strategy”.

Maybe these learnings can be valuable to others in similar transitions, so here's my attempt to share those ideas. This is also an early experiment of trying to organize and share more learnings and thoughts from my years building Product. I spent 10 years living a complete cycle of a startup at Geekie, and I'm trying to organize my notes, thoughts and lessons from this period.

If you find some of these thoughts and ideas valuable, let me know, I'd love your feedback. And if you’re a new PM/Product leader and want to share experiences and grab a coffee, feel free to send me a message at battagello.andre@gmail.com.

A brief context

Picture this situation. You're a new Product lead. After being responsible for a few product teams and areas, usually one at a time, you're now responsible for a larger product scope. You're super excited, but there are endless problems and high expectations. You don't have all the context in all areas you're now responsible for. There are several (identified and unidentified) issues and problems in your team or processes. The business and company leadership has high expectations from your Product area and you, and all of a sudden, you start handling decisions that were previously out of your scope. Things that were not your responsibility are now on your plate.

You start being asked different and broader questions in this new broad scope. Instead of being responsible for "how do I reach goal X for product area Y", "how do I maximize target metric Z”, or “how do I improve the experience/metrics/stability of feature W”, which usually involve questions/answers constrained in some way, you're now asked some open-ended questions, with less obvious/objective answers: “Where should we invest?", “What are the most important and critical product areas?”, “Why focus on area A instead of area B?”, "Why aren't we pursuing shiny new idea X?", “Why can’t we invest in area W right now?”.

Besides those broader, ambiguous questions, your approach and influence on execution also change dramatically. You’re not anymore directly responsible for the execution of several things that you were used to executing before.

It can be very stressful and overwhelming, and unfortunately, our default tendencies to deal with all of that tend to go in the direction of "working harder", but effort alone won't solve everything (and you can end up feeling burnt out really quick – been there, done that).

If you have good leaders and a structured career ladder, you might not end up in a situation like that suddenly (even though I think the general principles here still apply and might help you), but unfortunately, especially in fast-paced startup environments, the most common thing is to find yourself in a chaotic transition to a leadership role.

Why frameworks/tools/processes won’t solve all your problems

There are amazing Product Management content focused on helping you make better decisions and "strategic" choices. Good mental models and frameworks for thinking about Product decisions are critical (and I have learned and leaned on several of those frameworks myself).

But from my perspective, I struggled more with dealing with people/team issues and the "strategic process" than with the choices themselves (even though several decisions were super hard). We tend to spend a lot of time reading/learning about technical problems, but soft skills are usually the hardest to develop, and they are usually the ones that can improve your outcomes and your emotional health the most.

What is missing in frameworks?

First, frameworks tend to be oversimplified, giving you the idea of a perfect final product/canvas/ template that will solve all your problems and reach a “perfect executable strategy”.

Things can be simple when you're thinking about them on your own (on inside a smaller/limited scope), but when you have to create with/present/convince lots of people, things get messier. Opinions don't converge. Your leader or your peers don't agree with your approach. You don't have all the data you need. You don't even have full confidence in your first plan. Or you have a lot of confidence but you fail to convince and influence others in the same direction (because of the way you communicated or involved the team in the process). You get the point. From my experience, the problem usually is not reaching some “strategic output”, is how you build your decisions.

The major problem is that frameworks tend to show a lot about the "ideal" way and expected results, with a resounding decision, but they often fail to cover the hard parts of reaching those good decisions, and what can go wrong. They help you think about why "Choice A" is better than "Choice B", but they don't cover the challenges of persuading, aligning, and building those decisions in a fast-moving organization.

Besides that, most of the time, frameworks are derived from some specific context that doesn't usually transfer to your domain/situation (e.g. there are lots of product management templates proposed from B2C companies that don't map well to a B2B domain). Companies and markets have several particularities, and if you try to apply frameworks without understanding their original context and limitations, you end up wasting energy and also reaching bad decisions.

These mindsets and attitudes required to build and align a product strategy are usually discussed under the leadership, communication, negotiation books/posts/courses, etc, but in this piece, I intend to gather the aspects that made the most difference in my ability to build, influence and decide on a strategy.

A brief definition of strategy

Dealing with strategy is an ambiguous, uncertain and hard task. There are a lot of definitions and good materials about what a strategy is and what it’s not, but my definition/mental model is:

Your strategy is your approach on how you intend to win your game, from how you'll make choices to how you communicate your priorities and align that with your team.

It’s very broad and a little bit vague, but it reminds me that a strategy is not only about i) clear goals or ii) nailing execution, or iii) clear plans/processes, even though all those things are critical to making strategy work.

The intent of this post, however, is not to explore what are good strategies and the best templates/formats to put one together. To read more about how to think about your product strategy, there are also several other resources that I like:

• How to Define Your Product Strategy

• Getting Product Strategy Right
• Book: Good Strategy, Bad Strategy → Summary

Principles

In short, here are the main learnings that I wish I had known (or learned a little bit faster) when transitioning to a product leadership position and being responsible for a Product Strategy:

1. Treat strategy as a process, not the "end goal"
2. Clarify and Synthetize: Accept complexity and simplify things
3. Make choices: Embrace conflict and deal with ambiguity
4. Understand the context and learn how to question things
5. Nuance matters: it's not all science
6. Move beyond the Product: think about People and Processes
7. Keep yourself in the trenches

1. Treat strategy as a process, not the "end goal"

When you look at Product Management content, or look at other people in charge of a Product strategy, it's easy to be super critical and think that deciding on a strategy should be very simple. I used to think that the end goal when leading a product strategy was filling up a template/document with your plan and strategy, and then reaching a decision or consensus around it. After that, the work of creating a strategy would be "done": you would have a clear path forward, people would be aligned around that, and execution would happen easily. How naive. I quickly learned that this is far from the reality of leading a product strategy.

When you're dealing with more scope and more responsibility, the less direct/immediate control you'll have over everything, and you (probably) won't have all the answers upfront. People are not easily aligned around it. Good strategic insights don't happen overnight and without a lot of debate, reflection, experimentation and iteration.

Frameworks can certainly be valuable and help you in this process, but they are certainly not the end goal and the end result.

Thinking and acting more strategically is about creating alignment around the learning process as well, keeping all the necessary parts involved and supporting your plan, and not only about "getting the right answer and getting approval to execute it" (if that’s that is expected from you in your company… well, that’s another problem)

When thinking about strategy, I believe it's better to be right than to be quick. It's ok taking some time to move forward. Reaching quick decisions does not mean “good progress”. This might seem obvious, but I struggled with that quite a lot, and I saw several PMs struggling with that too. When they had to present some strategic plan, they would get super anxious upfront if they had no perfect plans/answers to show, or they would be overly confident if they had already reached some decision/consensus. Over time, I learned that this was the wrong mindset. A bad strategy can be worse than no strategy.

No organization/company/team has all the answers upfront, and not all problems should be treated the same way. Treating your Strategy as a learning process brings a valuable mindset, one that is focused on iterating and reducing risks instead of playing a game of false certainty. Sometimes the organization will have a clear idea of what should be optimized, but most of the time you'll be dealing with uncertain situations (e.g. a new product area, a new business unit, new innovative/risky features, etc), and you won't have a clear path to deal with all the problems.

When you start seeing the strategy as a process, you can also manage expectations (from yourself, from your team, and from other stakeholders). Some decisions are not reversible and should be treated with more caution, but very often it's possible to revert the decisions you make, and especially in the early stages of an initiative, you'll have time to course correct.

I also realized that getting good insights and high-quality information can take time, and a lot of testing, iterating, experimenting and false starts. When you see the strategy as an iteration, you leave space for improving it over time, and the more likely that you'll be able to get better insights and to better outcomes. Otherwise, you might end up articulating some ideas that are not very helpful if you try to make them “a final decision”.

Some senior executives, however, might push you to “show the final strategy”. Here are some ways to help you in this process to treat the strategic processes as an iteration, and some common traps you can avoid:

• Make it a ritual and constantly refine
  Create rituals and find time to get input and feedback constantly from the involved stakeholders, instead of leaving strategy to be discussed and thought in batches. Be clear that the plan is evolving and not “final”. It's easy to bring divergent opinions when things are starting, and it's easy to get everyone committed to a plan when they were involved from day 1.
  That's not something easy to do, however, because no one wants to spend time constantly “discussing strategy”. But after you start doing it frequently, you get several benefits: a better-shared context, more frequent inputs, and better decisions.
• Keep everyone in the loop frequently:
  You don't need to wait for those “formal” meetings to communicate and update people on the progress of strategic work (even if you have some recurrent meeting/event to discuss that like I suggested). Leave the meetings for discussing the most critical points, and create a cadence of updating the progress of some strategic work. If you agreed to gather more data/run some analysis, send the status about that. If you decided to run some experiment to assess whether or not to move forward with something, let everyone know how this is going. Short updates over Slack/email are important, in both directions: both to your team and to your leaders. People have a tendency to feel anxious when they don't hear no updates about “some strategic theme”
• No surprises: proactively manage expectations
  No one likes getting surprised in the workplace (except for very positive news, such as bonuses). Even things that are positive, if framed in a bad way, can backfire. When talking about your strategy, and especially if you're doing that constantly, be super clear about the certainty of the initiatives the team is working on, and about the time horizons.
  One technique is to create some sort of shared understanding about which phase are you in the moment: Discovery vs Delivery, Problem Validation vs Solution Validation, Experimenting vs Building, etc. The terminology can vary from company to company, but I saw very frequently people forgetting to make explicit that they were still trying to explore something (and that creates conflict, since they might have different expectations). If things can still change (the scope of the product is still open? the launch date is not yet final? etc), make those clear!
• Make things explicit and frame the problem properly to manage expectations: Very frequently, leaders, teammates and other areas don't have your full context, and they will probably assume things that cannot be true. For instance, they assume you have a team this is performing well, with no issues, when you might be in fact understaffed, or you might have a lot of technical debt/operational overhead. Make sure everyone has visibility about the context and the main constraints your area is facing. Some things that are usually forgotten to be made explicit:
  • Team status, scope and operational overhead:
    Sometimes, things may take longer than expected because of several reasons (systems complexity, operational overhead, technical debt, etc) but peers/leaders probably don't know about these in detail.
  • Unclear or conflicting business expectations:
    When people have no visibility (or alignment) around which goals/outcomes you're prioritizing, it's very common that they will start discussing and questioning why are you prioritizing feature X instead of feature Y. Most of the time, focusing on aligning the business outcomes/expectations will solve most of the tensions around roadmap/product priorities.
• Avoid dropping bombs in strategic meetings (specially those with a large number of people): no one likes big surprises (like I've just said two topics above). To avoid that, you should dedicate some time to keep people aware of major changes in the strategy, and I personally recommend avoiding communicating controversial topics (especially some bad news) first in a large group setting. That does not mean you should not raise awareness to big problems and issues, you definitely have to do that. But share them as early as possible, and possibly in a setting where people can properly process that without the inefficacies of a large group meeting.
• Align your scope, degree of autonomy and degree of risk you're allowed to take with your leadership
  Too often, especially when you're starting on a new role, the boundaries of your scope of responsibility might not be super clear. This can create some conflicts since you can fall in some traps:
  • Overlooking some important areas that should be under your ownership
  • Being too critical and involved in themes where you're not the one in charge Create some shared understanding about which decisions and processes and under your responsibility, and use that to calibrate and prioritize in which strategic themes and discussions you should get involved.

Common pitfalls that I made (or saw others making) when facilitating strategic processes:

• Perfectionism: investing too much time trying to create the "perfect doc" (whether it's a PRD, or a strategic plan, or a roadmap, or OKRs, etc). I know there are some cultures (like the Amazon written culture) where the docs tend to be a super important artifact, but the true value of those artifacts is that they create more focused conversations, and they help with finding clarity and making decisions. Instead of spending too much time trying to perfect the strategy document, make sure first you’re on the same page with others, ask for input, and iterate from there. It's ok showing drafts and incomplete versions of a document/presentation to others, as long as you create the context for that and do it in a timely manner. It's ok pulling some teammate, peer or your leader to ask their opinion after spending an afternoon/a few days putting some thoughts together. Be reasonable, and don’t overthink it.
• Mistaking a filled template/doc/presentation for true alignment, commitment and good decisions: it's easy to think that after you've done some research, some brainstorming and discussion with your team, and that you have created some docs or presentation, now you're done!
  But you can still be looking at the wrong things, or you’re not creating real alignment. Having a document filled out does not mean that people understand it, nor that its content is useful. If you’re asking the wrong kinds of questions, it doesn’t matter if it’s “done”, it’s your responsibility to reassess the situation. Some important things to remember when you're in charge of a strategic process:
  • Check for alignment/understanding: is everyone on the same page? Do they have any concerns? Are those concerns explicit?
  • Check for commitment: is everyone and all impacted areas fully committed around the strategy? Do their actions and plans reflect this commitment?
  • Check and assess the quality of your decisions: how confident you/your team/your leader are in the decisions that are being made? Make the level of confidence explicit, and bring/update thatover time
• Leaving no time or rushing to think about strategy: it’s a different type of work that you are used to do so far. It demands time (both individually and aligning with others), and sometimes it’s not as "concrete" as iterating on the product and on features. It's easy to look for things that feel more tangible, bringing a sense of short-term progress, but if you don't set time apart to think for yourself and to discuss/create/collaborate with others, it's very likely you won't have an aligned plan.

2. Clarify and Synthetize: Accept complexity and simplify things

There's something I heard from my leader/mentor that basically summarizes this principle:

A good "macro" does not mean a detailed "micro" – Leonardo Carvalho

A good high-level plan is not a highly detailed one. In fact, some of the best examples of strategies are super simple but very deep and robust/thoughtful at the same time. They sound almost obvious looking backward, but it can be hard to reach that level of clarity and concision.

Some examples of great strategic framing, which are all concise and super clear:

• The one email that explains Apple

• Amazon/Jeff Bezos: focus on the things that don't change

• Tesla Masterplan

Leading larger teams and products is a complex journey, with lots of ambiguity. When you're an IC PM working in a specific team, with specific goals/metrics, it tends to be easier/simpler to reason about what to prioritize and what are the most important things the team should be doing.

However, when the company scales or your scope of responsibility grows, there's a natural complexity involved in leading larger products and larger organizations. There are more types of users, more teams to coordinate, more dependencies to think about, more systems to maintain, more options of features and projects asked from your users, etc.

It's super hard to reason and understand every single part of a large system, and it's (virtually) impossible to micromanage and individually track everything that's happening, and usually counterproductive. It took me some time to be comfortable with this idea, however.

It's important to adapt and be comfortable with losing some level of detail in order to spend your energy aligning everyone around the most important things. You should still spend time involved in the details that are critical, but most of your energy should be focused on creating a clear high-level understanding of your strategy, vision, and expected outcomes.

Here are some tips that can help you simplify and articulate the most important things:

• Thinking in Systems:
  When you start dealing with bigger scopes/teams/processes, it's critical to be able to create models that represent the situation/problem at hand and to be able to assess and identify where to focus. Systems thinking is a very useful mental model/toolset because it allows you to create some concise way of expressing the parts that matter, and where you should act.
  There's an excellent book by Donella Meadow called "Thinking in Systems", and you can read about systems thinking in this blog post: Places to intervene in a system.
• Make things visual
  It's sort of a necessary part of thinking in systems, but when you try to conceptualize and represent your business/product domain in a visual way, you start to dissect how things work, what are the most important levers to solve your problems, and what are the inputs/outputs you can work on. That's where tools like User Journey maps, Service/Process maps, Personas, and several other frameworks can help articulate a problem.
• Choose the details you want to be involved in:
  Sometimes, I personally still believe that it's important being involved in some details, especially the ones that matter for the end result. While you should not be blocking or trying to execute everything yourself, you should still be editing and revising critical things, because that's how I believe you can set clear expectations to your team. See principle 7 for more about it.
• Improve your Communication: Learn how communication flows, and how you can better communicate your message in simple ways. I'm thinking of writing more about this topic too, if you think this might be useful, let me know :)

Some common pitfalls:

• Trying to align all the details, and keeping track of everything at all times: Dealing with complex and large changes in the product can feel overwhelming. There's an infinite list of concerns and small decisions that need to be made along the way, but they don't need to be tackled all at once. Don't try to keep track and communicate everything to everyone all the time: you'll not be very efficient, you won't transmit a sense of priority and won't create shared understanding around the things that matter.
• Focusing on “unimportant” things too early in the process: Related to the problem above, it's super easy to spend a lot of time/energy on things that are not important. If you're trying to assess if an idea is valuable or not, it's very likely that the final UX/UI of your product is not the most important thing. If you're deciding whether or not you should create a new product feature/area, you should probably be worried about reducing your risks and understanding your customer’s problems, and not about polishing the final UI.
  One common mistake that I saw teams making was feeling too attached to early versions of a product concept/prototype, or too concerned about the UX of some product concept that was still not clear if we should invest in that area or not. Learn to prioritize, and be okay with throwing stuff out. Just make it clear what people can expect as “final” and what are the things that still might change in the product.
• Mistaking Clarity for Oversimplification: If you create models and choose things that are simple but leave important problems out of the discussion, this can cause bad decisions or misalignment.

3. Make choices: Embrace conflict and deal with ambiguity

All organizations have to deal with massive amounts of information and ambiguity, especially in a world where things move faster every day. When you're trying to deal with this ambiguity, I always found it super hard to make choices and synthesize things. I was afraid of making mistakes and oversimplifying things too much, and I always felt that I didn't have all the information required to have a strong/assertive opinion.

Part of your job is now finding the ambiguities, the gray zones, the unclear topics that are blocking teams, and you should articulate and make choices about those topics.

To avoid the problem of dealing with conflicting priorities or too much information, here are some principles that I find helpful:

• Seek criticism and different perspectives:
  We all want to “get things right”, but the shortest way to that is counterintuitively to think more about what might go wrong in your plan. Instead of treating the input of other people as “blockers”, “pushbacks” or “problems”, treat those perspectives as more inputs that can help you make a better decision. Instead of trying to "prove your point", adopt a mentality of "invalidating" your ideas/plans, trying to think about what can go wrong, and then creating a plan to mitigate those risks.
• Share early and often:
  The earlier you share, the easier it is to course-correct and to refine your thinking and reasoning. You can gather inputs about critical risks earlier. The sooner you start sharing and asking for input, the easier it is to debate and assess different options. If you leave discussions or conflicts that show up too late, they tend to take more energy to resolve.
• Zoom out and Think on a macro level: It's easy to start overthinking things when you're dealing only with your own scope. One important and relevant thing to do is think about how your scope is connected to some higher levels in the organization, and how your scope is connected to the high-level business impact. Up to this point (as an IC), like said before, your scope was usually more constrained. When you start to lead and decide on a strategic level, you're also trying to solve the ambiguities that exist. Try to think about the goals of all the teams that interact with your area, and how they are dependent and/or impacted by your strategy.
• Define the constraints, and avoid the “Maybe”. It's very tempting to just “let things undefined”, and use a “maybe”. We tend to be optimistic about what the team can do and deliver, but this optimism can create more problems down the road. Do you have time, quality or scope constraints? Bring those up, and discuss those risks upfront. I believe most of the problems product teams face are due to the fact that people commit to plans that where they didn't consider and agreed on the constraints. Things that are usually unclear on ambiguous:
  • Team seniority: The team skill level to deal with the problem: sometimes there's a problem of lack of seniority/experience in the team.
  • Budget/resources: are the impacts of your strategy clearly reflected in the budget? If you need more developers, is that in sync with the org chart/growth plan? If you need to invest in content/marketing/operation, is that properly forecast?

Another thing that I understood better over time is that every organization makes mistakes and misreads things along the way, and most of them are not irreversible (the famous one-way vs two-way doors from Jeff Bezos's letter). There are also countless examples of strategic mistakes made by companies that show that it's possible to adjust your route. Even though it's important to get things right, you should try to focus more on learning and iterating instead of getting things right on your first attempt.

But even if you understand that you can iterate on your decisions (and learn from your mistakes), it's super important to make compromises and make choices. Your tradeoffs will probably bring limitations or some implications that you'll have to deal with in the future, but those are required to move forward.

Here, I think that experience and knowledge become fundamental because only having a good attitude won't solve all your problems. Knowing how to find the most important questions and assessing what are the most critical investments and improvements that you have to make is certainly important. Among all the things that you could be spending time and effort on, what are the most important ones? What are the biggest risks? What are the biggest leverages/opportunities? What are the macro trends?

The problem, however, is not that people don't have an idea about what they should do, but that they try to squeeze everything into their strategies. People don't make compromises and choices. Not because they don't want, but because it's hard.

Some common pitfalls:

• Avoid the trap of working too much on your own:
  Some people, either by overconfidence or by insecurity, try to show that they can do things by themselves, but end up isolating themselves from others in the process (either by spending too much time alone without considering valuable feedback or by wasting other people’s inputs)

  I tended to be this kind of "lone thinker", but I came to realize that I was not being very effective. Now I constantly seek support from my leaders, peers and team. Ask for their help, be constantly checking in with them. If they are not supportive, I think this shows more of a problem of the organization than a problem with yourself.

• Accept (healthy) conflict and find the common ground: it's easy to see conflict/different views as something to be avoided: we have a natural tendency to avoid confrontation. Making hard choices feels overwhelming, and can create a sense of "loss" (and humans suck when dealing with losing something). Usually, people tend to see conflict from a negative lens, thinking too much about what they are losing. It's helpful learning how to focus more on the expected positive outcomes ("glass half-full") than on the things that were left out ("glass half-empty")

• Overthinking and waiting too much: Trust your gut. Some decisions will not be based on data, they will require a level of intuition, of vision, of principles and values. It’s very tempting to leave a decision for the future, and not deciding anything.

4. Understand the context and learn how to question things

If you're creating something (a product, a completely new feature, etc) from scratch, this probably doesn't apply. But if you're entering a domain that already exists, or with previous attempts in the area, it's very likely that there are a lot of constraints and limitations in place. The technical/systems architecture has some constraints that would be hard to change, your value proposition and customer base already has an expectation for some things, etc. Several decisions probably made sense in the past, but after some time they can and should be reevaluated. People can fall in the trap of assuming that everything is still valid, and they may not question some things because of that. Also, there are things that were not viable or really a priority in the past, but they might be valuable now.

That's why it's important to question and understand the reasoning behind past decisions, and also if there's some significant change in the context that can bring a different perspective this time. However, doing that (understanding and questioning the context) can be a little tricky.

Senior executive forums demand different communication and negotiation skills (not only for persuading, but also for listening and understanding other's perspectives). These people are not completely aligned with every detail of what you're doing, and they are probably also in charge of large scopes. When you start to question past decisions, it might seem like you're entering their areas of responsibility.

It can be hard to find how much to challenge and question some decisions, especially because up until this point in your career you were previously assuming and working on some predefined boundaries and constraints. Now you’re suddenly supposed to set and negotiate some higher level constraints that you were used to “being given” as a premise, and this can be a subtle but difficult thing to deal with.

In dealing with more senior people, they probably will not always have the full context and understanding of the problems and risks you're seeing. They will often be concerned with other critical areas and their own challenges. They probably won't remember everything you communicated. This may require being a little repetitive and overcommunicating things.

Another common problem is that it's very easy to take senior people input as a mandate. This is the classic HIPPO (highest paid person opinion) problem: someone with more influence and authority will bring a really strong opinion or decision to the situation. Sometimes the senior person imposes their opinions, but sometimes you just think that they are imposing something because they tend to be very eloquent and better communicators.

There are a lot of negative ways to deal with those “pushbacks”:

• Being destructive:
  Instead of trying to understand why the person is proposing things in a certain way, you start to bring up a lot of reasons for why things will go wrong, and all the negative consequences you can think of. This will hardly help change some decisions, and now you have to deal with conflict/tension, instead of focusing on execution.
• Being confrontational:
  You take different opinions as a personal battle, and you try to make it like a dispute, and if things are not decided your way, you take the situation as a "lost battle".

There are some skills that can help to deal with difficult conversations like that.

• Practice your emotional intelligence:
  First, you can always control how you react to those divergent decisions/opinions, and being less emotional is super important. Separate yourself from your ideas, and understand that most of the time, people's criticism are directed to the ideas, not to yourself.
• Make people feel heard:
  In dealing with the natural changes that happen along the way, it's helpful to listen and to make people feel heard (which are different things). Sometimes, it surprised me when I made some decisions that I thought that were “in the best interest of the team”, but somehow they got upset with those. It made me realize that sometimes, you have to create room and time to make people express their concerns. That’s okay changing a few things, as long as the team feels heard.
• Ask better questions:
  Another useful skill is learning how to ask probing and clarifying questions: this can help you understand the other person's perspective at the same time that you make him/her realize and take your concerns into consideration. Why do they think that's important? What are they trying to optimize? Have they thought about the problems you're concerned with? What would they do if they were in your shoes? By asking good questions, you can bring a different point of view and raise your concerns in a constructive framing.

5. Nuance matters a lot in strategy

A lot of references of strategy today focus on the concept of guiding your product work seeking to optimize a North Star Metric. However, I believe that this leads people to mistake this data orientation with certainty.

There are countless examples and principles to avoid optimizing too much for only the proxy and mistaking this for the true result. This can cause several problems in products (being overconfident, or thinking too narrowly, causing harmful consequences because of your product unintended impacts, etc).

The truth is that a lot of the value that we deliver through our products is hard to precisely measure. A lot of the impact/value that our products deliver is not immediately captured in some direct ways in the metrics.

In a world where lots of companies find and share recipes of "how to create the next unicorn/hit product", it can be really tempting to try to copy and to apply what other successful companies are doing. But what works for other companies will not necessarily work for your company: you might not have the resources, the capabilities, the brand, the people, the knowledge or intellectual property, whatever it might be. Also, your customer segment and your mission can fundamentally differ from your competitors, and if you try to directly replicate and copy what others are doing, that can lead to failure.

I'm not saying that there's no value in learning and applying best practices from other companies. But you should do that after deeply understanding your customers and your market, and with a clear intention of what problems you're trying to solve.

And this won't be scientific all the time. If you look at how the greatest product people in history think about their strategies, you realize it’s not all science (this Twitter is a very interesting source of emails/messages where you can get a glimpse of some of those decisions). Humans make choices moved by emotion, and innovating and creating great products does not happen by optimizing processes.

I'm not recommending that you don't trust the data, nor that you make decisions based only on instinct, but I'm neither a believer in a 100% data-driven product development process. In my experience, data is an important compass/GPS that can show if you're moving in a certain direction, but it can't show you the direction and where you should go.

At the end of the day, the Product leader’s role is to provide confidence that the team is learning and moving forward, that it's looking at the right things and asking the right questions, and that all the necessary perspectives and data points are being taken into account in the process, and I believe that the nuances matter a lot in this process, and intuition, vision, and taste are important elements in setting a product direction.

6. Move beyond the Product: think about People and Processes

The more impactful things are, the more likely they will require coordination and alignment between a larger group of people. That's not always true, of course, since small teams can have an outsized impact, but when you're involved in products that are not only software, you'll inevitably have to coordinate several groups.

When you're dealing with implementing features in a single part of a product and in a single/autonomous team, you're usually thinking about the end user and thinking about moving/optimizing a constrained set of metrics. But once you start to lead bigger changes to the product, unintended and unforeseen consequences will pop up all the time, and how you deal with things will start to involve much more than the choices of features. Suddenly you'll be dealing with broader issues and decisions:

• Making tradeoffs that might directly impact the Go-to-Market strategy: in order to focus on engineering debt, or putting the time to invest in infrastructure, you’ll have to deprioritize new features that we’re expected by major/a large number of clients.
• Launching faster, but putting more "pressure" on your operations team/processes (and discussing the priorities/SLA/customer segmentation with those teams)
• Redefining external expectations with Product Marketing and Customer Success teams that might frustrate or impact some important/critical customers (or customer segments if you’re in B2C), which might impact your annual business metrics.
• You’ll be compromising some areas of the Product, in order to focus on the most critical issues or some current fire.
• You'll have to negotiate and discuss the shutdown of some products that involve some non-negligible revenue.
• You'll have to decide if it's appropriate to make a major engineering investment/change that would slow down several teams for the next year (since this will might adapting/rewriting several services)

Those are things that you always have to deal with as a PM, of course, but on a smaller scale, these things are much easier to deal with. They cause less burden and require less energy. For instance, it's way easier to negotiate to delay a feature launch for something that is an iteration/small improvement, than delaying something that can be foundational to your go-to-market strategy and sales team’s annual goals.

Being involved with broader scopes also mean you won't be directly involved in every decision. You now have to think about ways in which you can help not only your own decision-making, but also how to improve the decisions that others are making. This involves creating processes, tools, systems and rituals that can help the team to achieve better results.

It's important to understand that you're not only responsible for deciding what goes in the product, but also to improve the systems, the people and the team that create the product. Instead of building products, you're thinking how to improve the machine that builds the product, and the machine which improves the operation.

Here are some common pitfalls from my own experience:

1. Inertia and fear of changing rituals, processes and team structure:
   People don't like change, and it can be a little hard to adapt to new teams. Sometimes, the problems need faster communication (which requires creating forums/communication channels), other times they require less chat.

   Try to involve how your teams are organized, how they interface with each other, how fast they can access and act on user feedback.

2. Thinking in isolation:
   Don't get trapped in thinking about "my part" of the problem, and letting others figure out their parts. Sometimes, it's tempting to diagnose some problem, and just tell some other team to “just solve it”. But if try to understand that team's perspective, you'll realize they can be in a situation where they have different priorities. Instead of playing this “us vs them” mentality, work together and be empathetic.

3. Local optimization Optimizing for the user and forgetting about the business or the overall consequences (or the other way around). Sometimes it's okay to make short-term tradeoffs ("do things that don't scale") to improve your speed, and to avoid overengineering parts of the system where you're still uncertain about the use cases or the requirements.

4. Tolerate some level of error, and leave the decision for others:
   When you're in a new leadership position, and still feeling insecure about your own results, it's hard to accept some mistakes, especially the ones "you would not make”. But trying to avoid mistakes will only create bad long-term effects in your team (fear of taking risks, fear of innovating, etc).

7. Keep yourself in the trenches

It's easy to fall into the trap of delegating too much to your teams, and in this process, you can end up alienated from customers and from the end-user experience. Your new role will most surely pull you to other “high-level activities” that can seem more important, but they are secondary when compared to being in tune with your users and your current product situation.

• Keep using your product:
  It's easy to be flooded with syncs and endless alignment meetings when you are in a product leadership role, and you just stop using product launches by yourself.
• Keep allocating weekly time to talk to users:
  Talking to users demands a lot of energy. If you stop caring for this, this can cause two major problems:
  • your product sense/judgment/intuition will surely suffer
  • if you want your team to care about your users, you have to do this by yourself
• Keep the standards high:
  You certainly don't want to be overly critical, but the role of being a product leader is the role of an editor: teams are creating/shipping/iterating on things, but you still have some editing influence, and you're responsible for high-level directives (such as the vision/strategy/etc). You have to set the standards for what is a good process and what is a bad/good/great result.

---

This got a little bit longer than I expected, but I hope it might be helpful.

Thanks to my colleagues and former teammates who read early drafts of this, with whom I learned most of these lessons in my 10 years at Geekie. It was a wild and fun ride.