Get answers from product management leaders
Mckenzie Lock
Netflix Director of Product • August 4
The candidate must “spike” (“8/10” or higher) in all of these areas, in order of importance: 1. Critical Thinking Given how many decisions and complex problems are thrown at PMs, this the #1 most important attribute I screen for. They don’t need to be a rocket scientist (top 0.5% of population) but they should be exceptional at this (top 5%). Good looks like: * Take large ambiguous problems and break them down into smaller pieces * Uses logic to convince others * Gets to the root of the issue: Think about things from multiple angles but then focuses on what matters (this is key and hard to find). The more senior a candidate the more critical thinking/problem solving looks like: starting the why and bigger picture, being principles-based, helping others to structure their thinking (good frameworks, simplifies and structures conversations etc.). I usually test for this both in the initial phone screen and through a product thinking interviews (case questions, panels) 2. Drive PMs have a lot of responsibility, get very little direction, and get too much credit and blame, so they need to a) self start and b) be motivated to keep trying even when faced with obstacles. Good looks like: * Ownership over outcomes vs. just doing the activities? A former manager of mine once called this “an insatiable desire to ship” * Self starter - Can we throw them at a problem and trust them to figure it out without hand holding? * Vigilance - do they generally think ahead to the outcome they are trying to achieve? Do they proactively address what may get in the way? This is very hard to screen for in an interview but you can get signals from behavioral questions, their questions to you, and follow ups. 3. Bridge Building There are two parts of bridge building 1. EQ - not easily coachable 2. Communication - this includes both written and verbal communication skills and both the quality and frequency of comms. Verbal and written comms are usually coachable. It’s ok if someone isn't a perfect communicator because people improve on this over time. But it’s not ok if they don’t have sufficient EQ. Good looks like: * Self aware - seeks to know (and improve on) their own strengths and weaknesses, self reflects without defensiveness * Situationally aware - skillfully navigates people situations and figures out how to influence others towards an outcome * Concise and clear answers that are easy to follow, verbally and written. I usually test for written and verbal comms in the panel exercise and interview questions. I test for self awareness and situational awareness in behavioral interviews.
...Read More16868 Views
Upcoming AMAs
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.
...Read More23761 Views
Tom Alterman
Notable Head of Product • May 17
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.
...Read More9703 Views
Vasanth Arunachalam
Meta Director, Technical Program Management | Formerly Microsoft • February 3
It could be a combination of any of these things - * Look at data (dashboards, customer feedback channels, internal partner team feedback) to check progress (on product success, platform performance) -Take any actions necessary (filing bugs, resolving a SEV) * Supporting your cross functional team to deliver on roadmap projects -Brainstorm product and technical solutions. -Sprints, design reviews, code reviews -Removing blockers * Look at data to proactively surface opportunities, hot spots, technical bottlenecks etc * 360 communications often tailored meticulously for the target audience * A lot of meetings (Product reviews, Roadmap planning, Decision making etc) * Ideating and planning for the future (Strategy) * Upkeep or morale and motivation for team. TPMs often act as the glue for the entire team. * And ideally they are having loads of fun doing all these
...Read More4239 Views
Boris Logvinsky
Vanta VP Product • December 12
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.
...Read More4564 Views
Ultimately Product Management is about people. I do approach stakeholders differently, but it’s based on who they are, rather their role. Some stakeholders like to be consulted ahead of time, some prefer being briefed in bigger forums where they can gauge the reactions of others. Some like structured approaches, others react to the anecdotal evidence. Some may have specific trigger points on specific topics. Part of my role is to understand those differences and be able to navigate through them.
...Read More8366 Views
Rodrigo Davies
Asana Director of Product Management, AI • May 17
* I get frustrated whenever I hear business outcomes and customer outcomes described as two forces that are in tension, and that it’s necessary to choose between either building a fantastic product or having a fantastic business. It’s certainly possible to have a highly profitable business with a shoddy product, but I believe that the advantage that organizations gain by going that path is short term, and that eventually a poor product experience will erode trust and lead customers to move on to better products. * This is especially common in new product / technology areas, where some companies optimize everything around being the first to launch something in order to capture the so-called first mover advantage and build a moat. Looking back on the last few software innovation cycles, there are many examples of where the second, third or even fourth product to market was the eventual winner, by prioritizing nailing the customer experience and learning from others’ mistakes, over pure speed.
...Read More4882 Views
I would say there is no substitute to real user data. User research is table-stakes. But in my experience, not always representative of "actual" usage, so don't overindex on specifics. Rather validate if the problem statement is indeed important for the user segments. Because if it is, then they might be more patient with your iterations towards solving their needs. Else they are very likely to abandon very early on and never return. A good way to test is whether they are willing to pay for the solution. Paper mocks UXR is helpful once you have narrowed themes and want to develop MVP scope. Then go build MVP and ship to a small user segment to learn and iterate. This step is the journey. Scale up only when you see hockey sticks for atleast one feature. Also retention loops should be naturally showing up by then.
...Read More5956 Views
Mani Fazeli
Shopify Director of Product • December 14
Products must have some connection back to profitability, helping to either increase income or reduce costs. You otherwise wouldn't want to make an investment unless you're choosing to make a donation to the greater good (e.g. open source). It's OK if that connection is indirect, and in some cases, even difficult to measure. The latter requires leaders to agree that the approach to measurement is inline with the values and product principles of the company. It's easiest to use examples, and I'll go to the extreme to make my point. Every piece of software has a substrate and lattice work of capabilities upon which all the direct value driving features are built. Take your administrative dashboards, navigation UI, settings pages, notification systems, design systems, and authentication and security features. In the modern web and mobile landscape, it's dubious to think investment in any of these areas can be causal to growth and differentiation. But not meeting the Kano "threshold attribute" means that your product will feel janky and poor quality, which can lead to poor adoption or retention (and good luck with attribution there). Therefore, you need continuous investment just to meet the bar of expectation and that means time away from other KPI driving initiatives. There is no way to get there without the product principles that make space for this type of investment and improvement. Principles have to be paired with health metrics and trip wires that help diagnose the lack of investment (e.g. task completion time, dead clicks, clicks to navigate to common actions, duplicate code, account takeovers due to lack of 2FA, etc.) I learned the phrase "anything worth doing is worth doing well" from Tobias Lütke. At Shopify, we've created a culture where improvements in many of these examples I shared are celebrated and seen as table stakes. The same is true with things like API performance, UI latency, and UX consistency. All of this takes time and investment, and we uphold it as part of the "definition of done" for most projects. We were a much smaller company at Wave, but still made some investments in our substrate to maintain our perception as the easiest to use financial management software for small businesses. Let's circle back to products that are not directly monetized, but also not part of the substrate of software. The technique to measuring impact is about identifying the input metrics that ladder up to higher level KPIs that do ladder up to revenue. For example, the ability to do per-customer pricing is a feature expected of business-to-business (B2B) commerce systems, but not direct-to-consumer (D2C) ones. But no merchant adopts a B2B system for that single feature alone, and to some, that feature may not even matter. So while we measure win/loss reasons from the sales team along with churn reasons, we also measure usage rates of the feature and impact of per-customer pricing on average Gross Merchandise Volume (GMV) per merchant. Put another way, we're looking at the relationship of leading metrics and the KPIs that ladder up to, thus telling us how we should invest further in per-customer pricing.
...Read More4069 Views
Clare Hawthorne
Oscar Health Senior Director, Product Operations • March 22
Unfortunately there’s no perfect ratio – each Product Ops team I’ve run or learned about has a very different structure and mandate! I’ve heard of successful models with Product Ops to PM ratios of 50:1 and of 1:1, so it’s less about the number and more about working with what you have. If you understand the pain points of product leadership and front line PMs, you’ll be able to develop a strategy that delivers value to the Product team regardless of the number of resources you have. That being said, I do have two rules of thumb I’ll share about resourcing: * If you are embedding Product Ops within pods, target 2-3 pods per Product Ops resource. While it’s not a perfect science, I’ve noticed other embedded functions (like Program Managers, QA Analysts, Scrum Masters) try not to go beyond 3 pods. It makes sense – more than 3 pods and sprint ceremonies alone would take up most of the calendar! If your pods are especially big or complex, you may need to stick with a 1:1 ratio, but this can be a very tough resourcing ask if you don’t have a track record for results. * If you are a Product Ops team of 1-2 and have a PM team of ~7+, you should be looking for work that can impact the whole Product organization – you do not have enough resources to embed with specific pods! These may include things like optimizing the Product Development Lifecycle or creating a standard Go-To-Market checklist. Remember to engage stakeholders early and often and I highly recommend piloting your recommendations with a subset of the department!
...Read More1837 Views