Is The Product Manager Part Of The Team Or Outside The Team?

Hannah Chaplin, Leonard Kongshavn, Jason Knight, Fanny Krebs-Pinto at Is The Product Manager Part Of The Team Or Outside The Team? . Video: https://youtu.be/tq7Uo4hX0do

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How Google, Doctolib and DueDil organize product

[00:00:00] Host: Leonard, if you could start with Google.

[00:00:04] Leonard: Okay, yeah, sure. Let's talk about this, it's easy. We're about, I think, 140,000 people. I don't know actually how many we are, but there's hundreds and thousands of us. Within our product org we're organized like a traditional tech company, as in you have product being separate from engineering, and UX is a separate function with separate management chains that you operate in. The product manager is very clearly the person responsible for identifying what we are building, and for having a good rationale for why we're building that thing and not any of the other alternatives you have. There will always be a lot of alternatives.

[00:00:42] The product manager is not responsible for telling you which technologies to use, or how we solve this specific technical challenge, or what the UI is going to look like. There are a lot of things which are handled by specialists, very, very distinctly, and the product manager's role is aligning all of those activities around the vision you set. You're responsible for the vision. If people don't understand what they're building, or have any sort of misconceptions around what we are building towards, then that's on the product manager.

[00:01:12] That's traditional product management, I would say, if you look at it from a textbook perspective. Now, to be fair, I only see it from my perspective. Google is a large company and I can only talk about what I see, and obviously I have my own opinions on what would be the ideal structure. I think we're doing what we can with the scale we have. I think smaller companies will have a very different thing. I don't know who's going to take it on, Fanny, Jason?

[00:01:37] Fanny: Yeah, sure, thanks. In my company, Doctolib, we are, I think, between 2,500 and 3,000 people, depending on the month. We grow quite fast at the moment. We do also have a split between product and tech, similar to what you described, also in terms of the role of the PM. But that's also what we're striving for. I think that definition of the split and the role of the PM doesn't necessarily apply to all the teams; there are some specificities. But that's the idea we have.

[00:02:07] In product, we have designers as part of the product team. Data is also part of the product team, so that's one big unit, and then we have the tech side on the other side. This being said, tech and product always work in pairs. We do have two different departments, but we always have a pair: an engineering director and a product director, an EM and a PM, each time.

[00:02:34] Jason: Yeah, and from the DueDil perspective, it's actually been an interesting year, because we merged with another company towards the second third of last year. So there's been a lot of re-imagining how we work together and trying to bring two different product cultures together. I'll say completely openly that the product team is still very much in development at the moment. We've brought together two small teams. We've got three people, myself and two other people in the team at the moment, and we're looking to hire another couple of people and start to scale out properly.

[00:03:07] The way I'd say it at the moment is it's a bit all hands to the pump. It's a very small company, I think 60 people total, going through this journey together to try and work out who we are. We've got an exciting new name reveal and rebrand coming out next week, which should be pretty cool as well. We're just trying to work out what the best types of people to bring in are and how to organize. We're very much looking to organize around problems to solve, versus just being a bunch of people working very specifically on certain bits of platform. We want to focus this on the user.

[00:03:43] Another thing to call out from our side is that a lot of our clients are very big businesses. We're a B2B company, and we're very sales-led in our approach to market. There's no B2C element to it at all. There are some smaller companies, but the vast majority of our strategic efforts go to that bigger side, which obviously has its own impact on how product teams get to execute on the plan and how they even get to make the plan in the first place.

Where the product manager sits

[00:04:17] Host: Really great. Hannah has been replaced with me. We're having a great night; this is great so far, so thank you all. I wanted to ask, maybe Fanny, you could talk through where, in your opinion, PMs sit. For example, is it one product manager per team, or is it five teams per product manager? Is it group product managers? What's your opinion there?

[00:04:45] Fanny: That's a great question. I think it really depends on what is expected from the team, and I'll explain a bit what I mean. My ideal is always to have the PM sit in the team with the people coming up with solutions, because the closer you are to team members, the better you can engage them towards your vision, and it's much easier to get things done, I felt. This being said, I also see now in my current role, because we work in such a specific industry, healthcare, there's so much stuff you need to know that sometimes the role is slightly split. We work a lot with product strategists, for example, and they take care of checking all the things that as a PM alone you wouldn't have time to do.

[00:05:31] They sit outside of the team. This comes with good things, because they can do part of the job that we would not be able to do, but it also has the drawback that there's always a knowledge gap that you're not able to build on, or you miss some opportunities because this knowledge is not directly in the team. So I think, if possible, the knowledge, the PM and the strategy should always be part of the team. But it doesn't always work, because sometimes you have different needs, and then you need to slightly adapt. But the closer to the team, I believe, the better the results you get.

[00:06:07] Leonard: Yeah, if I can just add on, I would agree that it's very important to be very close to the team. I think the discussion of whether it should be in the team or outside the team is more of an "it depends": on the size of the company, the domain and knowledge you need, how close you are to the users and so forth. I would think, regardless of how you are, you have to be close to the team. You have to be a trusted stakeholder as a product manager. You can tilt the discussion a bit and say: do you need to have the trust of the engineers? Do you need to have the trust of the UX team, the UXR teams? Of course you do.

