S1 Ep. 11: How Does Your Team's Experience Impact You as a Product Leader?

HOW DOES YOUR TEAM'S EXPERIENCE IMPACT YOU AS A PRODUCT LEADER? Given the emerging discipline of product management, it's more common than not to have inexperienced product teams. As a product leader, how do you practically deal with that experience gap challenge?

 Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS

Hope Gurion: Many product leaders struggle with hiring for product team-related roles. Getting the team right is paramount! Why? It takes a strong team of collaborators and problem-solvers to achieve their company’s ambitious goals and do right by customers. However, given the emerging discipline of product management, it’s more common than not, to have inexperienced product teams. As a product leader, how do you practically deal with that experience gap challenge? When the team isn’t right, it falls back on the leader to coach, course-correct or fill in gaps, and there are already a lot of demands on the Product Leader’s time. That’s why we’re tackling the question HOW DOES YOUR TEAM’S EXPERIENCE IMPACT YOU AS A PRODUCT LEADER, in this episode of Fearless Product Leadership.

Welcome to the Fearless Product Leadership podcast. This is the show for new product leaders seeking to increase their confidence and competence. In every episode, I ask experienced and thoughtful product leaders to share their strategies and tactics that have helped them tackle a tough responsibility of the product leader role. I love helping emerging product leaders shorten their learning curves to expedite their professional success with great products, teams and stakeholder relationships. I’m your host and CEO of Fearless Product, Hope Gurion.

 

Many of the product leaders I work with have ambitious company goals and yet an inexperienced team. So, they ask me how to accelerate best practices within their teams and seek my advice on how to balance hiring and mentoring their inexperienced team with their other duties as a product leader. I empathize with this challenge as I faced in two different contexts as a product leader.

Once, I had to build, train and grow a team of product managers from various disciplines including finance, marketing, engineering, and support because the CEO I worked for insisted that we create career growth opportunities for already proven employees who knew our customers and business well.

Second was at a company when I inherited a team of project managers in an organization trying to transform from project-to-product methodologies.  So again, I had to assess the skills and experience capabilities on my team and make a plan to upskill or replace.

 

In this episode we’re going to hear how 5 experienced product leaders deal with varying experience levels in the product team.  I’ll share my own perspective as we dive even deeper into this extremely common product leader challenge.  In this episode you’ll learn:

  • Specific strategies that help Product leaders manage their bandwidth to while ramping up inexperienced PMs

  • How even deep experience can lead to coaching challenges for product leaders

  • Why taking a portfolio-management view of your people is as valuable as it is for your products

 

Fearlessly tackling the question “How does your team's experience level impact you as a product leader?” are:

  • Albert Lee, Co-founder and former Head of Product at MyFitnessPal

  • Preston Smalley, VP of Product Management, Comcast

  • Amanda Richardson, current Entrepreneur in Residence, former VP of Product at HotelTonight, Prezi and Snag

  • Troy Anderson, SVP of Product & Technology at SPINS

  • Laura Marino, SVP of Product at Lever

     

First Albert Lee of “MyFitnessPal” shares how the level of experience of your team is directly correlated to their ability to have autonomy over their decisions.

 

Albert Lee: Well, honestly I think there are a  variety of different ways that the relative experience level of the  people on your team affects you, and how  you build your team, how you think about  your team, how you assign people to  different projects. I think there are a lot of different ways to think about experience; certainly one is literally, “How long have you been doing this? How many projects have you been working on? What are the types of projects that you're working on? What are the types of things that you have built? And even beyond that, what are the types of skills that you've developed as a PM.

I think what  I used to think about a lot, in terms of  the product managers within my  organization is, you kind of  want to have this big bag of tricks that  you can bring to bear against any  problem that's like, “What are my  analytical skills? What are my product instincts? How do I understand product design and good user experience? How do I think about business metrics and motivating people? So there are all these different aspects of what makes you a good product manager. So that's even, I think, certain element of like experience level; how many of those things do I feel like you have some level of mastery over.

