Get answers from product management leaders
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
Upcoming AMAs
Generally, I am thinking of success in 3 dimensions: Vision, People and Execution. All three need to work well for a team to succeed over time. Early in your career Execution takes a bit of a higher focus. You can get your first 2-3 promotions by launching bigger and more complex projects. However, as you grow in your career the ability to offer broader, more ambitious vision and have others join you in the journey become more central for your success. Your already proven execution skills help in attracting people to work with you since they know you will deliver. It’s important to invest in all three dimensions throughout your career, since honing these skills takes time. When I joined Meta I was excited to find out that here we are formally aligning PMs expectations with similar axes: Impact (which includes Strategy and Execution) and Capacity Building (which includes healthy team and cross functional relationship as well as broader contributions to the organization). I believe this structured view creates the right incentive and culture.
...Read More13486 Views
Ajay Waghray
Udemy Director of Product Management, Consumer Marketplace • August 26
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!
...Read More21652 Views
Laura Oppenheimer
Bubble Group Product Manager | Formerly Quizlet, Chegg • July 29
Part of the fun of building something 0-1 is that you have a green field in front of you — you can build anything! (Or that's what we wish as PMS....) As much fun as it would be to the world is your product oyster, constraints help provide focus and a direction. I see the first step is making sure that you and stakeholders are aligned on what a goal or success looks like. And usually, that comes in the form of a metric that you're trying to move. If you work for an ecommerce company, you'll make very different decisions around what to build if your metric is increasing ASP versus unlocking a new vertical or segment. If your metric was the former, you might start doing user research on customer willingness to pay, or what they're thinking about when they're in the check-out flow. And if it's the latter, you'd probably start with user research into people who aren't yet your customers. Without that first constraint — what metric do we want to move, what does success look like — there's no way to focus your research and problem defintion phase. Once you have that north star to work toward, you can enter user research with your specific goal in mind.
...Read More8558 Views
Ravneet Uberoi
Uber B2B Products | Formerly Matterport, Box, McKinsey • August 31
One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your product? (Risk can be defined crudely in terms of Low, Medium, High or in some cases you might have a model with some sensitivity analysis built in). Regardless, if you can quantify the risk (and thus impact) of the problem to the final solution, you have a clear blueprint of where to begin. A related method is to consider one-way vs two-way decisions. One way decisions are challenging or impossible to reverse - these have multiple downstream effects on the solution. Two way decisions can be reversed easily or adjusted over time once you have more data. I prefer to focus my time and energy on one way decisions first, as these will build the pillars of the product. If there is considerable time or effort spent by your team on a two way decision, you can make the argument to come back to this once you have more information or once all the one way decisions have been made.
...Read More10382 Views
Avantika Gomes
Figma Group Product Manager, Production Experience • December 22
Congratulations! Being the first PM at a company can be a really exciting and formative experience, in shaping the product vision and the product organization. Here's a few things I'd suggest: * It's all about the user - user needs, user problems, user stories! Spend a lot of time learning about your customers, their needs and what they're looking for from your product. * Make sure you socialize what product management is, what your key responsibilities are, and how cross-functional partners should work with you. A "PM" can mean different things to different people, so make sure you tailor this to what your company needs and then communicate it out. * Set up your product processes early. For instance - start simple with a product launch calendar, some task management process (e.g., an agile process in JIRA or Asana), etc.
...Read More3770 Views
Mani Fazeli
Shopify Director of Product • December 15
Service Level Agreements (SLA) are driven by three factors: (1) industry standard expectations by customers, (2) differentiating your product when marketing, (3) direct correlation with improving KPIs. For checkout, you'll have uptime as an industry standard, but it's insufficient because subsystems of a checkout can malfunction without the checkout process outright failling. You could consider latency or throughput as market differentiators and would need instrumentation on APIs and client response. With payment failures or shipping calculation failures, you would directly impact conversion rates and trust erosion (hurting repeat buying), which are likely KPIs you care about. So your SLAs need to be a combination of measures that account for all of the above, and your engineering counterparts have to see the evidence that these matter in conjunction. Of the three types, the one that's most difficult to compare objectively is the third. In your question, you mention 1.5% error rates. You could go on a hunt to find evidence that convinces your engineering counterparts that these are elevated vs. competition, or that they're hurting the business. What's more likely to succeed is running A/B tests that attempt to improve error rates and demonstrating a direct correlation with improving a KPI you care about. That's a more timeboxed exercise, and with evidence, you can change hearts and minds. That's what can lead to more rigorous setting of SLAs and investment in rituals to uphold them.
...Read More3535 Views
Maxime Prades
Meta Director of Product Management | Formerly Algolia, Zendesk • November 29
As a product leader, the single most important activity I prioritize is attempting to build an amazing team. A players attract A players and building incredibly diverse, smart and committed teams is the single most important job of a product leader. People come and people go, as a product leader you're always hiring. One of my former boss said to me once that once you team reaches a certain size (~10/12 people) you're always hiring. Something always happens, (internal/external mobility, reorgs, hiring spree, layoffs, performance management etc...) and you end up always hiring. So staying ahead of the curve, networking, always having your next hire in mind and keeping an active pipeline is key, but also ensuring your key players are properly incentivized, motivated, fulfilled and have room to grow and do what they do best is critical too. I know this isn't the original question but I can't help myself 😊 The second most important activity I prioritize as a product leader is keeping up with the product and keeping up my product knowledge. Staying close to the users, the sales teams, the detractors and understanding the ins and outs of your product will contribute to make you a strong product leader.
...Read More1479 Views
Ingo Wiegand
Samsara Vice President of Product Management - Safety • March 31
* At a high-level, I usually like to think about the somewhat simplistic delineation that PMs decide ‘what’ to build, while engineers deliver the ‘how’. * Ultimately, prioritization comes back to thinking about the ‘return on an engineering investment’. PMs provide the ‘return’ (i.e., user value), engineers help size the necessary investment. No feature can ever be properly prioritized without both sides of this equation. * Getting buy-in from engineering usually comes from a deeper involvement and collaboration of engineering and PM as part of roadmap and prioritization discussions. A few things to keep in mind that have always helped me in the past: * Ensure alignment on the problem you are solving: PMs should be able to clearly articulate the customer problem that is being addressed and ensure their engineering counterparts have the same understanding of this problem. Additionally, it’s crucial to ensure that both PM and engineering agree on the success criteria and definition of done. This upfront alignment can help resolve a lot of friction that might otherwise occur further downstream in the planning or product development process. * Collaborate with engineers during planning/scoping: once you have alignment on the problem you are solving, it will become much easier to collaborate and jointly problem solve the right solutions for a given feature or product decision. Your engineering team will develop a more intuitive understanding of your customers and in turn might think of additional (creative) solutions that can significantly enhance functionality or improvement development time - engineers are experts in figuring out what options exist to get things done within given system/tech limitations. * Once you have jointly worked through a project or full roadmap, the issue of ‘engineering buy-in’ usually disappears given the amount of agency PM and engineering had in shaping their plans together.
...Read More3371 Views
Mckenzie Lock
Netflix Director of Product • August 4
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 More1895 Views