[00:06:41] But do you have to lead them as a people manager? Probably not. That's my personal opinion, and this is where I think the size of the company and the way things are make a difference. I think it's a really interesting discussion and an interesting problem to think about. But you can't go wrong as long as you agree that you need to be able to influence them and have them trust your instincts, your opinions and your direction.

[00:07:03] Jason: I think the key thing for me, and you touched on it with some of the other comments, is that this is a partnership. If we're going to say that product managers need to be close to or in a team, again, I don't necessarily think that specifically matters, as long as it's a partnership of equals where you've got product, design and engineering all working together hand in hand, skipping down the road, saying this is what we need. That can be achieved in a number of ways. You've also got to call out that, of course, in a company like Google, with all its massive scale and all this money, there are plenty of ways you can experiment with team structures, and you can hire and not hire people. If you're in a fairly small startup and you don't have a lot of money and a lot of ability to hire all those people, then necessarily this might get a bit messier as you start to build out and scale.

[00:07:58] But ultimately I would always want to optimize the team for that partnership, and make sure that the people who are building this product together are building it together. You don't just have someone swooping in every now and then, leaving a present on the desk and then leaving again. This should be a collaboration, and whatever we can do to optimize for that collaboration is the most important thing from my perspective. I do agree that getting people close to the team is a given. In the team, it depends on what you mean by "in," and to some extent what you mean by "team."

[00:08:33] There are different ways to lay out a company. I'm generally very much in favor of having an area or a problem that a team is supposed to solve, and that you would have a product manager in the team. We'll probably come back to it, but I still think that should be a product manager who reports to a product function, not just a failed engineer who didn't make it as an engineer and got put into the product role. Product management is a skilled job. There are things you need to be good at to be a good product manager, and there are practices that should be at least promoted, if not fully lived, through a product management function. I just think it's important to make sure that is driven through a strong product organization rather than just being a hanger-on.

[00:09:20] Host: Interesting. So if there's one product manager per team, do they have that vision and strategy at that level, or are they focused more on delivery? Is that what you're saying, Jason?

[00:09:32] Jason: No, I don't think product managers should be focused on delivery. Obviously they need to deliver stuff as part of the team. It's the team's general responsibility, if we live up to all the agile and Scrum clichés: we're all in it together. That's actually the best way to do it. We're all in it together. But I don't think the product manager is just there to crack the whip and tell people to build stuff. They're there to set the context, give the feedback, stand up for the team and protect the team, and define the scope and protect the scope, and all that good stuff.

[00:10:05] When it comes to an individual team, say you've got three teams or three PMs, those PMs necessarily have to be aligned with the overall vision of the company and the overall vision of the product, because otherwise they're going to be building stuff all over the place that doesn't support that vision. But that vision for the product as a whole, or what I refer to as the portfolio, would presumably be set by some kind of head of product, group product manager, some other person who's operating at a different abstraction level. Those people within their teams who are given those problems to solve should be given more or less the autonomy to solve those problems the best way they see fit with their team. So they still have a strategic role; it's just that the strategy is part of a bigger strategy, which ladders up to support the business. That'd be the way I see it.

Strategy, hierarchy and coordination at scale

[00:10:54] Leonard: Yeah, I want to add, and I 100% agree, you need to have that hierarchy. A PM is responsible for, in our case, features, a separate part of the feature, because it's a large, large product. So you'd be responsible for a feature, and a group product manager would be overall in charge of that feature, as in if it fails, that's on the GPM. But the responsibility is pushed down to the PM on the individual level, who is then empowered, to use a very famous quote from Marty Cagan, to make the right calls and the right decisions. Now, obviously, there are going to be a lot of reviews in a large company like ours. We do a lot of reviews to check and make sure everyone's aligned, and of course the GPM is the first one who'll be at fault if that hasn't been truly vetted, because as a people manager your role is to make sure the team under you is performing at a level where they deliver the right product that you want.

[00:11:45] So it balances that way. It's almost like checks and balances: are we driving the right velocity in the right direction we want to go? And as you grow in a company like Google, you get more scope. That's how we define it. Your scope will be one product as a GPM; now you're a director and you have four products; now you're a VP and you have a whole area. So it's very typical how that scales. But of course you also get the team to work with you, I think that's the right way to put it, who are able to execute on different functions.

[00:12:15] Host: Yeah. Leonard, I'll stick with you for a moment on that. With a large number of teams like Google, how do you coordinate? Are teams independent, or how do they overlap, or do they overlap in any way?

[00:12:26] Leonard: Oh yeah, there's a lot of overlap, and you do stuff that affects other teams. You have to have a healthy culture of respect, and we have a really good culture of respect. That's one of the things I really love about the company, from my personal opinion. You don't break other people's code, for instance. You can break your own code, but you don't break other people's code. That's an engineering creed, but of course it's up to the PM to fix that if it happens, and I've been part of that. It's a really fun journey. But we have a culture of respect for each other, and of how you are impacting other teams.