So I think it affected me in a couple ways. One thing I think that's really important is, when you think about decision making and experience, I think it's important to have some kind of a  rubric that you can put in place with  the individuals in the organization to  give them the appropriate amount of  autonomy, based on what their experience is. So I think you're striving to literally get to this point where everyone is doing all the work, and I'm just sitting on the beach and enjoying myself. So if the person has less experience, what that might mean is if they think about on these accesses, like “What is the level of impact to the business of this decision? What is the level of certainty that I have over the decision that I want to make”, you help people understand if the business is high and you have relatively little certainty, that's certainly something that I think you need to discuss, but in a different case it might be that the business impact is medium or low, and my certainty is relatively high, then I want to give you the autonomy to do that. So I think when you think about experience level, it's important to think about your team and have it clear to that individual where they sit on that spectrum, so that you can work with them in a very fluid and autonomous manner. It also affects how you think about resourcing your projects. Certainly, I think people with more experience, generally speaking, can deal with more complex and broader scope projects. Typically I think in some ways it's not, because there's some technical complexity, but really the complexity of the organization involved typically increases, because you just have more people, there might be more senior people involved. I think that’s where it becomes a challenge for people with less experience. It's like the herding of experts and doing that in an appropriate way, and doing that in a way where people are excited about how you're leading it. I think that's the stuff that takes a little bit of time to master.

So really thinking smartly about how I allocate people across these more complex and higher scope projects. I think an interesting thing along those lines that seems counterintuitive is, if you have a team that has all very highly experienced people which you tend  to run into, it is a problem where there actually aren't enough complex  and deep projects to work on.  I had that happen to me numerous times over the years and so it's not the worst problem in the world, but I think what it means is as a product leader how you think about your team. 

Product management isn’t just about accomplishing projects and necessarily just executing and building, it's about developing this PM toolkit. So being able to have other things that you can assign to those individuals that are helping them think about learning and growth, that may or may not be actually like driving something across the finish line and shipping it, I think it is pretty important.

So as a product leader, you want to have that stuff your little bag that you can pull out when you need that, if that circumstance arises.

  

Hope Gurion: I love that Albert brings up how all is not smooth sailing with a team of experienced PMs.  You as their leader need to be creative as you give special consideration for experienced PMs who still crave growth in their career and professional development.

Next, Preston Smalley of Comcast highlights that deep domain or functional expertise isn’t always an asset, and how he deals with that as product leader with his teams.

 

Preston Smalley: So, when you're thinking about the experience level of a product manager that you're looking to hire, I think you have to think about the different aspects of what experience really means.  No two product managers are really the same, everybody is coming from a different background. Typically, those backgrounds include things like; engineering, design, more of a marketing background. So, depending on which background they come from, they are going to have different blind spots. So, I think it's important to recognize what strengths they have coming from that background. The one from the engineering background may have less aptitude for understanding the customer. For the designer made product manager, he may not appreciate some of the technical challenges that the team is going to face in building products. Then sometimes people keep playing their old job too, so maybe they came from that role but then they’re not going to trust the person playing that role on the team. So I think  where somebody came from is so important  to recognize as a manager, to watch for  those possible side steps and be able to  either shore it up because you know that it's there, or potentially take a  different product manager based on the  type of product manager you need for  that product right now. So I think whether you're placing someone for hiring decision really recognizing the background is going to affect how they show up for the job.

So it's important to understand that the other, separate from your background, is thinking about experience level, regardless of how somebody became a product manager. It could be expressed in years but it's really about the types of experiences that they've had in that role, that they're going to be adept to handling certain situations. So how adept are they at handling situations where a project is off schedule, or dealing with third parties that they maybe letting them down, or how do they deal with executives that maybe change their mind as to what we're trying to build and how they guide them back towards that?

So all the types of problems that we know and we face, it's important to recognize which of those in your product manager are they equipped and ready to handle, because what you want to try and avoid is taking somebody that's a good project manager and just throwing them in the deep end of the pool without really them understanding how to handle those situations. So they can take on bigger and better challenges but then you've got to shore that up with the right coaching, the right on-background and mentoring, so that they're equipped  to handle those problems. So generally they may be on their own, but if you recognize that may be how they deal with stakeholders needs some work, then that's an area where you're going to want to spend more time with them and shoring that up, so that they've got the right approaches and the right tools that equip them to handle those types of situations. I think that knowing where  they’re strong and where they're weak will help you know where you need to  step in and where you need to  provide that assistance, because you want  them to be successful, it's going to  shine back on you and then ultimately  that's going to be why how the product  is successful. So that's what I think about when I try and hire.

