I will share first two steps that I follow. Step 1: Is this problem worth solving? 1.1 Problem definition and user segmentation * B2B product: A business customer must have a genuine painpoint that they are willing to pay for. Some problems are not big enough problems, hence not high priorirty for the business users, these are not worth pursuing. Fine tune the problems till they hit * B>B>C: The business user/stakeholder may have rightly identified a problem but may not have the best ideas in terms of what solutions can work. Validate the problem is real with user research. * B2C: Similar to B>B>C, some segment of users have a need. Identify who they are and what the real problems are. 1.2 Is the Problem TAM big enough Step 2: Why us? Why now? 2.1 Do competitive studies 2.2 SWOT analysis 2.3 Are you best positioned to build this and build now?

As you progress from PM to senior PM, competencies in these 3 areas should grow: Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications that someone is ready for the senior level, like increased scope, being a reliable partner and being results driven. Here are some less obvious ones: #1 You recommend initiatives based on your strategic evaluation, instead of waiting for them to be handed to you. You are influential in your field and feel confident putting forward these initiatives. #2 You leverage relationships across the org. You can drive results from partners outside of your immediate team. You are fully entrusted to tackle complex, multi-team problems with little necessary supervision. #3 You are seen as an available and trustworthy mentor and actively seek out opportunities to help others be their best. This is my favorite by far. What are the key stages that distinguish the different levels of PMs? I think a little bit of this depends on the problem space and company. In my mind, PMs are professional collaborators, strategic assassins and bring out the best in their peers. If you can look yourself in the mirror and say you’re doing these things at scale, well, I’d say you're on the right track.

I love this question! It happens a lot and working through it is part of our role as PMs. There are a few layers to my approach here: First, start with building the relationship. (I hope this theme is clear by now ;-). While your goals may conflict, at a higher level you are playing for the same team, and having constructive, trusting relationships is a key for any team’s success. You don’t need to agree, but at least seek to understand and show empathy. Second, focus on higher level framing, rather than your own goals - You both want the company to succeed, and if you start double clicking into what success means, you will likely be in agreement for the first few clicks. As you go deeper, call out the framing e.g. “We want to grow revenue, but also want to ensure good customer satisfaction. We may disagree on the relative importance of those factors”. I specifically recall a leader I worked with with whom I philosophically disagreed on the overall direction of my product, but could still have very productive conversations about how to think about the space. We were not trying to persuade each other, but rather use those conversations to enrich both of our thinking. Third, As you lay the framework and get to the crux of the disagreement, try to think of the “what needs to be true” statement. If two reasonable, capable groups of people look at a problem and get to a different conclusion it may be because they put different “weights” on different considerations. You can then enumerate “A is better than B if X, Y and Z are true. Otherwise B is better than A”. Example: Driving revenue up by X is more important than driving customer satisfaction up by Y if we believe that the change in customer satisfaction will lower attrition by XX and drive increased spend fro existing customers of YY”. Then the discussion can be about the conditions, not the goals. Fourth, when the discussion does move to goals, look at counter metrics. “Grow metric X while keeping metric Y within certain guardrails”. I’ve seen this technique used a lot at Meta. Last - Escalate. I encourage my teams to escalate disagreements so we, as a leadership team, can unblock them. If the work above does not solve the challenge, at least it allows for a very structured discussion among the leaders of the conflicting parties.

Aspiring technical product managers should consider developing the following skills and background: 1. Technical expertise: A strong understanding of technology and the ability to communicate effectively with technical teams is essential for technical product managers. Familiarity with coding languages, software development methodologies, and industry-standard tools can help aspiring technical product managers gain credibility with their teams. 2. Customer empathy: Technical product managers should have a deep understanding of their customers' needs and pain points. They should be able to conduct customer research and use this information to inform their product development decisions. 3. Business acumen: Technical product managers should have a good understanding of the business context in which their products operate. This includes understanding the competitive landscape, market trends, and financial metrics. They should be able to use this information to make informed decisions about their product development priorities. 4. Analytical skills: Technical product managers should be able to analyze data, draw insights from it and use it to make informed decisions. 5. Communication skills: Technical product managers need to be able to communicate effectively with both technical and non-technical stakeholders. They should be able to explain complex technical concepts in a way that is easy for non-technical stakeholders to understand, and be able to negotiate and influence stakeholders to achieve their product goals.

I think the best way to break into the industry as a PM is to get after building tech products yourself. Personally, I left a well-paying job in the energy sector to work on a start-up with no reliable paycheck. Thinking back on that experience, it was crazy beneficial to learn how to work with designers & engineers to build a great product or feature. The act of building a product or feature is the best teacher. I’m not advocating that you should quit your job and not get paid to build stuff like I did! There was a lot that wasn’t so awesome about that. 😅 But I definitely WOULD encourage everyone here to think about how you could do that in your spare time. What problems are you passionate about solving? What kind of product or feature could help you solve that problem? How could you bring that solution to life? How can you talk to prospective customers about it? Even PM candidates that make wireframes or prototypes to show a product that solves a real problem have a leg up over most of the other candidates. I’ll take someone with drive, initiative and passion for the work 10 times out of 10.