[00:13:01] Of course, that's typically what's being, "escalated" is the wrong word, but considered by the executives. They will look at things like: wait, are we aligned and going in the right direction? Is this fulfilling the mission? Are you laddering up to the largest strategic initiatives we have? I think the coordination there is what slows down larger companies. We find a way to still make it move faster, but obviously a tiny 60-person company will be able to move a lot faster than a large 140,000-person company. That's fairly obvious.

[00:13:35] Host: Yeah, that's great. And Fanny, what are your thoughts there on how your teams coordinate? Are they self-sufficient, are they independent?

[00:13:45] Fanny: Not as independent as they could be. I can give you an example. We're split into different domains, and each domain is more or less one mission, mostly based on the type of users we work on. We have a domain focused on patients, and then a domain focused on pro users, for doctors and hospitals, for example. Obviously those two are not so connected. But when a team works on a project, they don't work only on their part. We work on the end-to-end experience. That means if I build something for hospitals, I also have to take care of the patient side, and it needs to be super aligned with the teams who have much more experience and knowledge working on that part of the product.

[00:14:28] And we were not super good at this, let's be honest. We made some changes. Now we identify each quarter which projects will be touching different parts of the product, and then those people form their own meetings and have their own alignment to make sure that nothing breaks. It could still be optimized, I think. But as Leonard mentioned, the more the company grows, the more alignment you need and the less autonomous you become, in a way. So it's always about finding this balance of how much autonomy you can still have and how much alignment you need with the other teams.

[00:15:06] And it's not only about alignment. It's also about the experience from other teams and the skills you can get from others, so you don't have to repeat the same things over and over. If you think about user research, for example, from a team that is specific to that area, you also want to reuse what they learn. So you always have this overlap about sharing knowledge, which I think should still be improved. We also started to have PMOs to lead this kind of project sometimes, and that helps. But there are always things to improve on alignment.

Team counts and platform product management

[00:15:43] Host: Yeah, that's great. There are a few questions in here, and one for you, Fanny, which I like: with nearly 3,000 people in Doctolib, how many product managers are there in the company, if there's one per team?

[00:15:57] Fanny: Exactly, that's a math question. We have around 60 teams, and we have a bit more PMs than teams, because some teams have APMs and then a senior PM, so there are two, so they can learn. But we have one product person per team, let's say, for 60 teams. We also have a whole domain on developer experience, and more technical teams in a way. They also have PMs, because they just have different types of users, let's say, but they also have their own missions.

[00:16:31] Host: Great. And Jason, how about you? What's the team like for product managers?

[00:16:34] Jason: Well, again, we're a nascent product organization and still pretty small, so we've very much got three people looking after basically three bits of the stack at the moment. One of the things that's interesting, talking about this alignment thing, and something we have as well, is the concept of a platform product manager. So much of our offering is based on data. We're a company that's powered by data. We do a lot of stuff on top of that data, but at the same time the data is there and it permeates our system. So we have the data platform that empowers a lot of the user value that we can give, and that obviously could be sliced and diced a number of ways. The concept of a platform product manager is not that crazy; there are plenty of places that have them.

[00:17:27] But the alignment overhead is still there, even as a small company. We've got customer-facing APIs, we've got internal-facing APIs, we've got the platform APIs, we've got data ingestion and all of the stuff that goes on. Trying to make sure that changes that are required permeate through the system, and in some cases are worked on by data engineers in one team or by front-end developers in another team: there is actually still a need, even in a relatively small company, to maintain alignment between teams. Now, one way to slice and dice that could be to go mega cross-functional and have data engineers in every team. We've not done that so far, and there are arguments for and against, obviously, depending on how fundamentalist you are about cross-functional teams. That kind of debate could last forever.

[00:18:17] But the simple fact is that, with regard to alignment, there's an interesting dichotomy in a way. Ultimately the product managers, or the product manager for an initiative, for example, are responsible for that initiative being successful. Not everyone likes the word, but it's their responsibility, or their accountability, and they're the ones who have to stand in front of that initiative. But there's obviously a bunch of engineers across different teams working on things that support that initiative. I am massively in favor, and I believe the engineers are in favor too, of managing a lot of that coordination on a technical level between themselves. It's not my job to go and tell a bunch of engineers how to engineer. They should be able to do that for me.

[00:19:01] There's an interesting question in the chat which maybe touches on that as well, around project versus product management, which starts to get my hives rising a little bit. The engineers in a good, well-functioning engineering organization, I believe, should be able to do a lot of that project management and get the engineering work done without being stood over by an overbearing PM or PO telling them what to do. That's not our job, to tell engineers what to do and tell them how to do it.

[00:19:37] And that's where I think the project management thing is interesting. Fanny talked about PMOs, for example, and I'm sure there are program managers and project managers and PMOs in all these different types of companies, and I'm sure there's a lot of use for them in certain cases. But I'd like to think that's something that only comes with massive scale, not something you bring in too early. Because ultimately, if you need to have so much oversight so soon, it does point to a certain amount of dysfunction within the organization, because you need adults to come and make you do stuff in order. It's like: we're all grown-ups. If this is a partnership, if we're working together, communicating and aligned, a lot of that project management should go away.

