Product Management Subteams

This reminds me of an interview question I got a very long time ago: "Is it better to have a bad team or a bad manager". In both cases, you'd rather not find yourself in either extreme. In both cases, there is no right or wrong answer and a lot depends on additional circumstances and assumptions. The answer will also depend on your value system and the experiences which have shaped your core beliefs about human aptitude and potential.  For the sake of argument, if I had to pick, I would first apply the same framework: which suboptimal option is more mitigatable.  I believe that most people have the capacity to learn the facts of the domain, the technical aspects, I.e. the hard skills, with sufficient effort and time. On some level, I see acquiring the hard skills in this contrived case akin to suceeding in a college course you know nothing about but are highly motivated to ace. The soft skills can also be learned, but these are much more entangled with personality, self-awareness, communication style, etc., all of which develop and become ingrained over the years. They are harder to inculcate artificially or to undo as bad habits. Poor soft skills can burn bridges and set the course of nascent relationships on the wrong trajectory, impacting your ability drive results far into the future. No amount of hard skills may be able to offset that. Good soft skills can even buy you time to get up to speed on the hard skills, and can get you critical early support from the team to actively help you get there.  This is why if I had to, I would pick the soft skills option.

While infusing ML into a product can be extremely powerful to light-up new scenarios for customers and to optimize current scenarios, it can take a lot of effort to get it right. It all starts with defining and prioritizing the right scenario/problem to focus on, working with data science and ML engineering teams to map the business problem to an ML problem, trying out to different approaches to identify the right one to go ahead with, experimenting and optimizing and then operationalizing the approach and shipping it as part of product stack working with ML engineering and development teams. In addition to focusing on functional aspects and non-functional aspects like performance/scale/reliability, ML scenarios bring in an additional critical aspect of transparency and fairness which is broadly classified under Responsible AI - this is required to gain customer trust and hence feature adoption.  It is the responsibility of product manager to define the business scenarios and success metrics to focus on, work closely with data science teams to map that into ML problem and enable them with right data for them to come up with right approach. Then work with ML engineers and developers to operationalize it as part of the product. In summary, it take collaboration between multiple teams/roles in order to ship great ML features as part of a product. If you are interested in learning more, watch my session on AI/ML Product Management: https://www.linkedin.com/video/event/urn:li:ugcPost:6929801568753971200/

Implementing an ML feature vs a non ML feature is no different. The complexity is how the ML model is integrated into the existing product, business or user workflows, and how it might impact the overall end user experience. The goal is usually to simplify and not complicate things. The goal is to reduce buttons and not add buttons. The decision for ML features in a product is similar to the other features -- ML is just the technology about how - under the hood. It is not the end in itself.  As regards working with data scientists -- it depends on the feature. As PMs where there might be significant impact on end user experience, it is helpful that PMs keep in mind the ethics, diversity and inclusion issues to inform data scientists about what to include when capturing data for training and testing. It is important to have a good diverse test data set. 

My personal take is that when I am speaking with strong product candidates, I can see a few qualities shine through in their story. For me, those are:  1. They are constant Learners/curious They are constantly asking questions and actively listening. They are readers and constant consumers of information. To me, this shows that when they come on the team, they will bring fresh ideas forward. Ask the team questions that others may not consider and bring new information to the table.  2. They are persistent and don't stop at 'no' In this, they are contantly trying to understand constraints and find alternatives. They want to address a problem and flexibly driving towards a solution that will do it. They do not get discouraged when someone says no. Maybe they will flex their soft skills and coax a 'maybe' out of the person saying 'no'. 3. Understand how to balance the art and science Often times when we talk about product management, we talk about the science. Your frameworks, how you manage backlogs, understanding data and tracking metrics and all of those fun items. You'll find a lot of books on these topics because they are measurable and easier to write about. On the other hand, we often forget about the art. The way things get done. How you communicate, show empathy, tell a compelling story and inspire others. How you connect with your customers and their problems, lead individuals without authority. Normally when a PM fails, it's because not enough attention is paid to the art.  4. Focus on problems not solutions Often times when someone is describing a problem, you want to jump to a solution. Technically product management is helping to solve a customer problem... but to truly solve a problem, you must really fall in love with the problem.  5. Able to represent multiple POV They are able to advocate wearing different hats. So they can speak to engineer, executives, marketing, the customer, you name it. They can comfortably devils' advocate ideas and not settle for the first answer suggested. Often in the interview process, you are meeting with different stakeholders and really they are each approaching you with a different lens (or hat) to evaluate your ability to breakdown a problem.

