This is a two-part question. Let me first articulate how I like coming up with ideas for new opportunities, followed by how I like to make decisions about what to build. Hopefully, you don’t mind that I’m thinking about “opportunities” because it might not always be a feature that’s the right solution. I should start by saying that there isn’t one right approach to coming up with ideas. In my experience, I’ve had success ensuring that there are: 1. Insights from the four lenses: Customer, Business, Market, Technology 2. Effective methods to facilitate ideation At the core, you have to have a deep understanding of the underlying user pain point you’re trying to solve through a thorough investigation of the Customer by talking to customers and product usage. You might actually learn very quickly that the user problem is around discoverability or activation, not necessarily a feature gap. Ideally, the customer impact is so deep that it translates effectively into Business impact. The Market context is critical to help understand how your user will experience the product within the broader competitive landscape and the direction an industry is headed. Finally, the Technology lens offers insight into what capabilities could be used as part of a solution. Preferably, these four lenses come together through cross-functional ideation that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market teams). In a hybrid world where we’re working across time zones, I’ve enjoyed having the opportunity to ideate together synchronously and asynchronously. In terms of decision-making, the ideation process should lend itself to initial layers of prioritization. I won’t go into prioritization frameworks here, but there are many out there. They do tend to distill back to impact and effort and sequencing. At HubSpot, depending on the type of decision we are trying to make, we may use a “driver, approver, contributor, informed” DACI model used by other companies we admire like Atlassian.

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.

For a new product in a new market, I don’t think you can ever validate the problem space enough. Once you have reasonable confidence that the users (and buyers) exist for the problem space your product tackles, and there are viable ways to create a business out of that solution, the best next step is to involve engineering to build a prototype of the solution. Then you can test that prototype with a representative sample of the expected user base to get early feedback and iterate on building out the product and grow the business. For 0-1 products, involving engineering early as a partner to the overall product definition and development process is best, so you can iterate together on building the right product for the right audience.

Reality these days is that we mostly work in remote settings, and even when we do go to the office, some people will be dialing in. As a result, I believe 80% of the strategies have to do with focusing on the fact that we are all people, 20% are tactics and adjustments for remote settings. General alignment strategies: * Build trust ahead of time. This is fundamental and driving collaboration without it is hard * Focus on common goals. There’s typically a higher goal that teams can easily align on (e.g. Revenue, Engagement, Better experience), and the differences show up as you start double clicking into the “how”. Starting the discussion with a longer term view can also help in skipping tactical disagreements and alignments * Frame, rather than take a position. With common goals in mind, center the discussion on what the characteristics of a good solution are, rather than starting with comparing options. This helps setting a more objective ground before jumping into the solutions * Call out your biases (easier to do when you have trust). In an environment where there is trust, I expect my teams to be able to call out other considerations that may cause them to pull in a certain direction, those can be different stakeholders that push in other directions, past experience and others. Some of those reasons may be valid, some may not be valid. Calling them out can help the entire team work through them. A few remote specific tactics: * Set the right structure, if possible. This includes minimizing the number of time zones each team has to work across (In my organization we are trying to limit ourselves to 2 time zones per team, when possible). If you can, hire senior enough people in the right locations to be able to run autonomously. * Invest in getting to a clear strategic direction. Having an upfront debate on the direction is time consuming, but can then help in setting the guardrails for autonomous decisions that can happen within the teams, locally. * If you do have the opportunity to meet in person, do so. Especially when working across time zones with little overlap, a good relationship would allow you to accomplish more offline, and can dedicate the overlapping time for working more effectively through the tougher topics. While I still mostly work from home I prioritize going to the office when team members from other offices are coming to town (and I am writing this note from the airport, while waiting for a flight - going to visit my team in Austin!)

Perhaps a contrarian take, but technical skills aren't the most critical for the majority of PM roles out there, except for deeply technical products or platform positions. For the general PM role, it's much more important to demonstrate your ability to delve into customer problems, set strategy, execute, and drive impact that aligns with your organization's mission and vision. Technical skills matter, but they are secondary. They usually revolve around your ability to work with engineering counterparts and understand enough technical concepts to make trade-offs, and to work with data and perform analysis for decision-making. In my experience, both of these skills are often inquired about directly.