[00:20:21] Because of course project and product management are so entirely different that it's almost offensive to bucket them together. I know there's a common thing there, where everyone thinks I'm a project manager. And of course there is always some element of project management in any job; you've got to get stuff done in an order. But I think having a project management or oversight layer, certainly too soon, but to some extent even at larger scale, starts to feel like there are probably other ways to solve that.

Product versus project and delivery management

[00:20:53] Host: Yeah. Leonard, I'm not going to ask you about the complexity of Google's product managers, but I will touch on what Jason is talking about. Lucas asked the question: a common misconception they feel they run into is product versus project management. How do your companies balance those responsibilities, and are they separate roles?

[00:21:17] Leonard: Yeah, absolutely. On the last part, separate roles: absolutely separate roles, 100%. It's a very different role to be a project manager and a product manager. I do say there are a lot of people coming from project management into product management, but that's very different, because they're very close, especially if you're a technical project manager. You're working very closely with engineering, you understand how that world works, and you're able to translate that into the technical aspects you need for a product-related role. So, 100%, very different roles.

[00:21:48] On the responsibilities, Jason, I think you really hit it on the head there. If you have to tell the engineers exactly what needs to be done and in what order, there are some real other dysfunctional parts of the team. Now, there might be some use cases I'm not aware of, but from what I've seen, I've never seen that. To be fair, I interact with product managers all the time, on my own team but also people in other parts of the business. I rarely interact with project managers, and the reason why is because we rarely need them for what they do. But sometimes you need them. If there's a big initiative with a lot of coordination, you need someone, not to be the adult in the room, but to keep everyone on track. If there are 15 moving pieces, and it's not within one team but spread across 15 teams, then you need someone who can really guide this.

[00:22:40] So project management is a really interesting one. We don't operate with product owners either, even though you could argue some product managers become product owners due to the nature of the product. It's not a crystal-clear answer on how you balance those responsibilities, but I think it's very clear that they're separate roles, and it should be very defined in the title. We call them PgMs, as Jason was alluding to, for program managers, who are very different. Project managers, or program managers as we typically call them, can also be handling some initiative you're driving that isn't necessarily technical; it could be something different. So, yeah, a little bit.

[00:23:17] Host: I love it. Fanny, do you have anything to add there?

[00:23:21] Fanny: I think most of the things were said. What I could add is that it doesn't always have to be a completely separate role, but it's important that a person in the team is in charge of doing this, and it doesn't have to be the product manager. Or maybe not even in the team, but someone has to do this role of leading the delivery. It doesn't have to be the PM, because the PM should lead the discovery. So this split should happen, and then whether it's a project manager, a PMO, a program manager, a developer or a tech lead makes no difference for me. The role can be split and could even rotate, but the split between the discovery phase and the delivery phase really needs to be clear.

[00:24:06] Host: Yeah, I really like that. Leonard, I'm going to touch back on you. Does the product manager look after delivery management, or is there a separate delivery management in your teams?

[00:24:18] Leonard: No, no way. That's typically up to engineering. As I mentioned, it's up to engineering how to deliver. The typical product manager will come in and say: okay, we have this vision, this is what we're building towards, and this is the requirements doc we have for whatever feature we want to talk about. Then you start asking the engineer: how long will it take to get that right, and can we get this as part of whatever framework you're using, typically OKRs or something similar. So there will be some accountability on what's being prioritized. There's a lot of conversation, typically, of "is this a P1 or a P2?"

[00:24:51] If you're not familiar with the P system, you have P0, P1, P2, P4. If it's P2 or below, you might not make it in the quarter. So it's a very big discussion of what you want to prioritize, but that's an exercise for the PM to do together with, of course, the engineering managers and the TLMs, technical lead managers. So product managers do not do delivery management in any sort of form, or making sure that something is being delivered. That's handled 100% by engineers.

The product manager as advocate

[00:25:20] Host: Yeah, I really like that. Jason, I'm going to ask you this question. It's from Leonard in the audience, a different Leonard, I'm assuming: "Having been a project manager and product manager myself a while ago, I see the product manager as the main role that needs to convince stakeholders, every type of stakeholder. Would you relate to this in your organization? Basically, are they a salesperson more than an engineer, more than anything else?"

[00:25:49] Jason: Yeah, well, my background before going into product was very much more on the engineering side, building the software, and then slowly segueing over into product management over the years. I think it's natural for me in many ways, and probably for anyone. I call it your area of most capability. There's a thing you're going to be most comfortable with, and your instincts are going to be in a certain area. For me, coming from a development background, 20 years developing software, there's always going to be some level of comfort in dealing with my engineering peeps, because those are my people. But at the same time, that's not my job anymore.