For me the biggest differentiator is having a growth mindset. This doesn't just mean they want to make an impact and improve as a PM. For me it comes down to three things: 1. They have a sense of what they know and don't know, and are always eager to learn more. They question their own assumptions. 2. They're humble and curious in trying to figure out what they don't know and leverage the expertise of others. 3. They frequently seek feedback from others and try to challenge themselves, not just to achieve more but to be a better colleague and partner to others.

1. They teach you something in the interview I once interviewed a woman who had extensive experience working for a telecommunications company. I have zero experience in telco – aside from being a customer of Verizon Wireless. I walked out of that interview having learned so much about telco companies, their business model, what they optimize for, how they segment their customers, etc. In the stories the candidate told about her work experiences she concisely weaved in the basics of the telco in a digestible way and was very aware of the learnings and insights she had from her product launch successes and failures.  As a product manager you’re responsible for the “what” and the “why.” What should we build and why should we build it? If you’re able to succinctly describe the what and the why of your current or previous roles -- no mater the industry -- that’s a great indication of a strong PM. 2. They make it a two-way conversation. (See answer to “What are the most common mistakes you see candidates make” question above)

A few things: * A very deep understanding of the problems they are looking to solve. This gets reflected in how they speak about past experiences (why did you choose to work on a specific problem, what exactly was the need?) as well as any case study (are they asking intelligent questions to understand the need). * User-first approach: While solving the problem they identified, are they putting the user at the forefront? Are they clear about who the users are for the problem? * Clear communication * For more experienced positions and specific for B2B products, are they mature to understand roll-out considerations for a large group of stakeholders? What are the people and processes needed to make a roll-out successful?

I'll speak to commonalities in IC PMs since I have less experience hiring other product leaders. It's really just 4 things in my view: * A clear ability to break down complex, multi-faceted problems into digestible, actionable chunks, as usually shown via some kind of case interview. * Excellent ability to ask good, tough questions * A clear track record of having an impact and/or continuous learning/improvement. This may not necessarily be demonstrated through previous work as a PM, but the candidate is able to speak clearly to the impact they distinctly had or the specificity of the learnings they captured. * Genuine interest and energy around the problems discussed in the interview cycle. This may show up in a case interview (ie. clear enthusiasm about the challenge presented) or when asking questions about the role/company. I always like to see how a candidate reacts when I answer questions about the business/product, challenges we face, etc.

Best product management candidates craft compelling, concise and inspirational narratives when they interview. They demonstrate clarity of thinking, knowing both the facts and the "why" behind their answers, and genuine curiosity. I always walk out of an interview with a great product manager feeling like I have learned something valuable, and inspired. I spoke to the skills I've seen among successful product managers in another answer to the AMA, but if you are looking to impress hiring managers specifically, I recommend practicing storytelling and becoming a great conversationalist in addition to the core skills you need to the job. The good news is that your conversational and story telling skills get better the more you practice - and you are not limited to interviews only. Any sort of verbal presentation mastery - Toastmasters, Improv and comedy, acting classes etc. will help you become a master storyteller. 

The best Product managers combine curiosity with structured problem solving skills. Being curious helps them look at problems as opportunities to learn & grow. Ability to frame & structure a problem helps them take others along in the process. Both these skills can be learnt & cultivated over time. Curiosity - Being curious is an under-rated skill. PMs who are curious keep learning, adding new tools (ideas, PM techniques, s/w tools) to their expanding toolkit and more importantly keep expanding their perspective. Structured Problem Solving - Being able to frame a problem in a simple manner, helps all cross-functional stakeholders & partners align on the problem definition (yes, this is key), the solution and then the execution I try to imbue these two values on a daily basis and this has helped me seamlessly transition across AdTech, Consumer Tech, E-Commerce & Fintech. And, it's a lot of fun!

