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 More17259 Views
Upcoming AMAs
As you progress from PM to senior PM, competencies in these 3 areas should grow: Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications that someone is ready for the senior level, like increased scope, being a reliable partner and being results driven. Here are some less obvious ones: #1 You recommend initiatives based on your strategic evaluation, instead of waiting for them to be handed to you. You are influential in your field and feel confident putting forward these initiatives. #2 You leverage relationships across the org. You can drive results from partners outside of your immediate team. You are fully entrusted to tackle complex, multi-team problems with little necessary supervision. #3 You are seen as an available and trustworthy mentor and actively seek out opportunities to help others be their best. This is my favorite by far. What are the key stages that distinguish the different levels of PMs? I think a little bit of this depends on the problem space and company. In my mind, PMs are professional collaborators, strategic assassins and bring out the best in their peers. If you can look yourself in the mirror and say you’re doing these things at scale, well, I’d say you're on the right track.
...Read More15115 Views
Hiral Shah
DocuSign Director of Product Management • March 31
I have a very simple framework for building 0-1 product - IVC framework 1. Identify: * The first step in developing any product or feature is to identify the user's needs. Hence, your goal should be to talk to as many users as you possibly can to understand what they say, do, think, and feel. This also helps you learn who you are solving for and who you are not solving for and create a problem statement 2. Validate * Building Conviction by testing Discovery, MVP, market analysis, possible conversion. During this time also you should be talking to customers to validate the problem and solution 3. Create: * Create the right team to build the product and also a plan on how you will bring the product to market.
...Read More1770 Views
Mani Fazeli
Shopify Director of Product • December 15
Let's cover this in two ways: (1) how to think about KPIs, (2) examples of poor ones and how they can be better. I'll also approach the question a little more broadly than Product Managers alone. Remember that Key Performance Indicators (KPIs) are used at all levels of a company (e.g. project, team, group, division, exec team) with different levels of fidelity and lag (e.g. daily active user vs. quarterly revenue). The appropriateness of standard KPIs will also differ by industry (e.g. commerce software will not rely on daily active users the way social networks do). Finally, many people use the term KPI when they actually just mean metrics (whether input, output, health, or otherwise). As the name suggests, only the metrics that are key to success should be elevated to KPIs, and there should be as few of them as possible. When I see more than 1 from a team, 3 from a group, or 5 from a division/exec team, there are good odds that some can be cut, amalgamated, or otherwise improved. KPIs are, after all, meant to drive decision making and accountability. So what are the criteria of KPIs that stand to be improved, and examples of them? 1. Vanity metrics: these look impressive but doesn't actually measure the success of a product. Examples include the amount of traffic to a website, the number of sign-ups a product has, daily active users for marketplaces that monetize through purchases, or the number of likes across posts on a social network. 2. Poorly instrumented metrics: these are not reliably measured, which can lead to incorrect or misleading conclusions about the effectiveness of a product. For example, if the first step of a conversion funnel (e.g. checkout) has many ingress pathways, and the user can transition in and out of that step before proceeding down funnel, how well your instrumentation deduplicates that first step is critical to your conversion calculations. 3. Lack of attribution to effort: any metric who's fluctuations cannot be explained by the combination of efforts from the team/group using it as a KPI, plus seasonal and random variability, is going to be ineffective. For example, if a common funnel in the company has multiple teams trying to improve its conversion, each team needs to define a KPI that does not overlap the others or they won't know if their efforts resulted in an outcome versus another team's efforts. Note that if all those teams are in the same group (e.g. a growth org), then that group could effectively use the conversion rate as their KPI. When in doubt, or if you're unable to isolate your efforts with lower level metrics, run an A/B test against every major change by each team to get a better (but imperfect) indication of relative contribution. This criteria covers many grey areas as well. Revenue is a prototypically difficult KPI for individual teams to use because of attribution. However, you can find relatively small teams or groups that build add-on products that are directly monetized and expansion revenue can be an excellent KPI for them (e.g. a payroll add-on to an accounting system). 4. Unclear tie to next level's KPI: companies are concentric circles of strategy, with each division, group, and team needing to fit its plans and focus into that of the prior. This includes KPIs, where you'd expect a well modeled connection between lower level KPIs driving higher level ones. For example, say a SaaS invoicing platforms sets an X in Y goal as an activiation hurdle to predict long term retained users (i.e. 2 invoices sent in first 30 days). It would be reasonable to assume that onboarding will heavily influence this. But what about onboarding, specifically, will matter? If a team concots a metric around how many settings are altered in the first 7 days (e.g. chose a template, added a logo, set automatic payment reminders) and wants to use that as their KPI, they'd need to have analyzed and modeled whether that matters at all to new users sending their first 2 invoices. 5. Lagging metrics at low levels: the closer you get down to a team level, the more you want to see KPIs defined by metrics that are leading indicators of success and can be measured without long time delays. Bad KPIs are ones that just can't be measured fast enough for a team to learn and take action. For example, many teams will work to increase retention in a company. But larger customers in SaaS may be on annual contracts. If features are being built to influence retention, it's better to find leading activity and usage metrics at the team level to drive behaviour and measure them weekly or monthly. These can tie into a higher level retention KPI for a group or division, and keep teams from getting nasty delayed surprises if their efforts weren't destined to be fruitful. The only caveat for this criteria is how platform and infrastructure teams measure themselves. Their KPIs are typically more lagging and this topic is deserving of its own write-up. 6. Compound or aggregate metrics: these are made up of multiple individual metrics that are combined using a formula in order to provide a more comprehensive view of the success of a product without needing to analyze many individual numbers. Examples include effectiveness scores, likelihood indicators, and satisfaction measures. Arguably, many high level KPIs behave this way, such as revenue and active users, which is why (3) above is important to keep in mind. However, its formulas that are particularly worrisome. They inject bias through how they're defined, which is hard for stakeholders to remember over time. You find yourself looking at a score that's gone down 5% QoQ and asking a series of questions to understand why. Then you realize it would have been simpler to look at individual metrics to begin with. In my experience, these KPIs lead to more harm than good. 7. Lacking health metrics or tripwires: having a KPI is important, but having it in isolation is dangerous. It's rare for lower level metrics to be improved without the possibility of doing harm elsewhere. For example, in commerce, we can make UX changes that increase the likelihood of conversion but decrease average order value or propensity for repeat purchases. Therefore, a KPI that does not consider tripwires or does not get paired with health metrics is waving a caution flag.
...Read More6720 Views
Aleks Bass
Typeform Chief Product Officer • September 8
Our product development lifecycle process looks very similar to a double diamond design process but with an adapted approach for our organization. While there are best practices for a product development processes, I've found that there is a decent amount of adaptation and adjustment that needs to happen to customize an approach for the needs of the organization. I've not seen 2 product lifecycles that are the same. At a minimum, a product development process should help reduce friction for the R&D teams, create clarity around what we need to know before we invest, and insight into the variables that influence those decisions. The most mature and refined PDLC programs also create consistant expectations of each role that participated in the product development process, sets criteria for high quality output, and provides clarity on what to do next through each stage. This is extremely benefitial when you think about onboarding new PMs to the team, as well as supporting the growth of PMs new to the role. Depending on the needs and maturity of your organization, you can chooste to implement a light version of this process that focuses solely on alignment and rescource allocation, or lean more into a more detailed process that provides more clarity on activities you expect the teams to execture for each stage. A good process provides time and space for the team to engage in activities focused on discovery, exploration, and time in a particular problem space. In this stage. you should avoid solutioning at all costs. There should be a stage for concept exploration, and I strongly encourage my teams to explore more than 1 concept. Sometimes the first concept we surface is not the best for the job, but inertia and time constraints prevent us from exploring more. I recommend my teams take the time, because it saves us on the rework later. Once a concept has been validated, there should be a stage that allows you to define the high level requirements and start thinking about an experience that would make it as easy as possible for customers to realize value from your chosen solution for the problem space. For me, customer validation of the specific execution is critical, because we are very rescource constraigned on the engineering side. If I can prevent rolling out soemthing that needs major rework, I will. Some organizations are more constraigned on the research or PM side in which case you may use the experience itself for validation. There are many types of product development lifecycles, and you should choose an execution that solves the most prevalent R&D problems your organization is facing.
...Read More3294 Views
Ajay Waghray
Udemy Director of Product Management, Consumer Marketplace • August 26
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 More5537 Views
Zeeshan Qamruddin
Cloudflare Sr. Director of Product | Formerly Segment, WeWork, Airbnb • April 13
At the company level, there are a few different methods of communications to keep everyone abreast of updates: 1. Product Notification emails (Ad Hoc) - These emails have a set template and allow product teams from around the company to share updates to their areas in a digestable format as major features go out of the door. 2. Product Newsletter emails (Weekly) - The weekly newsletter summarized major product updates and initiatives to all product team members. 3. Quartery Business Review meetings (Quarterly) - These larger meetings gather key parts of the business to talk through major updates each quarter, including an opportunity for the C-Suite to interact with and pose questions to respective teams. 4. Quarterly Kick-off meetings (Quarterly) - These meetings are specific to our Product Area and include our stakeholders; each team in Fintech is able to share wins from the prior quarter and plans for the coming quarter. 5. Slack Updates (Ad Hoc) - For major releases, the PM will often post a message in our global product channels to notify the broader group of the change. This allows an opportunity for the team to be recognized, as well as others to be informed about the update.
...Read More2380 Views
1. Not validating the problem statement enough. Is this really a problem? 2. For a B2B product, I think its important to think through early on whether this is a problem they are willing to pay for. Often times, this is an after thought and expensive to pivot. 3. Giving up too soon. Its easier said than done to validate the problem statement. Sometimes this take iterations where you get live feedback from real users. So you might be dancing around the problem space for a bit and that's okay.
...Read More4330 Views
Katherine Man
HubSpot Group Product Manager, CRM Platform • May 4
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.
...Read More2149 Views
Kie Watanabe
HubSpot Group Product Manager • October 14
In my previous answer, re: finding the right opportunities + making decisions - I mentioned four lenses (Customer, Business, Market, and Technology) as key components of coming up with ideas and making decisions. The best advice I have to offer is to be intentional about spending time developing your muscles in those areas. It can be as simple as picking a product or service in your day-to-day life and thinking through what inputs might have contributed to the experience you’re having as a user. Additionally, a lot of product strategy is about being able to identify the opportunity that will maximize impact. How will you hone in on the right problem and arrive at an excellent solution? I’ve found that strong problem-solving intrinsics and the ability to make effective decisions are very valuable. Here are two frameworks I’ve always found helpful: * McKinsey’s Seven Steps of Problem Solving - Helps abstract underlying problems/issues * Playing to Win - Strategy book by the former Procter & Gamble CEO A.G. Lafley Lastly, communication is essential for being able to get buy-in and execute product strategy. Work on simple, effective communication.
...Read More7673 Views