[00:26:37] And going back to that idea, I can quite honestly open up and say that I wasn't the best developer, but I don't want to be seen as a product person just because I wasn't a good developer. My interests brought me in this direction, and my desire to contribute cross-functionally across all the different parts of that wonderful Venn diagram that we all know and love. So for me, wherever my instincts may draw me to, and there's always probably a drift there, when times are hard you go back to your area of comfort. But I don't know if it's necessarily being a salesperson, more like an advocate, a chief advocate for your product. An advocate not just for the engineers, not just for the designers, but also for the business, the commercial side, the users, of course the users.

[00:27:25] And to try and bring yourself as close as possible to the center of all of those different circles on the Venn diagram, which I've probably added two more circles to now, to be there in the middle, standing up for everyone. Standing up, again, for the users, but also for how you're going to serve them, how you're going to get the product into people's hands. You're going to have to deal with, in B2B, salespeople. You're going to have to deal with account managers. You're going to have to deal with direct client requests from the person who represents 25% of your revenue. These things are going to happen based on the type of company you are.

[00:27:58] So for me, yes, it's 100% a function of product management, or the product management team, to be that advocate for the product. Obviously, as far as possible, with good product thinking and good product principles, to make sure they're building products in a way that everyone enjoys, and that they're building the right stuff because they're actually doing the research and all of that good discovery stuff. And then being the advocate for all of those, and ultimately, from an advocacy perspective, selling to the rest of the organization, including the engineers, working with all of these people to make sure they bring that product across the line and get it out to as many people and delight as many people as possible.

[00:28:38] So I do relate to it. I think B2B, certainly B2E, ascending into enterprise, does have a few wrinkles on top of that which maybe make it more like that as well, because again you have these big power dynamics between big clients and small startups, and you have to try to ride that wave as well. But the biggest thing I want to get product managers away from is being seen as either part of the development team, just an extra person in the development team who doesn't do as much coding, or someone whose job is just to pass messages back and forth to the developers. Those aren't bad roles, in a way, but they're not product management. I think we need to shift the narrative and say that product managers are there to help the company make good decisions about the products it puts in front of its users, and that involves being equally close to all of the different parts of the business.

Single-threaded leaders and executive sponsors

[00:29:32] Host: Great. Fanny, I'm going to ask you a question that's from another person, around the Amazon concept of a single-threaded leader for large initiatives, as opposed to product managers. They found having a senior person, not outsourced, helps to keep deliverables on track. Is there a similar role in your organization?

[00:29:55] Fanny: That's actually a great question. We don't have a similar role per se in the organization. We have directors in charge of each of the domains, and they're in charge, a bit similar to what Leonard said before, of making sure the results for that specific part of the company work. But we did have an example recently. Because we work in healthcare, we were working on the vaccination effort in Germany and in France, and we built a task force. For that task force we had one of our leaders, a product leader, put in charge of the specific task force and the whole project, because it was a very intense and very risky project that we really needed to get done fast.

[00:30:37] So he was also in charge of making sure of the delivery, and making sure that everyone was aligned from all the different teams, not only product teams. That, I think, was really, really helpful. I don't think it would apply in our case for just any type of project. But for a very large initiative, as mentioned in the question, maybe it makes sense. It definitely worked for us in that specific case.

[00:31:02] Host: Brilliant. And Leonard, I have to ask, given it's an Amazon question, what's it like at Google?

[00:31:07] Leonard: Yeah, what I've seen, at least from my perspective, is we have what we call executive sponsors. If there's a large initiative, you have executive sponsors, meaning someone at a somewhat senior level will run this and start asking questions. And typically what happens is, when someone senior asks questions, things tend to be prioritized. I think that's not the way to say it, but it's somewhat of a shortcut. It's a similar concept, but it's very much on a case-by-case basis, if you have any issues you want to do that for.

[00:31:39] There are a couple of cases I remember where Sundar has been saying this is a priority for the company. Obviously that flows to everyone, all the different areas, and then the question is: how can we tackle this large problem we want to solve? If you look at what we did in AI, or machine learning, I think that's one example where we really positioned ourselves in a good way to deliver things like the Assistant, which I think is a great, great product. So, yeah, something similar.

Limiting duplication of effort

[00:32:08] Host: Oh, really great. I'll actually go back to you, Fanny, on this question: how do you limit duplication of effort across teams?

[00:32:21] Fanny: That's a great question. There was for sure some duplicated effort, but we now have, and I don't know, it's a bit sensitive these days to mention this, a team of product operations people. What they do is come up with processes and templates and basically all the bricks we need to do our job. Nothing's forced, but they give us the options to learn better and to make sure we don't duplicate things. It's not a magic recipe, but the area where it helped us most was really user research, because we had a lot of discovery work that wasn't shared, and that we just duplicated, and you had to learn the same things over and over again. Having a better process to share the findings really helped us.

[00:33:14] And the same for the things you want to check before starting to work on a project, basically all the, not administrative work, well, maybe a bit. For all this work we have tools, so that we don't have to redo the same things over and over, or recreate the same type of documents that are used for these kinds of things. For this type of duplication, that really helps.

[00:33:43] But I think what helps the most is also speaking. You have to have a good culture of sharing best practices. We have team meetings, the product team meetings, every week, where everyone shares learnings and these kinds of things. I think this communication within the product team is very essential, because you can have as many processes as you want, but if you don't know what others are doing, you might end up doing the same things. Learning from each other is very important for these topics.