Ideally, you design experiments in a way that seek to answer a question regardless of the result. For example, "do users not adopt this feature because of discoverability or usability?" is a great question to be answered with an experiment. If the exeriment execution puts that feature front and center of the main page when a user logs in, and the experiment is flat, then you could be pretty sure it's a usability issue. If it's stat sig positive, then you can be sure it's a discoverability issue. What's important is what you do after you've identified this finding. This new information can inform your entire strategy of your team or you can pass it on to another team for them to work on. 

 If the experiment results were flat or if the new variation performed worse, I would suggest three steps in deciding how to pivot 1. Confirm it failed.  2. Dig into the data 3. Get user / qualitiative feedback Confirm it failed.  * Did you run the test for long enough to get statistical significance? (How long does an AB test calculator say you should run the test?) The most common issue with AB testing is people calling the test with not enough data.  * Does the experience or part of the site you were testing does it get enough traffic to be a good fit for AB testing?  * Review the user experience you just tested yourself. Were there any issues with it you can see if you look at it with fresh eyes?  Dig into the data * If the primary KPI you were testing is unclear/ low significance, is there a clue elsewhere in the data which might give you an idea why the new variation did poorly (worse results on mobile, better for returning users, or there were more form errors - are all examples of issues which might give you an idea on why the results were disappointing) * What additional data sources can you look at to understand how users were responding. For example, Amplitude, Hotjar, FullStory, Qualtrics, etc. Watching some user sessions of people interacting with the variation can be eye opening.  Get user / qualitiative feedback * Ask users. You can survey test participants and see how the responses different between variants, or if you have 'always-on' surveys on the site, you can divide responses based on which variation they saw.  * If the experiment is critical to decide an important investment, you can also do UserTesting.com style testing to understand how users were responding better. 

I personally believe this to be communication. Often times, we as PMs dive heads down into a problem with understanding that we need to have a time with us to do the work. It is important to develop a communication style that resonates meaningfully with your audience. As a PM, you will need to communicate with: 1. Stakeholders 2. Peers 3. Direct reports 4. External partners  Each of these groups will require their own set of nuance that you will need to determine based on the relationship you are working to develop OR need to maintain. Often times when you see friction in organization, it comes down to a miscommunication or lack of communication. It's better to set yourself up for success here. My recommendation: 1. List your who your audiences are 2. Capture their needs and the required cadence for communication. Understand the best mode to share communication, whether that is slack, in person or email.  3. Kick off your process 4. Important step... ask for feedback frequently. You don't want to wait until something breaks to know something is wrong. Ask people if they are getting what they need from you until you feel satisfied you are meeting the mark. 

I'd love to answer this in a slightly different way: The single most important skill, that cannot be rated highly enough is Communication. Many other soft skills are fundamentally still rooted in or are dependent on communication.  Nuanced aspects of communication also matter: * adapting communication to the audience and situation * timing the communication * communication in all forms: written, verbal, non-verbal/body language.

Sharp communication skills that enable proactive stakeholder management. This doesn't just mean blasting memos and updates to everyone, everywhere – it means:  * Speaking about what matters to who;  * Understanding what is the right timing; * And knowing which channels are most effective for getting your point across.  In some organizations, you may be lucky enough to have a Product Operations team to help you with that; in others, you won't. Leaning into comms and stakeholder management means:  * Risks are assessed early; * Issues requiring help are unblocked; * Expectations are adjusted at the right time;  * And – most importantly – that your teams (from executive leadership to direct reports to cross-functional collaborators) know they can trust you.

