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?

We have a great podcast episode about this! To summarize, it’s less about explicit processes and more about tools in the toolbelt. It’s all about right tool, right job. The tools that come to mind for incorporating customer feedback are: 1. User research. This typically involves a full user research team, crafted questions and a lab that users visit to provide feedback on designs, prototypes, live product, whatever is being used for testing. But sometimes it’s something you do on your own with the help of a user researcher. 2. Surveys. This usually involves working with someone that specializes in surveys, product marketing or something you do yourself (very carefully!) to survey customers about what things they like and don’t like about new or current product features. You can also ask about how likely they are to promote the product or feature to their friends, prices they’re willing to pay for products, etc. 3. Customer Support Feedback. This is what customers tell your customer support team if you have one. A great way to collect this is to sit with your customer support team and either field calls yourself or listen in while others are fielding calls. 4. Written Feedback. Can come from a feedback widget on a website or app, app store reviews, emails to the CEO, etc. This tends to be lower fidelity but can be really useful when troubleshooting or looking for lots of feedback volume. 5. Quantitative Data. This is not something people usually think of when it comes to customer feedback! But Quantitative data is really just a data representation of customer feedback. It shows what customers are actually doing. And, when analyzed properly, can reflect what you see in the more qualitative methods above. There are more, but these tend to be the most common ones. Depending on what the need is for a product or feature you’re working on, you might want to use different tools for different purposes and project phases. For example, if you’re trying to redesign a product page for the whole website, it’s worth taking your time. It would make sense to start looking at quantitative data and written feedback early in the process. Then, once you have prototypes to test, user research can play a bigger role. But maybe you have some bigger questions to answer before then, like what kinds of elements do users want to see on these pages? Then engaging user research to help figure that out can be a big help since it’s less structured and more complex. And of course sometimes you need something fast to ship in the next few days. Written feedback, quick surveys and customer support feedback can be really helpful. Each of these tools have some bias baked in as well. For example, written feedback is more biased to more engaged, more passionate users. So it’s good to keep in mind what those biases are and figure out how best to use those tools depending. Great question!

Given that it’s such a nascent function, I think there’s a lot of flexibility – I see that as a good thing! But I know the flexibility can also be daunting, so here’s how I talk about it with my team. Once you’ve been a Product Operations Manager, I think there are four primary paths: 1) Stay in Product Operations – “level up” within Product Operations and find a way to increase the scope or complexity of what you’re working on. At Oscar we have 6 levels for Product Ops, from Associate to Director and we promoted someone this past performance cycle! If your company has only one Product Ops role or title, make the business case for expanding your scope and a title change. Or look externally – many companies are building Product Ops and prior experience can be a huge asset. 2) Transition into Product Management – a benefit of working closely with Product Managers is that you get exposure to what they work on day-to-day. There are overlapping skill sets between Product Ops and Product Management, including translating needs into actionable requirements, strong prioritization skills and a deep understanding of the product you work with. I’ve had folks on my team successfully transition from Associate Product Operations Manager to Associate Product Manager – they enjoy that they’re working earlier in the Product Development Lifecycle. Note: I would be cautious if you are planning to use Product Operations as a stepping stone into Product Management. It can be a very different role from being a Product Manager and you may not get an opportunity to demonstrate Product Management skills in your day-to-day. For most folks on my team, they’ve had to take on side projects or volunteer for work outside of their swimlane to build those PM skills. 3) Transition into another Operations role – if the thing that gets you out of bed in the morning is improving processes or how things function, you may want to consider another Operations role after Product Ops. This could be within Product and Engineering – large Product Design teams are starting to build out Design Ops and/or User Research Ops. Engineering teams can have Engineering or Tech Ops (distinct from DevOps), to focus on optimizing the Software Development Lifecycle, improving Engineering onboarding and/or evaluating tools to increase developer productivity. You may want to get more creative and look beyond the Product and Engineering – the skill sets of organizing chaos, making playbooks, putting structure around things that are ad hoc, etc. are invaluable and very transferable. 4) Transition into Program/Project Management – I believe there is a big distinction between Product Ops and Program Management (I answered another question about the differences!), but there are overlapping skill sets as well. In both roles, you need to make sure people are delivering on their commitments. If your company does not have a specific Program or Project Management function, it’s likely that these responsibilities are bundled with another role – maybe even Product Ops! If your favorite parts of Product Ops are when you are coordinating across teams, tracking dependencies or chasing follow-ups, you might want to consider transitioning into a Program Management role. This can take the flavor of Technical Program Management (which may require specific technical skills) working with engineering teams or more general Program Management, which can span across all lines of business. If this career path is exciting to you and Program Management doesn’t exist at your company, define the opportunity and make a business case for these new responsibilities. There may be an opportunity to incubate the role within Product Ops, maybe as a component of your day-to-day. In talking to other Product Operations leaders, some have had Program Management teams organically form within Product Ops and before spinning them out into their own team.