I think the last thing is, as far as domain expertise, it is an interesting one.  Myself coming from consumer ecommerce into TV entertainment, at first glance would be like “Well how did you make that transition? Wouldn't have been better if they hired somebody with TV experience? What I found is that sometimes coming into a new domain can be a huge asset, because what it allows you to do is take a fresh set of eyes on a space that maybe was set in a certain way. So, it allows you to challenge certain assumptions and maybe bring a different point-of-view to the table. So having  a diverse set of opinions on the product  team could be super relevant, that's not  to say you don't need to learn the  domain and that those aren't blind spots,  because they are and I think I  had to understand those very quickly myself. I know when we make hiring decisions I’m just as likely, in the TV entertainment space, to hire somebody from a consumer-tech company as I am to hire somebody  from a traditional competitor.

 

Hope Gurion: Next, Amanda Richardson shares why having an experienced team of PMs are required when you’re tackling big problems and partnering them with experienced partners in engineering.  She shares how she uses a portfolio strategy to balance varying experience levels within the greater product team.

 

Amanda Richardson: So the experience level of the product team and the product managers on the team will drive both how I execute and what I execute. I would say there's no perfect mix.

If you have a fairly junior product team, your advantages are probably that you can get people onboard a lot faster, you can push through your agenda a lot faster. You  probably have downsides around making  sure you've got the right data, the right  analysis done, you've got challenges  maybe in managing dev and  predictability, but at least sometimes  execution can go better and faster.

I think having a lot of senior people helps you because you can just think much more strategically and set out very amorphous and loosey-goosey definitions. They're able to take like a hairy ball of a problem and figure out what that actually gets delivered. The challenge is that senior people want to lead, they want to influence the strategy, and they want to be involved in a lot of decision-making, in those big decisions, in those big meetings.     

So, it’s this balance of, how can you include them and get them the context they need, but also get stuff done. So, I've always found it's best to have a combination, depending on how directive the solution is versus how much of an exploration process it is, and I think that's true for design and product. Then you have to have different ways you work with engineering on each of those when you bring the engineers along, because the other big constraint is the talent on your engineering team and how they want to work. You can't put a junior PM in with a bunch of senior engineers because that PM will get eaten alive. Conversely, you can't have a super senior PM thrown in a bunch of junior devs, because they’re going to be like “Do I have to do both these jobs?” So, there's so much handling that gets done both ways.

So, I think it's really a partnership; it’s a portfolio across product but also partnership with the CTO on what kind of skills and problems they are going to tackle over the next six or twelve months, and then planning your headcount accordingly.

 

Hope Gurion: Laura Marino of Lever shares her approach of pairing people with deep expertise with those who are inexperienced to accelerate their learning and support their growth but protect her bandwidth.

 

Laura Marino: So how does the experience level of the PMs impact me? I actually like balanced teams. When I think of balanced teams, they’re a combination of people who have more experience and a combination of people who are maybe more junior but are very eager to learn.

Experience comes in different forms. You may need experience in product management, so you want to have people who have done product management before, who run engineering teams, who know how to help with engineering estimates, all of those pieces. But you may also want to have people who have experience with the product itself or with the industry. In many ways, the ideal is to have a team that has a combination of all of those.  

So typically what I have found is that  the best teams for me have been teams  where I've been able to bring in people who are pretty junior from the product management perspective, but have worked  in the company, whether it's customer  success or tech support. So, they come into the team with a lot of knowledge about the product and a lot of knowledge about the customers because they have been serving those customers. So, I can help them get ramped up on the product management side of things.

Then I will bring people who have done product management before, who may not be familiar with the product or not even with the industry, but they can ramp up on the product pretty quickly, and then they can help really coach those that are new to product management.

Once in a while I brought in people who might not have been familiar with the products or with product management but know a lot about the industry. In one of the companies that I ran, when I came in, I had four people in my team, and I drew the team to 21 people. So, I had different roles; I had somebody who was helping more with product strategy and she was really an industry expert more than a product management expert, but she contributed a lot to the team.