Empathy and the ability to connect with people across the board is the most under-rated skill for high-performing PMs. Empathy enables PMs to connect dots, build relationships, solve problems and dive-deep, to increase their expertise PMs need to exhibit people skills that span three broad categories and empathy for each of these different categories helps in its own way. 1. Managing XFN - PMs typically work with large cross-functional (XFN) teams and need to adapt their working styles for each of the XFN teams, their involvement in the product/ problem, the individual team members' seniority & their time at the company. Initiatives that are amongst the top priorities for the company might have a fully staffed XFN team and others would have varying degrees of staffing. Likewise, new initiatives, esp 0-1 initiatives would have gaps in resourcing and would sometimes be staffed with new hires or interns. The ability to connect with people will ensure the PM is able to partner with all XFN appropriately to get things done. For instance, at Flipkart & Rakuten, we were resource constrained and I hired interns for our Tiger (Innovation) teams. It was one of the most fun experiences I had since we could think big, not fear failure and also time-box our work (to match with internship cycles) to launch a prototype or pilot. Products such as Flipkart Merchant Ads, Flipkart Funnel Attribution & R-Pay Merchant Rewards developed from these pilots 2. Team leadership - PMs, esp later in their careers, would be managing teams of Product Managers, across their career spectrum. Every PM is different in their approach, some lean on context, others lean on passion, yet others on structured problem solving process and being able to identify what makes the team tick and make them the best version of themselves in key! My team had Rakuten had PMs that spanned multiple archetypes from the Captain (who likes to lead large initiatives themselves), the Generalist (who can shape-shift to any project), the Specialist (who likes to specialize in a domain), the Architect (Technical PMs who like to build) and the Integrator (PMs who are good at managing large, complex initiatives).  Meta has an equally impressive range of archetypes for PMs and more for TPMs & Project Managers. 3. Executive Presence -  The last & most critical category of people interactions for senior PMs is working with executives & Sr leadership in any firm. Here again, empathy for the leaders, for the scale & scope of problems they are solving, for what keeps them up at night, will go a long way in helping the company, the org & the product team. Sr PMs need to think of themselves as Chief Enabling Officers and the more they enable Executives, the more they enable their own teams

There are different paths that each product manager takes, but the common ones I've seen are: 1. Joining a tech company as an Associate PM or an intern straight from college. For college grads, I suggest starting by connecting with other product managers (e.g. via LinkedIn) to better understand what we do. There are great books available on this topic as well -- "Cracking PM Interview" is among my favorites. I also created a series of videos explaining tech jobs and what do I do in more detail - https://www.youtube.com/channel/UCsAz_arwNkiPobhi09VrMFg 2. Transition from other roles e.g. Engineering, Professional Services, Support. This path is easier, as it assumes that you are already in a tech company and can make connections with internal PMs. Picking a PM as a mentor or just becoming a friend with one is a great place to start. I also need to point out that PMs sit at the intersection of Business, Technology, and UX (Customer) -- that is why engineers who transition to a PM team will have an advantage as they understand the technology much deeper. On the other hand, someone in Support who wants to become a PM brings a much deeper understanding of a customer.

There is a fork in the PM career path road: one is becoming a people manager, the other becoming an expert in a deep thinking product area sans managing a team.  My recommendation is to figure out which one is right for you. Many folks want to jump into management simply because they think this is the only way to grow, make more $$$ and so on. That is not true. Big and small orgs I have been a part of value senior individual contributors that are passionate about their individual craft. Speak with folks from both paths, and see which one resonates more with you. Try mentoring people and see if you like helping others succeed through your guidance as a "management path" check.  Then, share your thinking with your manager to get them to help you moving along this path. 

This is a very interesting question and one that I keep touching upon on almost all career conversations with my teams & mentees. There is no one typical career path for PMs, which can be both liberating and challenging at the same time! It's liberating since PMs have the chance to shape their careers to what they would like it to be, playing to their strengths and having a fulfilling life & career. It's challenging since every industry and many firms in the same industry have different definitions & requirements for what a PM is! For instance, even within FAANG firms, the definition of a PM is different - Google requires PMs to market the work of their Engineers, Apple PMs are usually good at their domain of expertise but execute on Sr Management decisions, Amazon PMs are Business/ Program Managers with heightened focus on a few metrics, Netflix PMs are very Technical (most of their PMs were former Engineers or Architects) and Meta offers almost the full buffet but also the most agency & empowerment to PMs. I touched upon some of the PM archetypes in another answer and its great to see that PMs can succeed in any shape or form tht adds value to their firm! PMs who are early in their careers will do well to join established firms to understand the PM tracks and how senior PMs have shaped their careers. Working in a start-up or a 0-1 environment usually turbo-charges a PM's career but only if the PM is aware of their strengths & know-how to leverage them. I have found that alternating between large firms & startups or between established products/ projects and 0-1 initiatives is the best way one can gain the most perspective and shape their careers as PMs.