There are multiple things you need to get right before you start building a product, because the most likely outcome of creating one is that it will fail. To see an example of this you can watch this talk for how we did problem and solution discovery when creating Jira Product Discovery * Validating the problem space is important. For that I think the recipe is pretty straightforward: talk to customers and prospects and let them guide you. It's quite important to go in there open minded about what you're going to learn - because there's a high chance that all the assumptions you made when going into these conversations are wrong, that people don't face the problems you thought they faced, or not with the intensity that you imagined. I'd recommend getting coaching from a user researcher on interview techniques - otherwise you can easily meet with 50 customers and learn nothing. It's one of the most important skills for PMs (and humans are naturally pretty shit at this so it REALLY takes coaching). * You want to land on problems that are felt very strongly and urgently by the people you talk to, and are pervasive. * By doing all this you'll form a view on who your target customer is - you want to keep refining this. And you'll identify potential customers you'll want to work with to shape the solution. We call them "lighthouse users" and it's who you would want to build the solution for: they feel the problem strongly, are crafty and have tried many different solutions to solve them to no avail, they're great communicators, easy to collaborate with and have urgency in solving the problem. Find them, and the rest of the journey will be much easier! Read this post to learn more about lighthouse users. * But on its own it's not enough, there are other aspects to tease out. * You want to be clear on if there is a market - check out which companies play there, try to get a feel for their revenue and growth (there's a lot you can glean about that online); if you can, try to chat with investors who gave them money; understand the maturity of this market (early adopters, early/late majority, etc.). * You want to have a thesis for how you can win - e.g. do you have a distribution advantage, access to tech that's hard to reproduce, other? Note that the best product doesn't necessarily win distribution is going to be key to answering this question. * Distribution is super important and what will make or break your product. It's a good idea to validate demand and your ability to reach potential customers. In the past I've done this by creating and advertising a landing page on a website stating the problems and asking people to join a waitlist. That's how we knew we were onto something in the early days of Jira Product Discovery - within 3 weeks we had 3000 people on the waitlist (which contained zero information about the solution). * You need to have a clear answer on "why now?" - the problem needs to be felt really strongly and urgently by customers, maybe there is new tech opening new possibilities, maybe it's the right moment for your company to invest because of strategic reasons, etc. But you need to be clear on why this needs to happen now vs next year. * If you're in a bigger company with cash at hand, assess build/buy/partner opportunities - before jumping straight to creating something a new product: is there another company you could buy instead of building, and fast track everything by a couple of years? * Even after answering all this I wouldn't jump straight into asking for engineers. I'd only do that if we're not clear the solution is feasible, e.g. if it requires new tech that we don't master. After problem discovery, don't skip solution discovery! There's a lot you can/should validate without writing code: * In the past I've shown people slides with value propositions and asked them to explain back to me how the solution would help them. There's a lot I learnt by doing that! * Create prototypes, in Figma, or live prototypes than people can play with. You can gauge the reaction of the people you give them to: if they "just" look enthusiastic about the solution you can throw it away. If they're straightaway asking you if they can please please please start using it tomorrow then you know you're onto something * Even if you ask for an engineering team: start with technical spikes and prototypes, the goal is to validate the solution solves the problem and is feasible. All of this will also help you refine your understanding of the problem space (problem <> solution work hand in hand) You can also read more about it in the Atlassian Product Discovery handbook, that we wrote to help with things like this. Check out the "Ideas" section.

At a high level, a 0 --1 product offers a completely new solution or functionality to a user problem, often creating a new market category or sub-category within an existing large market. The top thing in developing a 0--1 product is validating that there is a real user need in the market that will be served/solved by this new product, and, that the need is big enough to build a viable business around it. * Identifying/defining the top user persona for the product – their motivations, goals, tooling needs, and pain points with existing solutions, if any * Defining the buyer persona (if different from the user) – motivations, incentives, goals for themselves and their teams, and pain points with existing solutions, if any * Understanding the market – what existing market segment or category would the new product fit in, the competitors, incumbents, market sizing and basic TAM (total addressable market) analysis to validate there is a big enough market (or potential market) to build a business * If creating a new market category with the product, it is still important to understand what is the closest market segment to the new category you want to create. It helps gauge the TAM for business development purposes as well as the closest competitors to the new product.

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.

A super common question! Traditionally the term "product manager" can often mean different things depending on the size of the company, the product's stage, and sometimes the overall market segment. I often times bucket them into these core groups: 1. Technical Product Managers (TPM): These PMs work closely with engineering teams on more technical products, thinks like API driven products where the end "customer" is technical in nature. For these roles, you will need a deeper level of technical expertise and the ability to understand the technical aspects of your customers needs. 2. B2C (Business to Consumer) Product Managers: In a consumer-facing environment—like mobile apps, e-commerce platforms, media consumption products — I find that PMs often emphasize UX and product design (along with core PM responsibilities). One of the key areas that this group focuses on is leveraging a typically broader/larger customer base to do things like A/B testing, and quick iteration on product designs to validate assumptions and feature value. 3. B2B (Business to Business) Enterprise Product Managers: These enterprise PMs focus on delivering products that solve businesses' complex problems. I spent a lot of my career here and this type of PM spends a lot of time on sales enablement, strategic account engagement, and roadmap management. Given that most B2B solutions have a longer sales cycle, their relationship with sales is key to success. Depending on the size of the organization, this type of PM also focuses a lot on the financial side of the product. 4. Infrastructure Product Managers: These PMs (sometimes internally facing only) focus on building components that other teams and products rely on, oftentimes within an organization. For them, the GTM isn't as relevant but they need to understand and balance things like scale, interoperability, and business alignment. Figuring Out Your Best Fit: 1. What are your Interests: Consider things like Do you enjoy getting into the weeds on technical discussions? Do you more get energized by user research and design? Do you geek out over analytical data and love looking at usage metrics to drive feature development? Each type of role has a different focus, so find the things that excite you. 2. Consider the Environment Do you want to reach a huge market of customers and iterate on minor feature developments and enhancements? Or do you want to work closely with larger business customers and develop a deeper understanding of their problems and how your product can evolve to meet those specific needs? No right or wrong answer, just what gets you pumped up each day. Remember, it’s about aligning your career desires, your core strengths, and the types of challenges that get you fired up to solve each day. We are problem solvers, so what types of problems do you love solving and how do you like solving them? Many PMs start in one area and end up in another. All the roles share a common framework of ensuring we are delivering business value for our organization and delighting our customers with innovative and useful solutions to problems they either have or don't even realize they have yet.

A few things: * A very deep understanding of the problems they are looking to solve. This gets reflected in how they speak about past experiences (why did you choose to work on a specific problem, what exactly was the need?) as well as any case study (are they asking intelligent questions to understand the need). * User-first approach: While solving the problem they identified, are they putting the user at the forefront? Are they clear about who the users are for the problem? * Clear communication * For more experienced positions and specific for B2B products, are they mature to understand roll-out considerations for a large group of stakeholders? What are the people and processes needed to make a roll-out successful?

I transitioned from journalism to product management earlier in my career, and although it’s not a straightforward path, it’s actually pretty common for PMs to join tech from other sectors. An Asana PM teammate of mine, Ari Janover, actually has the best articulation of how to make the transition that I’ve ever heard. He says there are three common paths: * The Ninja: Join a small startup as another role and push to own PM work until you become a PM. * The Expert: Apply for roles where the value of your specific knowledge trumps your lack of PM credentials. Think Engineers for technical products or a real estate agent for a real estate tool. * The Hail Mary: Follow the few PM Apprenticeships that don’t require previous experience (learn more about AsanaUp here). I followed the Expert path when starting out, and I’ve seen it work quite well in early-stage companies. One of the biggest challenges in starting in an early-stage company, though, is that you’re often the first or only PM, so although you have lots of things to learn, you may have fewer people to learn from. I spent a lot of time observing and learning from PMs at other companies and building up a group of folks I could exchange ideas and challenges with, and this is a practice I still find incredibly useful today.

Alignment can be a challenge for platform product managers since you usually have more than the average number of internal stakeholders and increased cross-team dependencies to get your work done. At best you have the potential to have a large scale impact, at worst your projects get blocked by another team. That’s why it’s critical to gain alignment across the broader platform. When striving for cross-team alignment, I always tell my teams to think in ‘spheres of influence:’ * Start with your immediate team: Work with your team to prioritize your product roadmap based on customer feedback and data. Make sure your team is bought into the work before circulating too broadly. * Expand to your larger product area: Most teams do quarterly planning, so once you and your team know your quarterly roadmap, I highly recommend circulating it to your broader product area, which includes teams that you partner with closely. You want to identify any cross-team dependencies as early as possible and get the work prioritized on their roadmaps if necessary. Since you usually partner closely with these teams and you’re probably also doing work that their teams need, the hope is that you can negotiate getting onto each other’s roadmaps. * Expand to the entire product organization: Since platform work has a broad impact, you usually want to let the wider product organization know what you’re working on as well. This can help you identify early unintentional impact you may have on their teams or even better, ways they can benefit from your work. Usually you have a good sense of your key internal stakeholders so you may be able to limit alignment to a few key teams outside of your product area, but it never hurts to let the broader organization know what you’re working on.