My current product team has about 40 PMs (And we are hiring!). I would not dive into what each of the team does, but maybe talk about how we went about structuring it, which may be a more transferable skill. When I first joined Meta my VP asked me if the current team structure is the right one. Naturally, I did not know the answer. Frankly, I don’t think it was the right question for me to answer at the time. Instead, I engaged with the team on setting a 3 year plan - Write down what our strategy is, at a high level, and what are the key milestones that such a strategy would hit, if successful. This happened both at the org level and for the individual teams in the org. As the team presented the strategy to the stakeholders we started seeing some gaps in our org structure and the team leads started to raise a desire to organize differently. We recently re-organized the team accordingly. Setting a direction was a critical prerequisite before talking about team alignment. As for measuring success, it goes a bit to the first question I answered - I expect each team to define their own strategy, then set the milestones of that strategy. Our discussion can then be focused on the three elements I highlighted: * Strategy: Was the team able to set a good strategy? * Execution: Is the team hitting the milestone? If not, is it because the execution is not tight, or because the milestones are not achievable and we should pivot? This is a very important distinctions that some people are missing - A team can be executing really well and proving that the strategy is the wrong strategy. Being able to prove that point and move on without wasting years of struggles is a big win! * Org health: Are we hiring well? Growing talent? Retaining talent? How is the cross functional relationships going?

Design a product for drivers driving in rush hour. I am betting every human stuck in traffic has once thought... “Dang this traffic sucks, I wish I could [insert idea].” The best answer I’ve heard is a tablet-sized visual, that is connected to the internet with key apps such as email, song playlist, podcasts, call functionality; along with the capability for partial self-driving in traffic. Once in rush-hour it kicks in, frees your attention to do other things, improves health of the driver by reducing both physical and psychological strain of commuting in rush hours and is highly scalable to autonomous-capable vehicles. I liked the answer because I’d buy this product 🤪 but also because the answer was (1) optimized for reducing real pain points (2) accounted for the future of driving (3) was a little wild, but not too out there. When I heard this answer I could tell the PM was both imaginative but grounded in solving real problems.

I have a very simple framework for building 0-1 product - IVC framework 1. Identify: * The first step in developing any product or feature is to identify the user's needs. Hence, your goal should be to talk to as many users as you possibly can to understand what they say, do, think, and feel. This also helps you learn who you are solving for and who you are not solving for and create a problem statement 2. Validate * Building Conviction by testing Discovery, MVP, market analysis, possible conversion. During this time also you should be talking to customers to validate the problem and solution 3. Create: * Create the right team to build the product and also a plan on how you will bring the product to market.

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'm lucky in that Google has a really rigorous interview process that I benefit from. Google is also known for taking a long time during that process but I promise you that is largely because of the rigor. Post that process though what I look for are three key signals 1. Grit is my first. Big companies are notoriously slow, process heavy, and plodding. But the way I look at this is that with so much user trust, such a large business, and really a huge opportunity that we have to respect we want to get it right. I tell my team all the time that if you want to go fast go alone, but if you want to go far go together. And we've all chosen to go far so grit is critical (and sounds cooler than patience) 2. Passion. Yes this one could seem to fly in the face of the first one. But I often find that I'd rather have somebody always frustrated we can't move faster, always frustrated that we can't do better and help them mature into taking a balanced position than the other way around. Another way to say this is that I can help show somebody the upside of measuring twice and cutting once, but I've never been able to teach passion. 3. Finally EQ. Most of what PMs do depend on building trust and trust is built via relationships. Too much detail isn't likely needed here as this one is obvious but where I will go into detail is that EQ isn't the same thing as being sociable. I have excellent PMs on my team who build strong relationships that aren't loud and in your face extraverts. EQ comes in all shapes and sizes so look carefully.