This is a tricky question. Lots of program managers struggle with prioritization and impact analysis. They also struggle to get alignment on the prioritization across among the stakeholders. Some of the best program managers are good at understanding customer cohorts, their behavior on the application, and what they like & dislike. Not understanding customer behavior leads to bad (or gut-based) product decisions. Almost always, it comes down to first principles. Good product managers invest time learning the customer.

Avoid artificial growth! A good growth PM or a good PM, in general, will only look for sustainable growth opportunities. There was this one time at Yahoo when a bad growth PM said to me, "let's grow video consumption by auto-playing every video on every page." This is a horrible idea because you will grow video consumption at the expense of user satisfaction, and time spent. Doing these types of trade-offs is NOT "growing," it's "trading". A good growth PM would say "hmm let's find real opportunities where videos are not present but should be." 

The number one thing first time growth PMs get wrong is only focusing on wins and not involving their team. When creating a Growth squad, your number one enemy isn't not making the number bigger, it's xfn attrition. Designers and engineers who are new to Growth have historically been rewarded for releasing new features. When joining a Growth team, you have to be able to prepare them to launch something and then delete it. This is very new behavior and goes against what they are used to doing.  So what do you do? You have to redefine how they value themselves. Essentially get them to unlearn what they've been used to for the last 10+ years. It's no simple task. But one of the greatest ways I've seen this get driven is by involving your xfn partners (who are interested) in the strategy of what your team will build. In that you are trying to move the number, but really, you're trying to answer questions that will inform the strategy. By involving your xfn partners there, they will feel rewarded when we answer a question and you help proliferate that insight across the company. You want your team to feel a sense of pride not just by moving the number, but by how you all affect the strategy as a whole. Even if that means you didn't make any permanent changes to the product.

The key mistake new PMs make is focusing on delivering over impact.  It is inevitable that PMs hit a point where the backlog runs dry. The instinct in this moment is to panic to get something ready for dev, push forward the first idea that jumps to mind. The problem is this reduces the level of rigor, making it likely the work will not have sufficient reach or impact to matter. It also increases execution risk, increasing the likelihood specs are incomplete and engineering has to work with partial requirements, like building without design, that result in rework. In the panic to get this new feature out the door, the PM likely won't have time to build a proper backlog and be in the same spot a sprint later. Instead, the PM needs to take the painful step of admitting fault and chart a sustainable path forward. They can follow my process in a different question for building a roadmap. Knowing that process will take time, the key is being clear with engineering and product leadership on the process and rough timeline, so that the team can be best utilized while the backlog is being built. This also creates an opportunity for individual engineers to see the backlog building process from scratch, giving them higher confidence and motivation when the work is dev ready. I should call out that it is not just new PMs who make this mistake. I've made it myself many times in my career, so I know it is much more easily said than done.

A traditional product manager is responsible for a specific set of features and functionalities in an application. They focus on building the functionality with great UX. A Growth Product manager looks more end-to-end and identifies opportunities to deliver incremental growth. Let's take an eCommerce website application. A feature product manager might be responsible for the checkout experience. They will be thinking more about building capabilities in checkout (like supporting new payment types). A growth product manager will take more of an end-to-end customer journey perspective and think about capabilities like driving more awareness for other related products in the checkout experience, increasing the average order value, increasing customer engagement and conversion on the checkout pages, etc. A growth product manager focuses less on building a specific component in an application rather more on the customer journey, conversions etc., across all application components. 

