AMA: Zendesk Director of Product Management, JJ Miclat on Product Management Career Path

Different types of PMs - Core Product Managers, Platform Product Managers, Infra/Internal Product Managers, Data Product Managers, Growth Product Managers, AI Product Managers Core Product Management * Building products, features, enhancements directly for the company’s external target consumer/business Platform Product Management * Building products, tooling, systems that are leveraged/shared by a handful of core product management teams to prevent service duplication - ie billing systems, authentication services, localization/globalization/accessibility tooling, design systems, graph services, etc.. Infra/Internal Product Management * Building products, tooling, frameworks, processes to accelerate the productivity of internal stakeholders in the company (developers, designers, GTM, marketing, analysts, etc..) Data Product Management * Like infra/internal product management but building warehouses, ETL, clean datasets, databases, query tooling, visualization software, to empower the productivity of data scientists, data analysts, ML engineers, etc.. Growth Product Management * Defining and executing on flywheels, acquisition levers, engagement/retention incentives, new feature introduction mechanisms, etc.. to ultimately acquire more customers, ensure they use the right products, and win them over as life-long champions of the product. AI Product Management * Leverage open source or commercial software, input customer/product data into it, tune/tailor it to your business, build an custom interface on top of it, to ultimately generate recommendations and/or outputs that empowers your customers to meet their goals * And/or build in-house, proprietary machine learning algorithms to accomplish the same as above Oftentimes, the titles above to match what the company decides to call you - which is just Product Manager :) Some PMs are also expected wear multiple hats here.

* the ability to ask questions and synthesize - customers often tell you what they want to see happen in the product, but that may not be the most scalable solution for all of your target customers in aggregate. In customers interviews, get to the root of the “why” behind feature requests - why are they asking for this? what problem is it looking to solve? how big of a problem is this? what workaround are they doing today to bypass this problem? how would solving this problem help your customers better reach their goals? how would solving this problem make your customers more productive overall? * the ability to prioritize and say no - “It's not prioritization until it hurts” - Ami Vora, CPO of Faire. Good PMs collect more customer problems than their engineering team is able to solve. Great PMs are able to diplomatically say no to the majority of the problems being asked for a solution. They also able to do this while keeping customers/stakeholders understanding why choosing to prioritize certain things over others. And it’s supposed to hurt a little bit. * curiosity and insatiable appetite to learn - it would definitely help if the PM innately had high raw intellectual horsepower, but that will get you nowhere if you’re not constantly willing to adjust, learn, and adapt - every customer, product, company, org, stakeholder, is different. There’s no shortage of techniques and tools to learn if you want drive your PM skills forward, from learning SQL, knowing how to run effective user research, get great at conducting competitive analyses, it’s etc..

Focus on how you drove engagement/retention for your B2B product, and how it ultimately lead to improving renewals and/or increasing upsells to higher tiers, if you made contributions there. Focus on how you drove self-serve checkout/trial experiences for your B2B product, if you made contributions there. Focus on how you solved the "cold-start problem" to an extent, for your B2B product, if you made contributions there. This applies to when a product's success is partially determined by the amount of users/traffic/volume/data that currently exists on the product.

* get some quick wins under your belt: * shepherd a small product/feature/enhancement that’s currently in development out to market launch * jump into user research calls to understand customer pain * jump into sales calls (prospects or existing customers) to understand pain * work with user research (or do it yourself) to understand and document the nature of different customer personas/segments, if this hasn’t been done already * write a PRD for small product/feature/enhancement, get feedback on it, and refine accordingly * learn * know the high-level product metrics that the team is currently tracking, and where they generally stand * immediately start using the product putting yourself in the shoes of a new user, and jot down anything that could be improved and what friction/problems/pain you’re facing * learn as much about the existing products in your ownership/purview/domain as quickly as you can * learn about other products at a cursory/introductory level so that you could see where your product fits in the grand scheme of things * build relationships * form and maintain strong relationships with other product development stakeholders all across the board, starting with your developers, designer, research, analyst, marketer, and manager

I have a Notion board with three swimlanes - to-do, doing, and done. I groom my to-do list about 3 times a day to ensure the highest prio stuff is next on the queue. I to try to carve out dedicated blocks for complex, mentally-intensive work. I try not to little tasks (stuff that takes less than 5 min to do) build-up and intersperse them throughout my day.

Coaching my PMs takes priority, people management is a force-multiplier if done correctly/effectively. I make individual contributions only if truly needed - a PM backfill hasn't been placed or a PM is struggling in a product that absolutely cannot fail. It was hard to to give up IC contributions initially as a people manager, but coaching your reports to be self-sufficient + autonomous + make quick/correct decisions, pays off dividends. If you miss IC work, go back to being an IC, the pay and glory is the generally same as management if you're really good at it.

* in product reviews, when an exec/lead asks you something about your product decision, don’t table it and say “idk, we’ll assess and circle back with you in xx days”, rather just say what you think ought/should happen. You could state that these are assumptions and you could/should validate later. But as a PM, you’re paid to have an opinion on the spot, and oftentimes we don’t have all the data/research at our fingertips. At least the exec could course correct you on the spot in case you need misdirection, so you don’t fall into a rabbit hole * in presos to execs, lead with the spicy thing first (the solution, the recommendation, etc..) and have the justification/rationale/analysis follow it. for non-exec presos, it’s generally recommended to reverse the order. This may be obvious, but I’ve seen it overlooked sometimes. * expose a healthy dose of skepticism, call out product/market risks/assumptions - but do it in the latter half of the preso, If you only present positive info, folks naturally get suspicious around what are you hiding (this was inspired by Mihika Kapoor's talk at Lenny's Summit earlier this year, but it's principles I've adhered to and shared with my PMs for the past couple years)

* File a request to get a PM intern (if there’s such a program at your company) for direct people management experience * Sign up through your company’s mentorship program (if there is one) to glean coaching/mentorship experience * Become another employee’s unofficial mentor (if you are doing great work, folks will notice, and will naturally ask you to help/guide them on things) * Influence other product development teams’ roadmaps (outside of the product development teams under your PM purview) * Ask to take on more product areas with deep complexity, nebulous problems, and wider scope * Take your time to research, craft, evangelise, and get buy-in for a multi-year roadmap (in larger companies) * What’s most important: launch impactful products. What you could do on top of that: establish yourself as a thought leader outside and inside the company * Demonstrate constantly showing emotional maturity / resilience when faced with extreme conflict

PMs are able to help engineers with: * talking to all different types of customers and prospects, so that we constantly have informed/holistic insights into most impactful problems we should be solving for our target customer * taking the set of problems we have to solve, strategically sequencing them (roadmap), and pitching this to leaders internally to ensure buy-in + resources to fund this work * take the lead on solutioning - working with engineering, product design, content design, user research, and data science - to ensure that we are building a feasible/impactful solution for the right problem * evangelising the products that we are building and collaborating with GTM stakeholders (Customer Success, Account Executives, Solutions Consultations), pricing teams, business development, legal, product marketing - so that the product is not only built, but well-loved and highly adopted by our customers * and so many more things Engineering leaders could drive all of that, and they are capable to. But oftentimes they are focused on managing large organizations of engineering staff and driving technical/architectural vision. And good PMs have years of experience and training on this work specifically, as opposed to having to focus on people management.

As a PM, you should know the architecture of your product's tech-stack, so that you could have meaningful conversations with your engineers about tradeoffs, capabilities, limitations, and estimates. You don't necessarily need to know how to code, unless your product is code (ie PM for Swift at Apple).