[00:34:11] Host: And if you were to pick a tool or a method of communicating with your team that's the most effective, what would it be?

[00:34:21] Fanny: That's a very good question. Two things. There needs to be some kind of written documentation tool. We use Confluence, because we use Atlassian. I don't know if Confluence is the best; I think the search is pretty horrible, but it does the job. If you're well structured, it's easy to find things. But you need to have one tool for written documentation. And the other one would be a very basic thing: a video calling or meeting tool, so you can have those discussions on a regular basis. It doesn't have to be any fancy tool, really just speaking, inside or online, either way, having those conversations. That's my tool of choice.

[00:35:03] Host: Yeah, really great. And Jason, how about yourself, on limiting duplication of effort across teams?

[00:35:09] Jason: Well, again, we're a smaller company, so we get to talk a lot more anyway. We still have to stay aligned, and I think alignment is actually one of the biggest problems, even with a small company. I have this image in my head of people starting to talk to each other, and they start to get aligned, and all the lights start to turn into one light. But then as soon as they stop talking, almost literally as soon as they stop talking, the lights start to drift apart again and make different shadows and all that sort of stuff. And you can't just keep talking to people all the time, because obviously you'd never get any work done. So there has to be some kind of middle ground.

[00:35:46] It's the old cliché: you have to tell someone something 7, 12, 15, 25 times, however many times, for them to actually remember it. And even then they probably don't remember it the way you think you told it to them, because you missed something out or put a comma in the wrong place. So communication is super important. But again, as a small company, we're probably better placed to do that than, say, Google, because if I want to, I can just round up the entire technology and product leadership and have a call with them, and we'd probably get two pizzas in that call. We're not at that scale yet.

[00:36:24] When it comes to tools, it's another cliché, but no amount of tooling is going to fix a broken culture. I was actually chatting to a guy earlier, doing a mentoring call, around this idea that a lot of companies try to fix stuff that's wrong in their company by just whacking loads of process on top. Now, this isn't an attack on product operations. I think in some cases product operations is a very good idea. But if you just put process on top of something that's not working, thinking it's going to solve all the problems because now you've got a checklist or something like that, that's not going to do it.

[00:37:00] You need to go back to basics and start to realize that there are things, maybe it's your lack of ability to focus, or the fact that you're drowning in tech debt, or that you've got two teams that don't talk to each other because they hate each other, or because one person wants to work one way and another person wants to work another way. These are all things that need to be addressed, but no tool is going to do that for you. You've got to actually get back to basics and have, as Fanny said, really good conversations, and try to get people to open up.

[00:37:25] But with regard to tools, we use ClickUp. We actually got off of Jira, and that was fantastic. That was like angels singing from heaven when we got off Jira. Everyone seems to want to have a boot into Jira these days. So we use ClickUp for the collaboration piece, a bit of Miro. But frankly, again, as Fanny said, good old-fashioned documents as well: one-pagers, or however many pages you can get it down to, to share around, in a sort of RFC, request for comment, type model, where people can come in and pick holes in your plans, or say that sounds stupid, or come up with some other suggestion you didn't think of yet. I think stuff like that can be really helpful as well.

[00:38:09] Host: Yeah, great. And Leonard, do you have anything to add on duplication of effort?

[00:38:14] Leonard: No, I think the only thing I would add is on the communication side: the written word is much stronger, I think, when you have a lot of stakeholders. The request-for-comment style is something we do all the time. You socialize a document, which of course is what you say you're going to be doing, and that just makes sure everyone has had their chance to say, "No, this won't work because of this thing you didn't think of." That's a way to start to socialize it, and we have the written culture down.

[00:38:40] The second part is that we also spend a lot of time engaging with product teams, even if you don't work with them day to day, for the learning sessions which Fanny was alluding to earlier. It's just the best way to understand, because someone will have had the challenge you're currently facing. In a company like ours, the chance of someone having that experience is very high, so you want to make sure you learn from them. So we do things like summits; there are all types of communication methods we use for that. It's very focused on using video, of course, in this day and age, but it used to be typically physical sessions as well, so you can build those really tight relationships as you sit down and have drinks after some event, which I think is really, really useful.

The product and tech relationship

[00:39:22] Host: It's really great. I'm going to stick with you, Leonard, and ask you: at Google, what's the product manager and tech relationship like? Does one report to the other? Are they peers? Are they friendly? Are they combative?

[00:39:38] Leonard: Very friendly, I would say, very friendly, of course. And they're peers; you look at them as peers. I think we talked about it before, but there was this fantastic video, sun market system [?], about how to become a product marketing manager, which is their word for product manager. In it, it says: if it's a challenge, you have to fix it. If specs are wrong, you have to fix it. It's your problem; you chose product marketing. I take that into my work. If there's an issue, it's my job to fix it. Let's say there are two combative engineering teams, for instance. It's my job to get them in the room, make sure we align on what we need to do, and move forward. If there's some other issue, it's my responsibility, or my team's.