I have sometimes seen Product teams focus on impact instead of landed impact. And while there is a lot of nuance in that answer I think landed impact is often the most overlooked KPI or OKR or goal (however you like to call them). Teams will goal on number of users or shipping a feature rather than goal on the impact enabled by those metric. Take your typical B2B SaaS for instance. 200 active users of a feature on day 1 is an ok measure of success. But what really matters is what those 200 active users have achieved with your product. Or what those 200 active users have led to in terms of business impact. The visual below is a good illustration of what I mean: https://www.useronboard.com/imgs/posts/mario-water.png

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.

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.

Great question! The move from Senior PM to Director level and above is a challenging one. In general, the change really involves the transition from product management to product leadership. You are typically going from managing one team at a high level with one roadmap and no direct reports to a role managing multiple teams at a high level with multiple roadmaps and direct reports AND driving an effective vision & strategy for your portfolio that brings those elements together AND provide tools and conditions for the whole org to get better at being PMs. Whew! Given the changes in responsibilities, you’re likely going to have to evolve into performing at the Director level so you can set your” opportunity table” for a Director opportunity. Given where the Senior PM level usually sits, here are probably the kinds of skills and experiences you’ll need to try to acquire: 1. Learn how to manage and mentor people. Does your company hire interns? Manage one or more of them! Does your company hire new people that need mentors? Become a mentor! Manage people volunteering somewhere! There’s lots of ways to get skills and experience here, great books too (Leaders Eat Last by Simon Sinek I highly recommend.) But in general the best teacher for managing people is experience. 2. Learn how to build product strategies at the portfolio level. If you’ve gotten to the Senior PM level, you probably know how to develop a strategy for your product or feature. But doing this as a portfolio level is different. It requires thinking longer term about multiple teams with multiple strategies & roadmaps. The best way to learn this skill is to take on the responsibility of doing this or sharing it with your boss or higher-ups. This is a stretch to do in the beginning, but the more you do it the better you get at it. Some good practice is also crafting strategies for products you like or companies you admire. See how many of them come true and how right or wrong you were. Learn, rinse and repeat. I also recommend Good Strategy, Bad Strategy by Richard Rummelt. Amazing book on this topic. 3. Help your fellow PMs in the org level up via skills like org design, policy design, tooling upgrades, etc. Basically practice the art of leveling up a team by creating an environment for PMs to level up and do great work. Think about your own experience doing your best work. What kinds of tools, policies and cultural norms were in place that really helped you level up? Now think of ways you can get from where you are today to that ideal. What tools do you need? What policies need to change? How does the culture need to change? From here, learn how to drive the highest priority items. You don’t need to be a Director for this, you can pursue it by speaking up in feedback forums on these topics, work with your peers or managers to make things happen, etc. If someone was taking initiative here, you can bet managers will be considering them for leadership spots. That’s the high level summary! The opportunity actually presenting itself requires being at a company where there is a need for someone at that level, which requires a bit of luck and timing. So all places aren’t going to be best fits for you, and you should assess that on your own as well. As for types of tracks, PM leadership skills are pretty transferrable. Director, Senior Director and VP are more traditional paths. But I’ve seen old bosses and colleagues go lots of different ways. Something I hear a lot is that the PM role prepares you for being a start-up CEO. Have certainly seen that happen! An old boss is CEO now. But I’ve also seen lots of people end up in Marketing, Design, Engineering, Strategy…there’s no one set path!

A product roadmap is a tool that communicates strategy, goals, metrics, features, initiatives, and timelines to the organization. It is key to achieving alignment and buy-in from leadership and ensuring that teams are on the same page. Regular communication with stakeholders, especially when changes occur, is essential. Below are some key stakeholders and their expectations from a roadmap. * Sales and customer success need to understand feature timelines and the value they add to customers * Marketing needs to understand the initiatives, features, and value to different segments to prepare a go-to-market strategy * Engineering needs to understand the overall vision, outcomes as well as feature details and complexity for execution * Customer support needs to know about enhancements and timelines to keep customers happy Note that depending on the organization, Finance, Legal, Operations and others may also need to be in the loop on the roadmap. By getting a complete picture of stakeholders in your company and understanding each team's needs and communicating effectively, PMs can drive product success and meet customer needs.