Get answers from product management leaders
Kie Watanabe
HubSpot Group Product Manager • October 14
This is a two-part question. Let me first articulate how I like coming up with ideas for new opportunities, followed by how I like to make decisions about what to build. Hopefully, you don’t mind that I’m thinking about “opportunities” because it might not always be a feature that’s the right solution. I should start by saying that there isn’t one right approach to coming up with ideas. In my experience, I’ve had success ensuring that there are: 1. Insights from the four lenses: Customer, Business, Market, Technology 2. Effective methods to facilitate ideation At the core, you have to have a deep understanding of the underlying user pain point you’re trying to solve through a thorough investigation of the Customer by talking to customers and product usage. You might actually learn very quickly that the user problem is around discoverability or activation, not necessarily a feature gap. Ideally, the customer impact is so deep that it translates effectively into Business impact. The Market context is critical to help understand how your user will experience the product within the broader competitive landscape and the direction an industry is headed. Finally, the Technology lens offers insight into what capabilities could be used as part of a solution. Preferably, these four lenses come together through cross-functional ideation that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market teams). In a hybrid world where we’re working across time zones, I’ve enjoyed having the opportunity to ideate together synchronously and asynchronously. In terms of decision-making, the ideation process should lend itself to initial layers of prioritization. I won’t go into prioritization frameworks here, but there are many out there. They do tend to distill back to impact and effort and sequencing. At HubSpot, depending on the type of decision we are trying to make, we may use a “driver, approver, contributor, informed” DACI model used by other companies we admire like Atlassian.
...Read More18781 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 More13632 Views
Deepti Srivastava
Head of Product, VP • December 14
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.
...Read More3242 Views
Clare Hawthorne
Oscar Health Senior Director, Product Operations • March 23
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.
...Read More6398 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 More9792 Views
Navin Ganeshan
Amazon Head of Driver Products, Amazon Relay • May 31
First of all, we need to address Amazon's terminology for these roles. A technical product manager at Amazon is generally referred to as a Product-Manager-Technical (PM-T). Whereas a Technical Program Manager (TPM) is a distinct role that sits at the intersection of product, engineering and program management. An Amazon TPM is a unique role that combines business ownership over delivery with high-level technical architecture. They are usually the program glue - that brings together PMTs, engineering teams and business stakeholders on all aspects of an initiative. However, note that this AMA is focused on the technical product-manager role or PM-T. So please make that translation whenever you see "TPM" in these questions.
...Read More7288 Views
Ravneet Uberoi
Uber B2B Products | Formerly Matterport, Box, McKinsey • August 31
Before investing in engineering resources you want to build conviction around the following: 1. Is there a market need? Are you fulfilling a true gap in the market? 2. Do you have a differentiated vision to deliver on this need? 3. Is there willingness to pay? 4. Does the business model make sense such that you see a path to ROI for the business? 5. Is there a clear route to market (you know how to sell / acquire customers)? 6. Does your business have (or plan to have) the capabilities to deliver on this product (ex operational, technical or other expertise) such that it is strategic to expand in this direction? Overall you want to be able to articulate what the investment unlocks for the company and how.
...Read More12577 Views
Katherine Man
HubSpot Group Product Manager, CRM Platform • May 4
I’ve held roles as both platform and non-platform product managers and I’d say being a platform product manager is definitely the most challenging but rewarding. The most challenging part is your solutions are more abstract and less obvious. Instead of building solutions directly for customers, you’re buildings tools for customers to build the solutions themselves. Does your head hurt yet? Let me give an example. Let’s say you’re trying to let customers customize the way their HubSpot UI looks. While you could try to build all the customization requests you get, no two customers want the same thing and it’d be impossible for our product teams to keep up with that demand. Instead, you build tools for external developers and admin users to configure the UI in the way they need. But how do you figure out which tools? Here is the usual process for regular product management: 1. Collect customer use cases 2. Identify a pattern 3. Build a solution that solves for the majority of use cases. Here is the process for platform product management with an extra step: 1. Collect customer use cases 2. Identify a pattern 3. Identify a pattern across solutions 4. Build a solution that solves for the majority of use cases. Still confused? Let me make the customization example even more specific. Let’s say you notice that a lot of customers want to display their HubSpot data in a table format on the CRM record page. Taking a non-platform approach, you’d build out every single table request that customers make. But this isn’t scalable. Instead, you build a configurable table component that customers can populate with their own data and then display. Believe me, I struggled for a long time with this adjustment in thinking but I promise if you choose to pursue it, you’ll love the wider impact that you’re able to have on customers!
...Read More5190 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 More6620 Views
Neel Joshi
Google Group Product Manager, Google Assistant • September 1
Without going into specifics, the biggest challenge has been cross-organization influencing. My time at both Microsoft and Google has exposed me to lots of intra-organization projects with varying levels of buy-in from each team. The level of effort and coordination required to pull not one, but two organizations in the same direction can be enormous. As a PM - at any level - it's your role to effectively communicate why what you're trying to acheive makes sense for other teams, your company and ultimately your customers. Even if you're aligned on principles and strategies, there are dozens of other factors that you need to be able to navigate such as resourcing, ownership, tech stacks, recognition, branding, leadership opinions and timelines.
...Read More11545 Views