[00:40:24] So it's very much how you look at that. But to be fair, we talk about the triad all the time. The engineering manager or TLM, or whoever leads the engineering team, is just as much a peer, and then of course the UX lead, on the visual side but also the UXR side. Between those three, it's very important that you are peers. You're three leaders for whatever project or initiative you're doing. But I must say I do notice a lot of things happen to fall back on the product manager to fix, because nine out of ten times the problem is typically on the business side of what we need to do, at least in my experience. That could be marketing, could be support, whatever, and then it's up to the product manager to fix it.

[00:41:07] Host: Yeah, I really, really like that. And from what you're saying as well, it's almost a cultural issue, in terms of if two people need to get into a room, you almost need to fix it; maybe there's a business alignment, or lack of business alignment, or something on that end. Fanny, what's it like on your side, the tech relationship and the product manager?

[00:41:31] Fanny: It's very, very similar. We have two different departments and we always work in pairs, so we have to be very, very close. Luckily, so far, no issues were raised, so it worked really well. But I would maybe add that in the past I've noticed, not so much on the team level or individual level, but on the high level, if you don't have this alignment, if the relationship between tech and product as departments is not very aligned, this just leads to many problems down the path. So I think it's important on the team level, but also on the company level, that those two departments are very much aligned and have good relationships.

[00:42:14] It can also be useful sometimes to have some friction, because you do need to have those discussions sometimes, pulling to one side or the other, and that's also how you make decisions sometimes. But I felt every time I was working in a company where the two teams were not aligned, it just led to many issues down the path. I think that's one key point to note, maybe.

The hardest parts of the job

[00:42:39] Host: I really like that. I'm going to stick with you, Fanny, because Katie here asks a question: what is the most challenging aspect, in your opinion, of being a product manager?

[00:42:50] Fanny: That's a great question. I would say the definition of the job, maybe, because it's very different from one company to the other. As a PM, you would join a company having your own expectations, and then you discover that maybe it's not exactly the same as the company who hired you. We all have this understanding, when you read the articles or go to events like this one: everyone has their own opinion of what the job of a PM is. And also within a company, the job could be different from one team to the other. I would say the most challenging part would be to have this understanding, this alignment of expectations: what you can offer, and what the company needs from you and what the team needs from you.

[00:43:30] Host: Perfect. And Jason, I know you're nodding your head, I know you've got a point on this. What are your thoughts on being a product manager?

[00:43:37] Jason: Oh God, I was going to say the most challenging aspect is getting to sleep without all the internal screaming every night. But no, I think what Fanny said is really true. There's a big difference between a lot of the classic literature out there, Inspired and so on, fantastic books that we should all read and try to live by as much as we can, and trying to translate that into your own reality. That can be seen in some cases as a cop-out, in the sense that some people say, well, your company is the thing that needs to change, not the book. And there's probably a bit of both in there.

[00:44:16] Ultimately, books like Inspired and all the other fantastic books out there are written from a certain perspective, probably one that's closer to Google's than others, because it's come from a lot of the big tech world. I don't believe all of those things apply to all companies and all situations. But at the same time, I do believe product managers should be advocates for good product management. One of the things I randomly tweeted the other day is: if you're going to hire product managers for your company, let them do product management. If you don't want to let them do product management, then consider potentially not hiring product managers, and get someone else to do whatever it is you do want them to do.

[00:44:54] Maybe you do want a project manager, or a delivery manager, or a bunch of business analysts to just write up your desires into a form that engineers can read. These are all completely valid roles, and there's nothing wrong with doing any of them. But if you want to do product management, if you want to build a product and get product managers to help you build it and define it and work out the best way to satisfy everyone and build the business, then get people in and allow them to do that. For me, that's the challenge, and I see it a lot with the mentoring as well. There are a bunch of people out there who are product managers, who want to do good product management stuff. They're flexible as to how they do that, but they have aspirations, and they're being blocked at every turn by companies that hire them and have no idea what to do with them. I think that's a big challenge.

[00:45:41] Host: Yeah, it is. There's a question here from Lucas, and Leonard, I'm going to take this to you. Assuming everyone has their specific responsibilities in building the product, how do you as a product manager create a sense of shared accountability for what you're building together? I'd guess at Google it's quite difficult, feeling like a cog in a wheel almost. How do you create accountability?

[00:46:07] Leonard: Accountability comes with responsibility. As a PM, as long as you feel empowered, and again I'm not talking about Marty Cagan's part, but as long as you personally feel you have the mandate to do something, the accountability comes with that, because you know you're the one who can change this. It's in your hands to say, "I need more resources to do X, Y and Z," and of course come up with a plan for that. So accountability, I don't see it as a big issue. Even when things go bad, we have retrospectives or post-mortem processes, and those are really good in terms of making sure you can articulate what went wrong in a blameless manner, and say: sure, we did this, this was wrong, this was the wrong thing that happened, and we want to change that outcome. How can we change that and improve the process?

