Get answers from product management leaders
Marion Nammack
Braze Director of Product Management • February 8
The level of detail that people on other teams need depends on what they are using the roadmap for. Our roadmap planning tool enables us to create multiple views of the roadmap - we tailor each view to the use cases of the consumers. For example, we have the following views: * A view for our quarterly planning process - this view is primarily used to communicate to execs so it focuses on the high level business goals that each roadmap item supports and doesn’t contain many implementation details. * An internal view that go-to-market team members can use to understand estimated delivery dates for items in active development or beta - this view contains much more detail - for example the user needs that the release addresses and how to sign up for betas. * A public view that is available to our customers - this view contains customer facing explanations of each project and information on how our customers can help us develop it. For example, an item might have a few questions about the customer’s use case and interested customers can send us answers to those questions.
...Read More13750 Views
Upcoming AMAs
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!)
...Read More12315 Views
Clare Hawthorne
Oscar Health Senior Director, Product Operations • March 22
My “north star” vision for the Product Operations team is to “unlock Oscar’s ability to ship more product, better and faster.” While this is a pretty broad statement, I want to highlight a few elements. 1. Product Operations is not a function to make the life of a Product Manager better or easier. We do not “support” Product Managers. Our focus is unlocking Oscar’s capacity to ship software. In our context, this means that Product Ops focuses on the goals and delivery of our engineering pods. If there are opportunities to increase efficiency of engineering or design, those are on the table. 2. Product Operations adds value in a few different ways. Here are a few examples: * Ship more product - We can maximize the time each member of the pod is spending at their “highest and best use.” This may mean that Product Ops takes on execution oriented work while we advocate for automation or create an operational process. * Ship product better - We can improve product quality by ensuring that we follow necessary testing protocols, or ensure downstream teams are fully enabled before product releases. * Ship product faster - We can create efficiencies by building repeatable processes and playbooks, both for ourselves and for other stakeholders. In real life, this might manifest as a Product Ops Manager taking on the product launch process for a particular pod, which frees up capacity from the Product Manager and the Tech Lead (ship more product). Product Ops can ensure that their operational counterparts have visibility into the feature work and are communicated about launches in a timely manner (ship products better). Product Ops then codifies this improvement by creating a product launch checklist for themselves and other feature teams, thus avoiding “recreating the wheel” for each team (ship products faster).
...Read More2514 Views
Ajay Waghray
Udemy Director of Product Management, Consumer Marketplace • August 25
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.
...Read More5542 Views
Shahid Hussain
Google Group Product Manager, Wear OS • May 21
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?
...Read More2360 Views
Lizzy Masotta
Shopify Senior Product Lead | Formerly Salesforce, Google, Nest, Cisco Systems • November 17
I don’t believe in a universal end-to-end product development process. I believe there are key rituals and elements that should be present on every team to ensure great outcomes, but each team needs to tailor the development process to their unique situation. My must-have product development elements & rituals: 1. Common Language - Your company should have a common language for the product development process. This is not a prescribed way to do product development for every team at the company (this needs to vary team by team for good reason). At Shopify, we call it GSD (get sh*t done). The base elements are a common language around Product Development stages: 1) Proposal 2) Prototype 3) Build. We have an internal system at the company where you can look at all development projects and the stage that they’re in, how long they’ve been in that stage, when they’re expected to go to the next stage. We also have a common calendar of 6 weeks sprints that is used by the company wide. This helps when you’re having a discussion around when do you think you will have x? This transparency and common language is key. 2. “Agile Research” - This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, providing feedback, etc on an ongoing basis. 3. Continuous Product Discovery - A common misconception around PMs is once a project is kicked off and being prototyped their discovery work is done. Discovery is a never-ending job. There is a lot of work to be done up front to define the problem and opportunity more broadly, but throughout the development lifecycle there are endless sub-problems that need to be found, defined and shaped. 4. Unstructured Live time with the Product Squad - At Shopify, we refer to this as "Jamming." This is the schedule I tend to implement on my teams: Monday - Problem Shaping, Wednesday - Live Prototyping, Thursday - Fresh Eyes, Friday - Demo. Monday and Wednesday sessions are unstructured live time with the Product Squad. PM, Eng, UX, and Data get on a call and stare at the Problem or Prototype together. PM guides the Problem Shaping meeting and UX guides the Live Prototyping meeting, but the purpose is to tap into all the brains on the team to get to the best outcomes. It can be terrifying for a lot of people. It’s like getting in the car without a destination in mind. You need to create a culture on your team where it’s ok to not have all the answers. To prepare, the PM can have “intended outcomes”, “problem definition” or “options” prepared. During the meeting, the PM facilitates getting insights from the group around what else to consider, what’s missing, etc. 5. Progress every week - Another cultural thing - you need to have rituals on your team to encourage and ensure progress is made in some way, shape or form every week. My favorite way to do this is the weekly demo AND ensure that not only eng presents, but also folks from PM, UX, etc.
...Read More1231 Views
Bhaskar Krishnan
Meta Product Leadership - Ads, Commerce & AI | Formerly Stripe, Flipkart, Yahoo • January 17
This is a very interesting question and one that I keep touching upon on almost all career conversations with my teams & mentees. There is no one typical career path for PMs, which can be both liberating and challenging at the same time! It's liberating since PMs have the chance to shape their careers to what they would like it to be, playing to their strengths and having a fulfilling life & career. It's challenging since every industry and many firms in the same industry have different definitions & requirements for what a PM is! For instance, even within FAANG firms, the definition of a PM is different - Google requires PMs to market the work of their Engineers, Apple PMs are usually good at their domain of expertise but execute on Sr Management decisions, Amazon PMs are Business/ Program Managers with heightened focus on a few metrics, Netflix PMs are very Technical (most of their PMs were former Engineers or Architects) and Meta offers almost the full buffet but also the most agency & empowerment to PMs. I touched upon some of the PM archetypes in another answer and its great to see that PMs can succeed in any shape or form tht adds value to their firm! PMs who are early in their careers will do well to join established firms to understand the PM tracks and how senior PMs have shaped their careers. Working in a start-up or a 0-1 environment usually turbo-charges a PM's career but only if the PM is aware of their strengths & know-how to leverage them. I have found that alternating between large firms & startups or between established products/ projects and 0-1 initiatives is the best way one can gain the most perspective and shape their careers as PMs.
...Read More3097 Views
Mckenzie Lock
Netflix Director of Product • August 3
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.
...Read More1940 Views
Suhas Manangi
Snap Head of Product - Trust & Safety • June 6
Being a good PM helps becoming a good manager of PMs, but is not a sufficient condition. I have seen below 3 as top challenges/opportunities unique to GPMs: 1. Deligating, and trusting your direct report PMs to care about Customers as much as you do, if not more. 2. Providing saftey net for PMs to fail fast, learn, and iterate, but as well the essential framework on lowering the cost of failure to ensure contribution to business impact. 3. Knowing that PM skills are not hard to aquire, but takes time. Coaching the team on specific PM skills need persistence and patience. It is not like you launch a product, and you see a metric go up instantaneously.
...Read More4115 Views
Don't think there's a "right" ratio, but I would say 1 PM to 6-12 engineers is a good ratio. I think beyond 12 engineers, it gets a little difficult for a PM to stay on top of projects and the PM could become a bottlenect to project progress. I would also say 1 designer to 6-12 engineers is a good rule of thumb.
...Read More1903 Views