Great question.  1. One important piece of knowledge is that EVERY PM is responsible for having a growth mindset. Growth PMs are NOT the only PMs responsible for growth.  2. Growth PMs are defined differently from company to company, and some companies don't have titles called Growth PMs. The most common Growth PM team that I've seen is usually responsible for user acquisition. This means they own the product features that help users have a smooth onboarding experience.  3. Sometimes the responsibilities go deeper in the growth process where they are responsible for user acquisition, engagement, retention, and referrals. However, in most cases from my experience, every PM owns a certain piece of the entire product but their responsibility is to contribute to a certain segment of this growth process. For example, I ran a team at 23andme called the Engagement team, where we owned the homepage experience, and our goal was to get our users to engage with our product more often. The more they engaged, the more opportunity we had to upsell them. 

I've wrestled with this over the course of ten years now. I used to think Growth PMs and Core PMs should just be one in the same and every Core PM should be able to do Growth work. However, I don't really believe that anymore. From my experience, there's a place in the business to do optimizations (Growth) and a place to do exploration (Core) work.  Core PMs generally have a stronger skillset around taking big bets which require a lot of coordination and patience. Growth PMs require high analytical acumen and rapid development, but much smaller bets, and not as much coordination. 

The skill sets for growth and non-growth PMs are about 85% overlapped. The key differentiator is analytical sense. While all PMs need to ensure the team is focused on driving customer and business impact, growth PMs always have a direct tie to driving business KPIs. This requires a more advanced level of understanding trends in the data to identify areas of leverage.  On the flip side, it is important to know what a Growth PM doesn't need to be great at in a given role. For example, I hired a PM who led a mobile app working with a small, dedicated team. That means the bar for collaboration skills didn't need to be as high as other roles. Another time, I hired a PM who work on core site conversion with a clearly defined scope, so they didn’t need as much depth in product sense.

The roadmap process is no different from any other product manager. They work closely with marketing, engineering, design, and data science to create the roadmap. There are sprints & prioritization processes for all features. They are focused on continuous experimentation and learning - which is an input into the prioritization process. 

Focus Area > Problem > Hypothesis First, the focus area for the team must be defined. This starts by mapping out the possible areas the team could focus. My recommendation is to assess the opportunity size using the product of "What's the business value if [x] area was improved?" times "What's the likelihood of that happening?" Next, you want to align on what problem you are tackling. For example, when I first started at ezCater we decided to improve initial landing experiences for visitors. I leveraged the Google Ventures style Design Sprint. That meant working closely with stakeholders to map the customer journey, bringing in analytics and data insights, inventoring customer research, and auditing competitors. Consolidating that all in a Miro board, I could walk the working group through these materials over a multi-hour session and come together on facts and insights to identify the most fruitful opportunity areas. Last, you generate solutions. To avoid group think, have people generate solutions individually. From there, the PM can take lead organizing the ideas and ensuring they have crisp hypothesis that tie back to known insights and there’s a sizing of projected reach, impact and effort to inform relative prioritization. I think this process works best to do quarterly, providing enough fuel for the team to run for a period while giving a recurring blast of fresh context and ideas!

These 3 principles are presented in rank order, because each one only matters if the ones above it are following 1. Empowerment - Everyone on the team feels ownership, understanding the problem space and context to really make an impact. Without empowerment, the team will inevitably be risk-averse or overly deferential, which is the opposite of the motivated, go-getter attitude needed. This can occur either because the team is not staffed or scoped appropriately, limiting what bets they are able to take, or management is overbearing and doesn’t cultivate independent thinking. 2. Rigor - Bets are thoughtfully taken, informed by data and strategic thinking into crisp hypothesis. They develop end-to-end solutions, thinking through the entire relevant customer experience. For a new feature, this spans presenting information to customers contextually in a compelling framing, providing easy actions that minimize cognitive load, and keeping the customer on a journey that remains compelling and relevant throughout. A team can be as empowered as they want, but if they take bets that are too small, just strategically don’t make sense, or they aren't resourced to cover the full user journey, their impact will be limited. Practice is the best teacher, but process accountability can accelerate this by making sure all initiatives have basic sizing (reach, impact, and effort) and execution risks (dependencies, order of operations) are planned out before work begins. 3. Agility - The team is scrappy, making a surprising amount of progress in a short period of time. Speed to learning is of the essence. A team can be effective if they just have the top two principles, but they’ll move slowly without agility. Management can support this through pushing on speed without rushing. My favorite question is “How could you learn [x] even faster?”