[00:46:54] So accountability, to me, is less of an issue. As more people build together, it comes back to alignment. If people are building in vitally different directions, there's something wrong, either in the documents that have been shared, or they haven't been given the right input. Sometimes you discover those some way into a process, and then you just have to course correct, and you're being flexible. I think Jason touched on it: being flexible as a PM is almost the most important thing you do. It also answers the other question: the most challenging thing is that you have to be so flexible.

[00:47:32] Most PMs that I meet are, and especially when we interview, you can really notice who are the flexible thinkers and who are not. If you're a flexible thinker, you're good in my book, because everything else I can teach you. That's why I built a big framework [?] which really cuts out some of the elements of behavior an individual should have as a product manager. Being flexible is one of them, and I wish I'd added that into my framework. It's very important to be able to stretch yourself, but at the same time it's really tiring, and that's why sometimes you're screaming inside in some meetings. You go out, you have a walk, you scream, and then you go back in and continue your day.

Upskilling junior product managers

[00:48:09] Host: Great, and you can do 2.0 of the epic [?] framework next time, Leonard. We're almost out of time, but I want to touch on this question from each of you, and then a very quick closing point, if that's all right. How do each of you upskill junior product managers to take on a team? Jason, quickly, I might start with you.

[00:48:35] Jason: Yeah. Touching on Leonard's point around clover [?], you can train a lot of stuff into people, but it's a lot more difficult to train attitude or mindset and stuff like that. That's something you'd probably want to hire for, with the caveat, of course, that you definitely want to be diverse and inclusive in your hiring, and you don't want to overcompensate for that. But you definitely want to get people who have that hunger and that adaptability, because that's very difficult to train and it takes potentially years to train that in.

[00:49:11] Apart from that, you have to identify people's learning styles. Some people like books, some people like courses, some people are school of hard knocks like me, some people like to go through certifications. Nothing wrong with any of those. Personally, I think there are probably two or three books that all PMs should basically read, whether or not they get to live them. They should read them and internalize them, maybe read them a couple of times if they can.

[00:49:38] One thing I did with an old team was get an external trainer in. I got Janna from ProdPad in to do a day's training, because even though I'd say much the same things as she would in principle, because we believe in many of the same things, she's an external expert. Bringing in that external person, who is completely abstracted from your day-to-day, to come and say some of this stuff in an unbiased fashion, I think could be really powerful to try and inspire people towards moving towards something and build some of those skills up as they go.

[00:50:10] Host: Great. And Fanny, how about you? How do you upskill junior product managers?

[00:50:15] Fanny: I completely agree with Jason. When I was working at a smaller company, that's also the type of thing we did. Now, at Doctolib, we have an APM program, where we take people from other departments who want to become product managers, which I find is awesome, because they're also great and they have great experience. They get a bootcamp of one to two weeks where they get lots of different sessions, and after that they're mentored by one senior PM, who lets them make mistakes and learn, and coaches them. It's similar to what Jason explained; we just do this internally. But otherwise, reading and going to these kinds of events also helps to shape what you believe is the right way to do product.

[00:51:00] Host: Great. And last but not least, Leonard.

[00:51:04] Leonard: Yeah. You upskill your junior PMs, of course, with a formal program. We have an APM program as well, and you can do internal transfers at Google; that's another way to do it. But I think the real learning comes from having someone coach you who has done this before, who can say: okay, so what are you thinking? And really coach you. It could be marketing, it could be sales, the same thing. I would argue it's the same challenge, but from a product perspective it's such a unique role that having someone who's done it before is very useful.

[00:51:36] I tap into a lot of the more senior leaders. We have VPs who've been in the company for a long, long time and can explain to me why things are like they are, because sometimes you bang your head against something and you're like, well, it's been like that. And then I try to do the same with my team and the teams I work with: to be that coach, and figure out, okay, I actually read about this somewhere, let me connect you with that individual, let me connect you to that document or something similar. Being as helpful as you can. That's the core thing.

[00:52:05] The other part, I would say, is to let them make the mistakes. I have been in many sessions where I've been coaching someone and they have an opinion, or an idea, which I don't think will work, but at the same time I know they're brilliant and I trust them, so let's see how this plays out. Sometimes it doesn't work out, and then you have to course correct before they really crash into the wall. But you let them get as close to the wall as they can, because then they learn, and they'll try to adapt, hopefully, the next time.

[00:52:33] Jason: Just one bookend on that, on the point about coaching and mentorship, specifically mentorship. I think mentorship is one of the highest-leverage activities you can have, from a junior through to a leadership position. It's easy to think that people might need less of it as they progress through their careers, but I don't think that's true at all. There's always something that's new to you that you don't know, and that's okay. Having people around you, peer mentorship, or even mentorship within your company or whatever, can be super high leverage, because it can help you understand what's okay and what's not, what's the problem and what's not, and help you build a lot of confidence as well.

[00:53:14] Host: That's great. We are over time, unfortunately. That was fantastic. I think this is a really important topic, and I'm delighted that all of you got involved. So thank you all again, I really, really appreciate it. We'll do a post summary after this with all of your details, and if you ever have anything to add, we'd love to have your thoughts again. So thank you all for a great session.