When you’re working at an early-stage startup, I know it can feel like every conversation, Slack message, or email thread throws another item on your plate. It’s totally normal to feel overwhelmed because there is always more work than can be done by a PM. To help manage this, here are a few strategies and tips I use: 1. Define Clear Priorities and Communicate Them: Define the priorities for you and your team in terms of areas of focus. What are the most important things that will have the biggest impact on your product and your product success right now? For example, if you're at the design phase of a future release, you would prioritize things like user experience research, customer feedback, focus groups, etc. Be ruthless with your priorities, define them, and stick to them. Early in my career, I would get distracted by items that weren’t critical at that moment and later regret the distraction. The second part of defining priorities is communicating those. When your team and your stakeholders understand what your area is a focus is, it's easier to manage those incomings and set expectations. 2. Batch Your Interruptions: In a startup, the product manager is often the jack of all trades. This is a double-edged sword as being the focal point of many conversations allows you to drive the product strategy and execution with a greater degree of confidence and visibility, but it comes at a cost since everybody looks to us for every type of question. To help manage this, I typically carve out a block of time every day to respond to non-critical interruptions. Reserving a block of time either at the beginning or the end of the day allows me to defer those interruptions and knock them out without disrupting my flow. Context switching to handle incoming interruptions comes at a significant cost to your focus....so minimize that. 3. Empower the Team Around You and Defer: Typically with a small product management team, it's not possible to handle all of the incomings all of the time. Defer what you can to either other members of your team or a subject matter expert in another team. Don't be afraid to suggest speaking with somebody else to get the answer that they need. It's hard to let go sometimes, but protecting your focus is critical to being successful as a product manager. 4. Don't Be Afraid of No: Your time and capacity is valuable for your organization. Don't be afraid to say no to incoming interruptions in order to preserve your focus. It's not a black-and-white answer that applies to everything, but you need to use your best judgment and be comfortable, saying no to incoming asks and requests if it doesn't align with your priorities or won't help you drive product success. Be honest when you say no to something and be open to explaining why you are saying no. You never want to be the black hole of incoming requests where customers and stakeholders feel you don't respond....so always better to respond with a no vs ignoring and never responding.

One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your product? (Risk can be defined crudely in terms of Low, Medium, High or in some cases you might have a model with some sensitivity analysis built in). Regardless, if you can quantify the risk (and thus impact) of the problem to the final solution, you have a clear blueprint of where to begin. A related method is to consider one-way vs two-way decisions. One way decisions are challenging or impossible to reverse - these have multiple downstream effects on the solution. Two way decisions can be reversed easily or adjusted over time once you have more data. I prefer to focus my time and energy on one way decisions first, as these will build the pillars of the product. If there is considerable time or effort spent by your team on a two way decision, you can make the argument to come back to this once you have more information or once all the one way decisions have been made.

There are several things that you can consider mistakes, but I do view them as learning opportunities. Every PM goes through some of these in their career (including myself). Here are some of the common mistakes I have seen PMs make: * Not talking to customers to validate the problem: A lot of times I see PMs jumping to solutions for a not well-defined problem. How will you know you have solved the problem when the problem definition itself is not correct? * Ignoring customer feedback: Worse than not talking to customers is talking to them to tick a box but not listening to their feedback. You become so fixated on the solution that you believe they know what's best for users. * Trying to build too much: Combination of creating a feature factory and going after shiny objects vs truly understanding the pain points and narrowing it to start small. In this scenario, PMs spend months or a year to build the right product and then when it gets launched no one uses it * Lastly not communicating enough: You should be able to articulate the value proposition of your product to anybody, your teammates, your customers, your cross-functional partners, investors, media, etc. This is why Amazon press release has taken popularity to force you to think through everything and communicate to inspire your team and others

1. Ability to communicate well - Someone told me early in my career: The single most important PM skill he looks for when hiring a PM is communication. Communication is really a proxy for building trust, driving alignment, having healthy debates when there’s conflict and committing to a path forward. That’s all under the hood of good communication, and is instrumental in driving product teams forward. 2. Data driven mindset - relevant to qual as much as to quant. Ask yourself and teams the right questions. Become familiar with qualitative research tools, understand what your dashboards need to look like, and get your dashboards in place. Be empowered to make data-driven decisions. 3. Ruthlessly prioritize - every day you have more you want to do than you will have time to do it. That’s just the reality. Every human has 24 hours, and one can’t change that. Make sure you prioritize your team and the team's time and resources.

In my previous answer, re: finding the right opportunities + making decisions - I mentioned four lenses (Customer, Business, Market, and Technology) as key components of coming up with ideas and making decisions. The best advice I have to offer is to be intentional about spending time developing your muscles in those areas. It can be as simple as picking a product or service in your day-to-day life and thinking through what inputs might have contributed to the experience you’re having as a user. Additionally, a lot of product strategy is about being able to identify the opportunity that will maximize impact. How will you hone in on the right problem and arrive at an excellent solution? I’ve found that strong problem-solving intrinsics and the ability to make effective decisions are very valuable. Here are two frameworks I’ve always found helpful: * McKinsey’s Seven Steps of Problem Solving - Helps abstract underlying problems/issues * Playing to Win - Strategy book by the former Procter & Gamble CEO A.G. Lafley Lastly, communication is essential for being able to get buy-in and execute product strategy. Work on simple, effective communication.