I’ll skip the obvious things - pay well, set a vision, growing company, skill building, career pathing - and highlight some under-rated ones: * Hire well and have high talent density. Most people who choose a career in Product Management are motivated by self improvement - being around other talented PMs who they admire and who push their thinking is motivating. * Stay lean. This may seem counterintuitive - isn’t it good to have enough PMs? Honestly, no. If you hire well you want to give people room to grow and stretch. The worst thing you can do is to staff up too quickly, only to have frustrate your stars who are ready for more in a year (or worse yet, sudden shift in the business which requires you to scale back projects). Having too many PMs will also lead to more work being generated, you then need to resource. It’s far better to have PMs that have 20% too much to do than 20% too little. My rule of thumb is: everyone should be just uncomfortable enough with their scope that they drop a few things, but not so uncomfortable that they burn out. * Autonomy. People choose a career in product management because they want to make or be at the center of product decisions. Allowing them to do so is one of the most important things you can do to keep them motivated. As a people leader your jobs is to set goals, give context, guide, and identify blindspots. It’s not to operate the product for the PMs on your team. At Netflix we have a value, “Context over control” - leaders should focus first & foremost on setting context so others can make decisions vs. making decisions for them. * Actually care about them. When I think about the best managers I’ve had they have one intangible thing in common - I felt on a deep level that they actually, genuinely cared about me. This had a ripple effect on every part of my job because I felt supported, was calmer, and did better work. Caring looks like regularly thinking about the growth & success of another person without being asked to. It looks like advocating for or elevating behind the scenes, especially if they are in a disadvantaged position. It’s something that you can’t fake.

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.

I talked about my take on desirable qualities in one of my previous responses, so I’ll focus on the common mistakes I’ve personally made in my career in the past, that hopefully will help others avoid those pitfalls. * Mistaking motion/effort for progress (This is also one of Meta’s posters on the wall in our campuses) * Rushing to prove my value (whenever I switched roles or teams). * Not being able to articulate the “So what” well. Eg: I’ve launched this shiny new feature, so what? * Assuming everyone has the context (and motivations) that I have * Assuming everyone understands how I communicate (and my jargons) * Not stepping up soon enough to grab a new opportunity a.k.a feeling scared * Asking for permission * Getting comfortable in a role; growth & learning plateaus

PM to engineer ratios can range wildly from 1 PM to every 2-3 engineers to something 1 PM to 15 engineers. This largely depends on the size of the company and the type of product. In a more entertainment context, like a gaming start-up, you might have leaner engineering teams with more PMs to develop the ideas and concepts for all of the experiences. In a scaled big tech company you might require many engineers and teams to work across all the platforms involved, so the ratio of a PM and product initiative to engineers might be 1:10 or more. That said, the most typical ratios I have seen are 1:5. More technical the teams and products will tend to have fewer PMs and the more customer facing and experience oriented the product will tend to have more PMs

Technical questions are usually asked in a few contexts within a PM Interview. * Understanding a PM's experience working with engineers: These questions are usually asked in rounds led by engineering stakeholders. A typical question concerns making a hard prioritization decision due to a technical constraint. A PM is expected to know enough technical details to understand the various choices, their pros and cons, and make prioritization decisions accordingly. * Data Analysis and SQL: Most PMs do some level of data analysis themselves. Especially for early startups or lean teams where there is either no or insufficient data support, PMs are expected to know the basics of SQL, understand and prioritize where they need instrumentation, and even create some reporting/dashboarding for themselves and the company. For such a role, it's quite common to have a round on data analysis and sometimes even SQL. * Platform, Infra PM roles: If you are applying for a role that is platform or infrastructure-specific, it's expected for PMs to have a degree of understanding of the same. Technical depth also depends on the role (early or mid-career). For eg: Dev API PMs, Authentication PMs etc.