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.

0 -1 product development refers to building a new product or service line from scratch (0) to bringing its first iteration into the hands of customers and users (1) The first step to develop a 0-1 product is to deeply understand the market need. I look at this from the buyer perspective, the end user perspective, and the competitive landscape perspective. Unless you understand, what's needed, what exists, what's missing, and what will differentiate your solution and validate your need to exist, you cannot begin the next phase, which is product definition. 

At Asana, we don't use leveled job titles to indicate seniority (e.g. Product Manager III or Senior Director of Marketing), but that doesn't mean that we don't have management structures in place. Instead, we use Success Guides for every team that help employees understand what success looks like for each role level at Asana. Another way we demonstrate ownership and growth in role is Areas of Responsibility, key areas of the business that have one designated owner who is responsible. AoRs act as a directory so employees easily can understand who does what, and they offer employees additional ways to stretch and grow outside of a traditional role structure. * As a more junior PM you are working on a well-defined initiative driving the backlog of a single program team or large workstream within a program team. You contribute to the strategy for a program, while the high level elements are largely defined already. You drive work with end-to-end responsibility around execution in a problem space that is fairly well defined. At this stage you are open and curious - your growth mindset is a career accelerant. * As a more senior PM you have a lot of autonomy in running a program team or large workstream within a program team, and are thinking boundarylessly outside your program to drive a seamless customer experience. You may be contributing to multiple backlogs and your work likely touches experiences that are owned by others. You are expected to set the strategy for your program or workstream based on the broader pillar strategy. This strategy must help Asana win. The work that you tackle is difficult, ambitious, ambiguous, and does not have a clear solution from the outset. You coach other PMs informally, and may seek out a more formal mentorship opportunity. Once someone is demonstrating all the competencies at their current level, we then start giving them extra responsibilities. It is only after demonstrating those new competencies consistently do we decide they are ready to be promoted.

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!)

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!

Success metrics and voice of the customer. Ideally, at the time of defining a product strategy, you’ve also invested time in thinking about specific Goals that are important to measure progress against it. The goals should be time bound and specific and may include product usage, customer satisfaction, and financial performance. Several product organizations (including HubSpot, Google, Spotify, Twitter, LinkedIn, and Airbnb) like using the Objectives and Key Results (OKR) framework. Metrics are important, but at the end of the day, the best true north is the voice of your customer. If your customer is happy, the rest will follow.

I love this question because it flips one of the previous questions to focus more on the individual. IMO the success of a Technical Product/Program Manager largely lies in the ‘What’ and the ‘How’. What impact did they have? This individual measure of success should be tied to the business (product or platform) goals. The TPM should directly be held accountable for delivering on those goals. This is also the (relatively) easy part to measure (Eg: How many new users signed up for the app?, How much incremental revenue did the feature bring?, Did the platform ship on time?“ How did they land that impact? This is the ‘hard to measure’ part. For a TPM it is equally important to demonstrate leadership qualities such as - high EQ, deep Empathy, Conflict resolution, crisp communication, ability to influence without authority etc and overall be a kind and respectful individual. Often peer feedback has proven to be an effective means to gather these signals.

No-one can, or should ever be sure that they have a 100% right product strategy. But you can do a lot to de-risk your approach, and your tactics should vary depending on how much time you have to plan. * Is your strategy ultimately going to drive the change in behaviour you want? Find the key participants in your strategy -- e.g. the customers -- and talk, talk, talk to them. You'll learn a ton from the first 5-10 conversations, and suddenly you'll start to hear the same themes and be able to predict what they'll say. Then you can move on. * Read, and connect with people who are familiar with this situation in your industry or other industries. How did things work out? Is the current market / environment similar enough that you can draw conclusions? * The more experienced you are, the more confident you can be about relying on product intuition. A phrase I often use is "we've seen this movie before" and, it's surprising how many times the same situation gets repeated.

The most important thing you can do as a new head of product is to align with the founder/s and/or your manager on what your role is. Most people assume they did this in the interview process. Yet, misalignment on this question are the most common reasons heads of product fail. You want to know: 1. How will I be evaluated? “In 1 year, what evidence will tell you I’ve been successful?” Make sure they are specific. For example, if they say something like, “customers are happier,” follow up with: “what’s an example of something that would give you confidence customers are happy” This tells you what outcomes you’re being evaluated against. 2. How much autonomy will I have for which product decisions? The best piece of advice I've received is to ask a new manager or founder, "What decisions do you want to make? What decisions do you want me to make but run by you first? What decisions do you want me to run with entirely?" This tells you how much autonomy you have on what. Once you understand these things create a 6 month plan that incorporates a few things: 1. Quick wins - ask your manager, their manager, your team, and your peers, “what do you need most from product management?” Use this to identify a few quick wins you can deliver to build trust. 2. Start with the low context decisions - a lot of new Heads of Product make the mistake of trying to define a product strategy too early. This is often a mistake because such decisions require product context, organizational context & an intuition for the space. Instead start by making decisions you don’t need a lot of domain context to make - who to hire, how to uplevel the team, how to improve your product process, etc. For product decisions, start small by picking a few projects/or areas to go deep on before building out a larger strategy. In all of this, setting expectations is your best friend. Once you’ve aligned with your manager on your plan, be sure to set expectations with the organization about what you’ll be focused on in what order.

Product management decisions should ideally be data-informed rather than purely data-driven. Being data-informed means leveraging data to guide and support decision-making, while also acknowledging the context, the subtleties of customer behavior, and the broader market trends that quantitative data might not fully capture. Data is invaluable for validating hypotheses, understanding user behavior, and measuring performance against goals. However, it's equally important to recognize the limitations of data and the potential for it to lead to suboptimal decisions if relied upon in isolation. Product Managers should indeed lead with an informed intuition—a blend of experience, understanding of the customer, and strategic vision. This intuition is then refined and validated through the use of data. By using data to back up assumptions, Product Managers can challenge their biases and ensure that their strategic direction is grounded in reality. Ultimately, the most successful Product Managers are those who can adeptly interpret data, understand its implications, and also know when to question its suggestions. They balance the art of intuition with the science of data, using each to enhance the other. This holistic approach allows for innovation and creativity, driving product decisions that resonate with customers and succeed in the market.