I think that the situation where it's a bit harder is if everybody in the team is junior, because even though I love mentoring part of what I do, I need to be performing at the executive level. If all my time is teaching people the basics of product management, it's really going to absorb all of my time. So in those cases, when I come  in and I have a team that's very junior, the first thing I do is spend some time  really assessing where the team is and  based on that I say this is what I need  now. For example I brought a  director of product management, specifically looking for someone who had  had experience with multiple companies, who had seen different teams, who had  also worked with different engineering  teams because sometimes when you have  your product team being junior, it's also  likely that your engineering team be  junior. There's a lot that product can do to help bring engineering to the next level, but you need experienced people to help with that.

So again, I think that what you want is this balance.  The reality is that if you are in a growing startup, it's really really hard for you to bring in someone who has no experience in product management, has no experience in the industry, and has no experience with the product; it's just too much ramp up.  

So, I get a lot of people who are interested in product management when I teach at Stanford, they’re like “How do I break into product management?” It is hard and I would say some of the big companies have internship programs where they   get exposed to things. But in my experience, I have balanced it in a way that if I bring someone who's really new to product, at least it is somebody who’s familiar with the industry.

 

Hope Gurion: Yeah, that makes a lot of sense. I think it’s just like the speed at which you have to be contributing value as a product manager. It doesn't often allow for people to learn on the job without one of those skill sets that you just mentioned.

Laura Marino: The other piece that’s very important is design. I am so fortunate that here in Lever I have a full design team, this is not something that had happened to me any of my previous B2B companies. The reality is that Lever had design team from the very beginning. My CEO was a designer, so she started really with the concept that the product had to be beautifully designed, for me it’s like “Oh my god, this is so wonderful”.  But in other organizations what I had to do was to actually come in and start fighting for getting designers. In B2C, it's taken for granted that you need a lot of design, but in B2b it is equally or even more important because typically B2B products are more complex. So, if you do not have the right design, the product would not be intuitive.

But for historical reasons, if you look at some of the old enterprise software, the idea of the UX doesn't matter, it's the functionality that the buyer cares about. So, for me it's always been very important to also make sure that if I start building up the team, I start bringing UX UI experience. It is a luxury to have a large team and it really makes a huge difference.

  

Hope Gurion: Finally, Troy Anderson of SPINS agrees with Laura’s strategy for pairing inexperienced PMs with experienced members of the team for mentorship.  He also shares what he looks for when considering inexperienced candidates for product team roles.

 

Troy Anderson: So in choosing between inexperienced people with a lot of potential or experienced people who’ve been doing their job for a long time, you want to mix, because I found that the best thing you can hire for is what they call them sports athletes. So, there's position people, like running backs, and wide receivers, and linebackers, but you want to hire athletes because athletes can do just about anything and they can learn. If you have a lot of experienced people and you have a lot of athletes, you tend to do a lot better job because athletes will learn on the job.  

So, hiring the most competent person that may not have the experience, but is like an athlete who is smart and energetic and curious and wants to work hard to succeed, those people are valuable, but they need the experienced people. So, you only have a good balance between those. Now if you can train them yourself that's great but most of us don't scale, so you are going to have to have some experienced people to train these people. If you find the right experienced people that are willing to mentor, and you get a bunch of inexperienced athletes, you're in a very happy shape.

 

Hope Gurion: As product leaders, our job is challenging, but when you don’t have experienced members of your team to rely on, it becomes not only challenging but time-consuming.  You don’t want to micromanage your team or have them feeling that you don’t trust their judgment, so here are three steps you can take:

  1. WHAT & WHY: Be clear and direct with the person who has experience gaps that concern you and why that makes you and them vulnerable to successfully achieving agreed upon goals

  2. WHEN: Discussing these in 1:1s instead of performance reviews.  This gives you both a safe space to problem solve to remedy these gaps together.

  3. HOW: Proactively have a plan to acknowledge and address those experience gaps.  Here are a few ideas to consider:

  • you have more reviews of their work-in-progress/decision-process

  • finding them internal/external subject-matter experts to shorten their learning curves

  • partnering them with more experienced people in their roles who are looking to take on people management responsibilities

There usually isn’t patience for trial and error due to the high opportunity cost of wrong decisions made and confidence lost in the people on your team. However, if everyone can speak openly about their blind spots, and your team knows that their success is your success, you can have an open dialogue about what combination of experience and process yields independent decision-making.

 

 

Previous
Previous

S1 Ep. 12: How Do You Craft and Communicate Product Vision?

Next
Next

S1 Ep. 10: How Do You Create Accountability for Product Teams?