The ideal product manager to engineer ratio can vary from company to company and even team to team, but it usually depends on the company size, product complexity, the skill level of the engineers, and the role scope of the product manager. A general rule of thumb is 1 product manager for every 5-10 engineers. * 1:5 - This is common in startups or small teams where the product manager may need to be in the details. * 1:10 - As the team and company grows, a product manager may manage larger engineering teams. Sometimes it's one large team or multiple engineering teams. Since product managers don't have time to be in the details for every project, they are expected to work at a higher level on setting product vision and direction rather than detailed product requirements. It is common for senior product managers to manage multiple teams. * 1:7 - This is the sweet spot where a product manager can still get into the details of a project while also having a lot of impact with a team of this size.

While project management and product management require similar soft skills (communication, negotiation, structured approach etc.) there are some fundamental differences. For instance, project managers need to be risk averse because their job is to make sure projects are delivered as promised. Whereas, product managers must have a higher risk appetite as their job is to maximize outcome for the business and must explore unconventional paths get to the outcome. So it's important to recognize that these are fundamentally different jobs and approach product management career with a sense of curiosity. Other than, the approach to getting into product management is the same for people transitioning from any other craft. The easiest way is to find product management opportunities within your current team / organization, rather than job hunting in the open market, because they already know you and your work.

Prioritise with respect to the key goal that is important to the org -- but balance with your estimation of what you think can land. That sounds simple, but in large matrixed organisations, that can get hard quickly. * Sometimes it's not clear what advances the org's goal -- is there a key metric? Can you forecast a project's impact on that metric, and is that forecast credible? * If shipping a particular project needs alignment from lots of teams, do all of them share the same incentives you do? If not, can they support your goals, or will they deprioritise?

1. Bring structured thinking to your communication and approach: Become effective at breaking down problems using structured thinking. For Behavioral questions, look into the STAR method. For other product sense questions, look at case study books such as Case in Point and PM interview practice. This is a critical skill set that will serve you well as you take on different types of PM challenges on the job - from developing a new PRD, doing a competitor analysis, to building an execution plan. 2. Have a good pulse on market, products, & design trends in the industries you are passionate about: Read, observe, podcast, leverage Gemini & ChatGPT to constantly stay up to date on trends in your relevant markets. Bonus if you can keep trying new products in your space and be able to articulate the user journeys and pain points. 3. Showcase your leadership in various aspects of your personal and professional; journey: Whether it was leading an effort in a nonprofit group, or in an extracurricular, or work - reflect on leadership journey and be able to articulate how you would bring that to the organization you are interviewing for. 4. Demonstrate your passion to learn & be open to feedback: With the fast changing technology and world landscape, hiring managers want candidates who will go above and beyond to learn. Demonstrate your approach to learning new skills and how you would continue incorporating learning in your day to day. 5. Get effective at using data & metrics: Critical in today’s PM role is leveraging data to augment key decisions. Be able to illustrate how you leveraged data in your past roles / projects. Think of building your data skillset just as you would build your technical and domain skill set - learn different tools for data analysis, dashboards, and best practices for metrics that matter in your domain.

The way how you measure your own success depends on the criteria you have for yourself. However, I think it's very important to know that when you go into the PM career that there are some specificities: this is a late reward career. Being a PM is not like an engineer or a designer or a sales where you produce outputs. The way how you measure success for a PM over time usually take years, to measure impacts that you brought with products. For myself I use 2 indicators to measure my own success: the impact from the products I am overseeing, and the impact from products coming from PMs I had the chance to coach over time.

The following stand out to me for what I've witnessed: * The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time. * The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding. * The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast! * The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them. * The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

The “soft skills” are often what separate the good from great product managers. In particular: * Curiosity - An insatiable curiosity about your customers, partners, fellow team members, technology and just about anything that comes your way helps add arrows in your quiver you can use when tackling the wide range of daily challenges product manager takes on. * Story Telling - Central to a product manager’s success is the ability to influence key parties to deliver an outcome. Whether its influencing the customer to use your feature, the engineering team to build something, the product manager ultimately has to craft and deliver a clear, energy-infusing narrative that touches on logic and emotion to compel the party to deliver the desired behavior. * Hustler Mentality - Great product managers consistently deliver results even in the most constrained environments. They do this by being scrappy, resourceful and opportunistic - using great judgement to figure out where they should spend their energy, thinking creatively about how to marshall the resources they have, and steely resolve when tackling blocking issues. They do not resort to victim mentality. This is not to say that specific technical or writing skills are not important. However there are many flavors of PM where “hard” skills required vary. But the above needed soft skills tend to remain consistent.

* in product reviews, when an exec/lead asks you something about your product decision, don’t table it and say “idk, we’ll assess and circle back with you in xx days”, rather just say what you think ought/should happen. You could state that these are assumptions and you could/should validate later. But as a PM, you’re paid to have an opinion on the spot, and oftentimes we don’t have all the data/research at our fingertips. At least the exec could course correct you on the spot in case you need misdirection, so you don’t fall into a rabbit hole * in presos to execs, lead with the spicy thing first (the solution, the recommendation, etc..) and have the justification/rationale/analysis follow it. for non-exec presos, it’s generally recommended to reverse the order. This may be obvious, but I’ve seen it overlooked sometimes. * expose a healthy dose of skepticism, call out product/market risks/assumptions - but do it in the latter half of the preso, If you only present positive info, folks naturally get suspicious around what are you hiding (this was inspired by Mihika Kapoor's talk at Lenny's Summit earlier this year, but it's principles I've adhered to and shared with my PMs for the past couple years)

I like to get as much input as is reasonable both internally and externally. * Internal examples of stakeholder input: partnerships, sales, marketing, product support, operations, finance, data science, design, execs… * External sources of roadmap input: press reactions & professional product reviews, app store ratings and reviews, customers support requests, user research, inbound marketing research, and above all behavioral data from your logging/analytics. In terms of gates... during the planning process, you don't really have gates, just the process you follow that encourages all good ideas to flow in, but then rates those ideas by expected impact toward your goals, and level of effort to design/build/test/release. See my other answer to the question about the end-to-end roadmap prioritization process. When the team is executing, not planning, ideally all ideas coming in can wait for your next update or refresh cycle. This might be quarterly or even monthly in a very lightweight way... but since your teams have established goals, new projects will only bump other projects out of the roadmap if they're more likely to have higher impact in achieving the goals. Occasionally there's a disruptive change that should cause you to think through changing the team's goals or an immediate pause/change to work-in-progress in the roadmap. But these should be rare, and very important, because you're going to thrash your team to consider the change/pivot.

There are two ways to think about what the right KPIs are for your product and product team. One is to use a general model of customer lifecycle and the other is to align closely with your company’s overall goals and north star metrics. For the general customer lifecycle framework, a good place to start is defining metrics for each lifecycle category: discovery, acquisition, activation, engagement, retention, revenue (if applicable). Now not every product has every category, but this will get you a good place to start. This framework works for internal and platform teams as well - I know since I use it with our platform teams at BILL. While you can start with this lifecycle framework, you will want to make sure to align to the company’s core KPIs. You will want to make sure any metrics that you select within the customer lifecycle framework roll up well to the overall metrics the company is trying to move. This will help ensure that all of the metrics you are monitoring are aligned with the company direction. I will also call out that defining the right KPIs to understand and monitor day-to-day is not the same as setting goals. KPIs are intended to help you understand how your product is performing overall. Goals / OKRs are your commitments to specific ones that you want to move or change. So defining KPIs are a very important first step to get visibility into product performance, then you can get a clearer picture of where you want to focus your roadmap to make meaningful changes.