Do devs need a product manager?

Hello, and welcome to Go Time! Today we’re gonna be talking about whether software engineers need product managers. We’re gonna be discussing this with our wonderful guest, Gaëlle Sharma, who is a senior technical product manager at The New York Times, leading the identity group, and I am very happy to inform you I am joined by our wonderful panelist, Kris. Hello, Chris.

Hello.

Happy that you joined us for this conversation.

Happy to be here. How are you doing, Angelica?

I am good, I am very excited to have this chat, given the fact that I – well, as most of you know who listen to the podcast, I am a product manager, but I love engineers, I like to think of myself as a secret gopher… So I think this is gonna be a good conversation for us to have.

First of all, I’m gonna kick it over to you, Gaëlle, to explain to our lovely listeners who may not be aware, what is a product manager.

[03:54] Yeah. Thanks, Angelica. So a product manager, in the definition I like to give, is somebody who identifies the customer need, and links that with the larger business objectives, to deliver a product that will be successful in the market, it’ll help the company earn revenue, and also they’ll fulfill a need for customers.

So a product manager helps articulate the vision and rally a team towards that vision, and make it a reality. I think it’s a very exciting role to have.

And how is it different from a project manager? Because I don’t know whether it’s been your experience, but in my experience when trying to talk to anyone about what I do, they default to “Oh, okay, you’re a project manager.”

Yeah, yeah. So a project manager oftentimes can work very closely with a product manager. A project manager will be a little bit more focused on planning, or organizing and helping direct the completion of a specific project… So they’ll help make sure that the project is on time, or on budget, and within scope. They’ll really try to help track down open questions and make sure everybody is aligned and knows what’s happening next. So they’re really focused on a project, but in the progress and getting that executed.

A product manager might be doing a couple different things. A product manager could be conducting discovery with customers, like going out into the market, surveying how folks are using the product, maybe they’re doing industry research and trying to figure out where the new products should be, maybe they’re doing some research and getting feedback on an existing product and what could be improved, maybe they’re doing some sort of strategy work, trying to think about how the company should be evolving and what does that mean for their product… Maybe they’re helping the engineering team think about tech debt and how they should be tackling that… It could be a wide variety of things and it’s not always about executing a project that [unintelligible 00:05:52.12]

So tell me, how did you end up as a product manager?

Well, probably like many other product managers, it was by accident. I had no idea that there was such a thing as a career for product managers. I’d never heard of this. So earlier on in my life, when I was in college, I was really interested in public health, and that led me while in college to work at a community development thing. I was doing a fellowship where I was learning more about the community, what did it mean to do impact investing, and how we could make loans to small businesses in Chicago; that’s where I was located.

I had the chance to have a manager at the time during my fellowship who was giving me some feedback, and one day she said to me “Gaëlle, I think you would be a great product manager and that you would really enjoy it.” I had no idea what that was.

So she taught me a little bit about what it was, and she explained how some of the work that I had been doing was very similar to a product manager, because I had been helping create new products for the community development bank, and working really closely with customers and solving customer problems… So she really kind of opened my eyes to this potential career… And then later on, as I was trying to think about what to do as a next step after the fellowship, I found some product associate positions and I decided to give it a go and apply. It turns out I had a lot of good experience… And that was it. I just kept going further and further into this career path.

So yeah, somebody had heard about it, and saw that I had a lot of the skills or interests that mapped on well to doing a good job in this role, so they kind of like pushed me towards it.

Yeah, for sure. And I think it’s interesting how so many of the product managers that I’ve met have talked to this kind of falling into it. Like, they had no idea what it was, then someone spoke to them about it, and then they were like “Oh, actually, I’d be quite good at this.” I’d love to hear from you, Kris, in terms of coming into the industry… I know we’ve talked about it before a little bit on the podcast, but you came in quite senior, so I’d really love to hear a little bit about your experience getting to know how to work with product managers efficiently, what your experience has been…

[08:14] And also maybe a little bit about the difference between the various product managers you worked with, given that many of us have completely different backgrounds, whereas - I’m generalizing here - it seems that many software engineers know they wanna do this very early, it’s a very direct path to a job, as opposed to this kind of falling into it; that certainly has been my experience, and Gaëlle’s experience.

On your last point - I kind of fell into software engineering. I don’t have a CS degree or anything like that… But yeah, as coming into the industry as a pretty senior level person, I didn’t actually work with a product manager until probably like two or three years into my career. There just wasn’t anybody that was fulfilling that role in the places I was. My first experience with product managers - we were kind of like on the outskirts, because I was really working on internal stuff, so there wasn’t a lot of customer-facing things that I was doing, so there weren’t a lot of interactions I had with product managers… But I liked hanging out with them, they were cool people.

I think the first time I actually worked closely with a product manager though wasn’t too great of an experience. I think it was mostly – it seemed like they were a little too much on the project management side. It seemed like a lot of what they were doing was just very focused on the day-to-day of what the engineers were doing, and being like “Oh, this is what I want you to do”, and not really getting us the information that we really needed about what it is we were supposed to be building…

And I think that’s been a lot of my experience with product managers in general; it’s been not enough of like the really good ones, that kind of go out and they’re like “Okay, here’s all the information that you need, here’s the requirements. I’ve thought through the things that we’re gonna try and build; here’s the scope, here’s what you need to go do.” I’ve often found that I had to do a lot of that work and a lot of the heavy lifting myself, and then my team members who don’t do that heavy lifting wind up just not building the right thing at the end of the day, and there’s features missing, or something got completely mis-scoped… So my overall experience has been quite hit or miss as far as product managers are concerned.

This is interesting, because when I first took some Agile classes on how to be part of a team, and play the product owner role on the team, some of the nitty-gritty details were around “How do you write a ticket? How do you manage the backlog for the team? You’re part of the team and you’re doing the backlog management.” But I think definitely as you start to level up as a product person, you understand that really what you’re bringing to the table for the benefit of the team is doing all of that really deep research of getting to know the space really well, and developing those relationships with the customers… And even if it’s an internal product, perhaps your customers are other teams internally, and asking the right questions and surface feedback from the teams… And once you have received that feedback, kind of packaging it in a way that’s really nice to bring back to your team and be like “Hey, here’s what I’m hearing. Here’s what’s working really well” or “Here’s where we could improve. Here’s where I see us going long-term”, and then getting feedback also from the team. I think it really should be a collaborative exercise - we were learning something to decide “Okay, where do we take this learning? What’s the next step? How do we keep improving?”

But I do think there’s a little bit of an evolution that product people have to do. First, get some of the basics down, and then start to level up more and more, and learn the really key skills around doing the discovery work, and the research, and communicating well, and asking really good questions that kind of get that nice, meaty information out of folks… And then bring that back to the team.

[12:09] Yeah, for sure. I mean, Gaëlle, you talk about this collaboration between engineering and product, and Kris, you’ve talked about the collaboration perhaps not so successfully, but it’s been a collaboration… I would love to hear from either of you what you think makes a successful partnership between product and engineering.

Sure, I could take a first crack at it. When I reflect on partnerships with engineering that I really enjoyed, one, it’s been one where I can ask stupid questions… Like, “Well, tell me a little bit about the architecture of the app” or like “Why is it that we need to run this test? Why do we need to do this right now?” And having that space where I can feel comfortable and then I can be taught “This is why it really matters”, and then I can understand that “Okay, this will make the quality of the product much better, and we should be prioritizing this right now.” Being able to have that conversation with that part of my engineering partners is really helpful. If somebody can explain something really well to me, that’s valuable.

I appreciate diagrams. Diagrams are great. [laughs] Anyone who draws a diagram for me, typically it’ll really help me understand something, and then I’m likely to be able to take that information and explain it to someone else. That’s valuable to the team, if I can go to another team and explain like “Hey, in this sprint we need to be doing this and that, but the following sprint we’ll be able to deliver [unintelligible 00:13:33.22]”

So being able to learn from engineering partners works really well for me. I really enjoy truly feeling like I’m a part of the team, so I wanna participate in retro and I wanna hear the hard feedback on how I can improve as a product manager, and make things even better for the team. Maybe I don’t deliver a product requirement that was clear enough, and I was blocking the team; I wanna hear that, and I’m really open to it. So I enjoy when I have that relationship with my engineering partners.

And sometimes I really appreciate having a partnership where we can be creative together. Maybe I’m trying to solve something and I’m not exactly sure what we could do, but maybe we can bounce some crazy ideas around together, and we might find something that may not be the best solution, but can get us to solve something quickly… And then we’ll also talk about like “Okay, yeah, that’s fine for now, but here’s the other solution we would prefer to do.” I like having these conversations, and not being the only person that’s [unintelligible 00:14:35.29] out crazy ideas and like hearing the pros and cons. So I like a really collaborative relationship with my engineering partners.

I think what comes to mind for me, especially when you talked about getting in a room, brainstorming with your engineers - do you need to have software engineering expertise to be a good product manager? I know we’re gonna talk a little bit about the difference between a technical product manager and a product manager… But in general - maybe I’ll turn this to Kris - do you expect your product manager to have technical skills? If so, to what level? I’d love to hear a little bit about your experience there, and your expectations from a product partner.

Yeah. In general, I’ve found that there’s not really a clear line between where things happen; I think it’s this kind of dance you have to do between the product team and the engineering team to figure out where everybody is… So I do think there are some teams of engineers that just only care about the low-level technical stuff, and don’t really have that skillset and being able to suss out what types of things we need to add to the product, and figuring out all the different edge cases, and things like that… So I think if there’s a team that’s like that, then I think the product manager really does have to be a technical person, because they have to kind of descend down to that level so they can communicate with them. And if you have someone that’s not technical, but with a team that’s super-technical, I think there’s a lot of struggles that happen, especially around communication, especially around prioritizing things, and backlogs, and stuff like that.

[16:13] I’m kind of on the other side of things when it comes to being an engineer. I’m very good at thinking about edge cases, and what we would want to have in a product; I’m capable of sitting down and talking to customers, and talking to clients, and whatever, and kind of assessing what we need from there, and extrapolating.

So for me, I definitely prefer product managers who can focus less on the technical stuff and more on those higher-level requirements; people that can answer questions that I’m not capable of answering myself. And I kind of feel that that’s how we should be building engineering organizations. I think it’s not really that great to try and have someone that’s not very close to the code and working with the code all of the time trying to make decisions about what we should do with the code, or how we should prioritize things with the code.

So I think our engineers should level up a bit more to the product people, instead of product people having to come down. I also think if the product people have to come down, then it’s like “Well, who’s gonna do the other stuff that product people need to be doing?” We can’t just be like “Oh, well you just have all this extra work to do now, because our engineers don’t wanna figure out how to assess product requirements and translate them into actual things that we can go out and build.”

But I think it also has implications on who owns what. One of my interesting opinions is I don’t think product managers should own backlogs. I think in general that’s the place of the team more than anything else. The team should own their backlog and should prioritize it and they should have input from the product manager… But I think giving that away to someone else take away some of the autonomy of a team. This is especially true if the product organization feels further away from the engineering organization as a whole.

That is a very interesting opinion. [laughs] Actually, building off of that, I think – I had a situation where I had to step away from the team for a little bit, so I was less involved, and the team very much was operating without a product manager… And I think one of the things that worked really well for the team is having context; the team knew what was the goals for the team, what was the vision, what we were trying to accomplish, and from then on really the engineers could be self-directed in determining “Alright, we need to have these stories in this sprint, and it would really be ideal if we finished these milestones within this timeframe.” And I didn’t really have to be like a hawk over the backlog, and moving things around, or up and down to different sprints.

On the other hand, I think the backlog is a good tool for a product manager when you’re having conversations with other teams. That’s where it’s really helpful, because you can kind of keep an eye on if there was a request from another team, you have an understanding of “Alright, it’s not going to go into this sprint, because we’d have to drop something else, but it’s likely to go into the next sprint, so I can reasonably say it will be done around this timeframe”, and that helps build really strong partnerships with other teams, and then you can help move projects along if you ever happen to be from another team. Building that relationship and enabling teams to work really well together - that’s really key to delivering features in a successful way… Especially if it’s like a really complex project that has dependencies on many teams, aligning all the dependencies can get tricky. So I think for the product manager that’s where the backlog and keeping an eye on where things go becomes a really useful tool.

And I think too part of the problem is the tooling we have is pretty awful for most of this. I think any of the task/issue managers, JIRA, what have you - they don’t really have enough of the utilities you need, especially for complex projects. That’s something I’ve always found failing in the past.

[19:53] But there is something that we’re trying to do across multiple teams, trying to visualize and track that, especially at a not fine-grained, “someone will go do this individual unit of work”, but in this “Here’s a thing that we need to do and we wanna track it.” There’s a lot of work that you have to do to actually put all of that together or to assemble that, even within a system as powerful as JIRA.

And I think also not having a separate view of the tasks that need to get done I think gravitates people toward just piling everything into the backlog and being like “This is the source of truth.” And then you have different things that are supposed to be owned in there, and it’s not clear who owns what, and there’s not a good way for you to say [unintelligible 00:20:31.27] to be able to prioritize things in there. That’s always been my problem with some product managers, is when they kind of go into the backlog and they start rearranging the things that they want, and they just like shove down all of the dependencies… It’s like, we can’t do that; arguably, our tooling should prevent that from being a problem. It should prevent you from putting things out of order. But that’s really hard to do with the tooling that exists now.

Yeah. Something you said earlier really spoke to me, which is - I do think team members should be playing to their strengths. Like Angelica mentioned, both Angelica and I are technical product managers, so hopefully we know a little bit about the technical side of things, but really, I do think the engineers should be owning the technical side, and the engineering decisions. If we’re rolling out something and there’s some work that needs to be done and it’s very engineering-heavy, then I fully put the responsibility on the team to let me know “We’re gonna have to do this, and we’re gonna have to do that, and then we’re gonna do this, and then we’ll be ready to launch. And we want to plan the launch in this way, and do a gradual roll-out, whatever the case may be… Because I think the team ultimately has the ownership for building a really high-quality product or feature or what have you.

So I think the product managers should be doing the product work, helping make sure that we’re launching well, and that we’ve given appropriate communications to other teams, or that we’ve scoped what we’re going to do ahead of time, to give the context… But there’s definitely certain responsibilities that should be owned by different individuals, and what’s really important is just to have good trust with each other. If I know that you are working on the engineering piece of it, then that’s your responsibility, and my responsibility is to support from the product perspective.

So I guess to go back to the backlog management, definitely there’s more engineering-heavy tickets… My approach as a product person is always just to ask the team “Hey, how high priority is this? Should I keep it towards the top? When do you wanna be working on it? What is it going to enable us to do?” You know, just enough questions to be able to pull in into the sprint or not, depending on what the team says.

Break: [22:47]

How would you feel, Kris, about a product manager who was very technical, maybe was previously a software engineer, and did understand everything about the system, was able to review PRs, was able to really get down in the weeds, and therefore could go through all the tickets in the backlog, could even create all the technical tickets, and then perhaps he would come to you or a team member and be like “Okay, this is the technical approach we’re taking. Here are the tickets, please execute.” That for me – I’m obviously being very kind of “I would do this”, but to get that conversation going, that for me, even saying it now… I know a lot of people who wouldn’t be happy with that.

Yeah, at that point you’re not really doing – that’s not really product management anymore, right? That’s like team management, to some degree. You’re the one that’s setting up all of the work for everybody to do, and I would assume also like tracking to make sure people are doing things… So that’s like team plus project management, which is not what product management is about. But I think there’s roles you have to fill in every team; every team obviously needs engineers, but you also need someone to be the leader of the team, so that we can get consensus around everything that you’re doing, you need someone to keep track of whatever is going on to make sure that things aren’t getting lost, you have to have someone that is out there, setting the future, saying “Hey, this is where we wanna go, these are the things we want to build…”

So you can have one person that fulfills those things, you can have a couple of people that kind of shift between those things… But I think it’s very important to actually make the roles very clearly defined as to like what they are and what to expect… Because I think part of the problem we have probably as an industry is that we’re very bad at defining what these roles are, which I think explains why we have so many of these titles that all have the same letters in them. There’s product manager, project manager, technical project manager, technical product manager… All of these things, they’re all kind of operating in the same space, and we’re trying to use one thing to describe it; it’s like, okay, no, you’re doing some project management, and you’re doing some product management. That’s okay. One person can do both of those things, but we should call it like that. I think when you don’t do that, then it makes it hard for people.

So I think a) switch between teams, or move around teams, or move around companies, but it also just makes it very unclear when you start to scale how you actually scale the team… Because then if your team gets – you know, that might work for one product manager when you have a team of five people, but if you have a team of 10 or 15 people, that’s a whole lot more work to do for one person, and you’re like “Okay, we need to bring a second person in.” Finding someone that can do that mix of product and project management work is gonna be really difficult to do. And if you’ve already defined upfront, you’re like “Okay, well these are my project management responsibilities and these are my product management responsibilities” and you’re like “Okay, now it seems like there’s more project management that has to get done, so we’ll hire another project manager, and I can still do product and some of the project stuff.” So you can start that kind of dividing things out a little bit better.

But yeah, I think for me personally, I would not want to be on a team where a product manager is that heavily involved in the backlog, and that heavily involved in the process. I typically don’t like teams where the engineers don’t have a high degree of autonomy and a high degree of trust in them.

[27:59] So I think ultimately, the way I kind of see things is engineers should be trusted to prioritize work properly, they should be trusted to maintain the backlog. Because at the end of the day, you have a bunch of tickets, and let’s say that you wrote them all up; well, the engineers have to understand them. So it’s like now you have to spend all this time translating it for them. It’s easier if they just write them themselves, make sure they have the information so another team member could actually pick up that ticket and do it… And they have to own the responsibility of making sure that that information is sufficient for what other people need. So if the higher-ups need to be able to track what’s going on, the tickets need to have enough information to make that happen.

I think that’s much more scalable than trying to put that all into one person, and I’ve definitely seen it more scalable in teams like that. I think a lot of the teams I’ve been on, there’s just been like one person that’s trying to write up all of the tickets. The team manager takes the epic and then breaks it out into a bunch of stories, all under this thought process that like “Oh, well we just want the engineers to be writing code”, and I think that doesn’t help us in the long run.

Engineering is about more than just writing code. I think in the last podcast I said “Writing code is the least important part of software engineering.” There’s so many other things that we have to do, and if you don’t give the engineers the autonomy to do that, if you don’t give them the authority to do that, then they’re going to just not do it, and that’s gonna make it much more difficult to build software in the end.

So I think in general - it’s the long way of saying I think product managers need to be much higher up than that. I don’t think that they should really be doing that project management work, and I don’t think you should necessarily bring on a project manager until it’s like “Okay, no, we really have a team big enough that we need someone to manage everything, because it’s difficult for engineers to keep on top of all of it.”

So you would not be happy if I jumped on a PR and reviewed it.

I mean, you could, but I don’t know if that’s the best use of – that’s like half PM and half software engineering, which once again, if that’s a thing we have, then sure… But if this person is a product manager, that is their title, that is all they do, I’d be like “No, that person’s a product manager plus some level of engineer, because that’s what they’re doing, and we should call them that.” And then yeah, sure, 50% product, 50% engineer. Cool. I don’t have a problem with that.

Yeah. I think if the product manager were that hands-on, you would probably not be spending your time on other things that to me are the more fun things that are part of the role… But on the other hand, maybe your product is a product that is for other engineers at the company, and you’re trying to understand what is the experience, so maybe that’s why you’re doing a PR, to experience it yourself. Maybe in that case it’s appropriate.

But I think I would strike a balance. I think the engineers should be able to write their own tickets and determine what’s important to work on next, and the product person should also be writing some tickets. Everybody on the team who identifies a need for something that the team should be working on should be able to write a ticket… And yeah, I think we should all be expecting that things can change, but if something happens, if there’s an incident or some new customer need, or business has shifted in a dramatic way, maybe due to the pandemic or something else, we might need to be [unintelligible 00:31:08.00]

So yeah, I think that’s a collaborative exercise, and I don’t think it has to all be done by the product manager. I think the product manager can help shape maybe some of the [unintelligible 00:31:19.13] For example, one of the things I like to help make sure we’re doing, just for good team health, is to be really clear on the acceptance criteria, so we can all agree like “Okay, this work is done. Here’s the scope of it.” So that we can keep delivering. That’s one of my things; I like to make sure we have acceptance criteria and that we all understand what the acceptance criteria are.

I don’t like to be prescriptive about how we’re going to do something, especially not on the engineering side. I think that is way beyond what I should be doing, and that would not be appropriate.

[31:55] So I know we’ve touched on this a little bit, and it’s been mentioned a few times, in regard to external team management and dependencies. So a lot of our time as product managers is spent having meetings with people, understanding their needs, understanding what work is required from our team… I guess do we - either Gaëlle or Kris - see a world in which a senior software engineer, an engineering lead would take on that role? …if we got rid of the PM role within a team. Or do you feel like product managers have unique skillsets - and this is not a trick question - to be able to do that? Just because I know, Kris, you’ve talked about that being something you’d like the engineers to be thinking, around business value, being able to prioritize their work… So I’d love to hear your views on that.

Yeah, I think it depends on what the team is doing… Like internal products versus external products. I think in some cases, depending on the size of the company, an internal product manager makes sense, but I think for most companies you probably want the engineers to kind of be doing their own product and be capable of doing that sort of work… But I think in general, the thing that I’ve always found is like if you have good processes for your organization as a whole and you have good forms of communication, the need to have a human that’s kind of transiting information between people decreases a lot.

I always see it as kind of a failing of an organization even when a manager has to talk to another manager to transit some information, because then you’re going from some engineer that’s telling some manager, that’s telling another manager, that’s telling an engineer… It’s like, we all played telephone as a kid… That never worked well. That was the fun of the game; you’d be like “Oh, what weird thing is gonna come out the other end of the telephone line?” It’s completely not what I said.

So I think fixing those problems and reducing the friction of communication is super-important, and I think that can actually reduce the need for as many internal or cross-team product managers.

And then I think product managers really do get to go talk to the people who aren’t within the company and aren’t gonna adhere to the same sort of process and communication systems… Or just aren’t gonna be able to give enough feedback. If you are just building a product and you have some users, like actually sit down and talk to the users, do user studies, all that sort of stuff, they’re not just gonna kind of walk up and be like “Here’s everything I want you to build”, or be able to translate that into something useful for you internally.

So yeah, I think when it comes to cross-team communication, it’s not a good use of a product manager’s skillset to be doing that. Or really, it’s not a good use of anybody’s skillset to just be like transiting information between two humans. We’re all adults, we should all be able to talk and communicate with each other. That’s I guess where I fall on that.

Yeah, I think that if there’s maybe 5+ engineers on the team and only one of me, if I have to be involved in every single conversation that the engineers are going to have with another team, this is going to take forever. And then also, personally, I think the engineers are completely capable of talking to each other… So yeah, I would tend to agree that there’s no reason why we can’t go talk to other people and ask questions and find out information.

I think in terms of cross-team communication, where a product person can help is there’s this interesting art form, I believe, of sharing the plans of the team with another team, so you can set expectations. And I say art form because you don’t wanna over-promise, but also you wanna be setting expectations. I always try to strike a balance between telling teams like “Here’s what’s coming next”, but also potentially anticipating that things might change. So you have to be specific, but also a little bit vague at the same time; not reveal timelines too much…

[35:55] Sometimes I’ve had situations where sales gets really excited and they wanna try and go and sell something to the market, but it’s not ready yet, so this is why you wanna be careful about what you communicate, and do so in a way that’s useful to other teams, potentially will get other teams excited, and can help teams prepare for partnering with your team - that’s helpful conversations to have, and a product person can be strategic in “How do we wanna set up that conversation? What is important to share, versus what we could keep to ourselves for now as we’re continuing to do some work?” That is a little bit of stakeholder management that product can help do.

Right. I understand why we need to do that on a level, but I’m also just kind of like – I feel like that exposes some problems that we have, especially around telling people when we’ll be able to deliver something; that’s always been something that’s really irked me about the way that we do software engineering, because everybody’s always optimistic… They’re like “How long is it gonna take?” and you’re just like “I can do that in two days.” And it’s like, “You can’t do that in two weeks. Let’s be reasonable.”

[laughs]

Which is why also – I get back to the whole “We need better process.” We need better ways of describing how long something’s gonna take. Giving someone a “That’ll be done in two months” - that’s not reality. It might be two months, it might be two-and-a-half months… You have some amount of confidence that you have in how done it’ll be, by what time… There’s all of these risks; the thing might never happen, it might get canceled, we might have to delay it for other reasons. And I feel like we as an industry lack a lot of the language we need to actually express that well. We try to kind of everything down into story points or T-shirt sizes or what have you.

It’s unfortunate that we have to use someone’s skillset that could be used for communicating with people outside the organization to communicate inside the organization. That just seems like a failing of our organizations; that’s something that’s happening, and something we should address and be like “No. We’re all on the same team here. Sales, here’s what you can read to figure out if we’re actually gonna be able to meet something. And if you oversell it, that’s your problem, not ours. Don’t do that, please. That’s hurting other people within the organization.”

I mean, I feel that… I think what you said about “We’re all on the same team” I will say feels strongly. I would love it if that was the case, but often it’s not. Often it feels a little bit like six different cooks trying to make different dishes, and they all need the same ingredients, and they’re fighting over the ingredients… And then the product manager - the chef, in this analogy - has to advocate why they would use the tartar sauce better than this other person… But they’ll give the tartar sauce in a month(ish), as long as they finish their dish. I think, in my mind, that is part of the art of being a product manager. It’s being able to have a room filled with different kind of people trying to do different things, agree on an approach, and have them leave, whether it’s a meeting, it’s an email thread, Slack thread, feeling happy and feeling great. “I achieved something. I have got what I wanted. I’m gonna be able to do what I needed to do to fulfill my goals for the business” etc.

That for me is the reason why it’s difficult to not play this kind of game of giving enough information, but holding some back, framing it in the right way… Especially, I think when you are on a platform team, or a team who does predominantly backend work, and you are trying to advocate to a feature team, a frontend-facing team why you need six months to completely redo your backend infrastructure, change your database, migrate to a different cloud infrastructure… When they then said “Okay, well is that gonna enable us to do audio segmentation, personalization? How is that gonna add some value to our end users?” and you say “Well, it’s not really… It’s gonna make it more resilient, it’s gonna make our platform better, it’s gonna get rid of a lot of tech debt, useless code…”

[40:19] I think part of the art of a product manager is being able to put it in a way that has them go away going “Oh yeah, we really need to spend this six months doing this work. Oh yeah, this is gonna be great.” So I think there is a bit of an art there…

I do like to default to taking the approach “We’re on the same team”, but different teams do have different goals, and that introduces interesting tension, where some teams might be really driving growth for the company, and they might be testing and iterating really fast, and perhaps another team is developing foundational platform tools, and those really need to be resilient, so you might be a little bit more thoughtful and careful as you allow the change, because it could impact the entire company.

So I think having tensions between teams is okay, because ultimately, all teams are thinking about how they can benefit the company in the best way possible. They just have different ways of doing so, and that’s okay.

And then with regards to communication, I kind of try to take the approach of thinking about, you know, if I’m the other team, what is it that I need to know? And that’s what I prioritize telling teams… Like, you might be interested in knowing that we’re gonna deprecate this thing, and you’re gonna have to be able to be ready to migrate to a new thing. And it’ll be better, and it’ll allow you to do X, Y, Z… But just know – maybe you’re building on your application; you might wanna align your timeline with our timeline, because you could benefit and use a new thing in your new application.

So that’s what I do. I try to give the information that’s going to be the most useful… And maybe we weren’t ready to tell folks yet, but I know “Oh, this team - it would really help their roadmap. They wouldn’t have to do rework, and they wouldn’t lose effort if I tell them right now.”

So that’s kind of like my communication practice. I share what is going to be most useful. I don’t want teams to go off and spin their wheels and think about things too much. Maybe sometimes I don’t have enough to tell folks here, because we’re still doing discovery, trying to figure out what’s the best technical solution for something… So yeah, I might have to just forecast at a really high level “This thing is going away. I don’t know yet what’s the new thing, but we’re gonna make it better… [laughs] And just know that you may need to plan accordingly.” And that can be useful to teams.

So I just take the perspective of “We are working together. We’re trying to do the best that we can, and I may know some piece of information that might be useful to someone else.” Because I know a little bit about what they might be working on, and I’ve built that relationship and I’ve been kind of keeping track of what their roadmap might be, and I’ll be like “Okay, key stakeholder, here’s what I think you should know… And hopefully it’s helpful to you.” And then maybe they’ll reciprocate and tell us “Hey, we’ve been exploring this really important new feature we wanna launch to our customers. We think we might need you to update something.” Maybe a new API endpoint might need to be surfaced. It’s helpful for me if I know about it as early as possible.

And maybe they’re still doing some customer research right now, but they’re getting positive feedback, so I can start to know “Okay, this might come up in the future. Maybe I should start having some preliminary conversations on my end.”

So I feel like there’s always benefits. If I share a little bit, folks might share with me, and then I can anticipate better… So yeah, it’s all towards this grander vision of working better.

[43:50] Although I do wonder – I guess if we’re on that level, it’s like, I understand the need for this now, but I also feel like this is just not a productive way for us to be working. I guess for an industry that prides itself so much on innovation and doing all of this amazing stuff, it’s like, we should be able to sit down and like – if we’re all in the same company, we’re all trying to achieve the same goal, our leaders really should be sitting down and figuring out and talking to each other and being like “Yeah, there are teams that need to move fast and iterate quickly, and there are other teams that need to move slowly, and we need to prioritize both of those teams and figure out ways that they can all work together without having to play hide’n see with information.

I guess in my career I’ve always kind of looked at that need to hide or that need to “Oh, well we won’t tell them what we’re really doing” or “We’ll deliver that thing later”, or just being overly optimistic and saying “Oh, we won’t need that feature, or we won’t need that thing.” I feel like that’s ultimately what kind of trickles down and leads to us burning out our engineers, or leading to situations where people are pulling 70-80 hour weeks for months at a time because we just weren’t able to plan things out well, because we’re not really projecting and looking far enough in the future.

Whenever I hear that some platform team is having trouble justifying why they need to do what they do, I’m like, that’s a failing of the entire company. If the organization doesn’t understand why your foundation needs to be taken care of, it’s kind of like “Oh, I don’t see why we need to have heating and cooling in our office, and running water.” Like, “We don’t need to have running water on the weekends. We should just turn it off on the weekends. We should just turn off the HVAC system on the weekend. So it’ll be fine to turn it on Monday morning, and then everybody’s sitting in an 80 degree office, or like an 85 degree office, that has 80% humidity and everybody’s miserable.” It’s like, no, you have to plan things out into the future. Everything can’t be instantaneous. There’s lead times for things. That’s especially true for anything that’s like big and platformy; these things take multiple years to build, and multiple years to build well. You can’t just look at it as building everything in two-week sprints, or whatever.

So I think if the organization doesn’t understand that, that’s like an organizational level that needs to be solved, which is like - some organizations just don’t care. And in that case, I think product managers can fill that useful void with their skillset. But also, that seems to me to be like a miserable environment to be working in. I guess it depends on how you value your job at the end of the day. If you’re just like “I just wanna go in and do some work” and I don’t care as much about the whole thing, it’s just like I wanna do a job, I derive happiness from other things in my life - I think people like that would probably thrive in these environments. But I think if you’re like “No, I really deeply care about this, and everything around me”, I just imagine it’s gotta be a frustrating space to live within, or exist within, of just like fighting this uphill battle and having people just not really understand or not really feel like everybody is on the same team.

Break: [46:45]

This is completely just off the top of my head, a thought, but do you feel like some of these struggles are rooted in these companies that are not technology-first companies, who then try to make the move to being technology-first, digital-first companies, and therefore kind of try to hire hundreds of engineers, build out their technical org without really taking the time to ensure the engineering work cycle, the way that we work in technology is optimized, is ideal? This is completely off the top of my head, but I personally feel like I’ve talked to a lot of people who have said, as product managers or as engineers, they’ve struggled when the org has grown substantively; they’ve suddenly said “Technology is first. Engineers are our most important employees”, but haven’t optimized for “How do we work with all these engineers? How do they work together most effectively?”

Yeah, originally I was gonna say that my experience has been kind of the opposite, where it’s like the organizations that are very, like, from the beginning software engineering organizations or whatever - those are the ones I think have the worst problems when it comes to this sort of stuff… But in general, it depends very much on what kind of operating system – not like in OS, but how the organization and company as a whole operates… Because I think organizations that tend to have fewer problems are likely those that already have a practice of implementing processes and having processes for moving information around and having all those nice checklists that are like “Hey, do you wanna do a project? Here’s all the stuff you’ve gotta do.” I think when you have those types of organizations, they’re already primed to scale, so it’s not as big of a problem for them…

But yeah, I think if you just try and throw a bunch of engineers at a problem and say like “Hey, we’re technology-first now. Go build a bunch of stuff”, I think that’s honestly why a lot of these fiefdoms and a lot of these positions that the skillsets people have could be better used elsewhere wind up in this, because no one planned it, no one thought it through, and no one said “Hey, things are a little funky here. Let’s stop and revisit and go back and fix things up.”

At the end of the day, what I’ve really been trying to say here is just like, I think product managers are incredibly talented people, and I think that their skillsets are very much wasted shuffling information between teams, and playing strategic hide’n sees with information between groups of people that have no reason to have adversarial relationships.

Yeah. To add to that, I feel like product is an interesting balance between strategy and execution, because you can strategize as much as you want, but at the end of the day if you don’t help the team get something accomplished, then it was a bad strategy, or it was a poorly executed strategy. So the product manager does have a role to play in ensuring that we’re successful as a team and as an organization… And I guess in terms of like sharing information, my personal take on this is to overshare, and share a lot, and be as transparent as possible.

Actually - Angelica knows this - I like to send out newsletters… [laughs] I’m really big on newsletters, and keeping – anyone who might be interested can subscribe and get the information and hear what we were up to most recently. If you’re not interested, if it’s too much noise for you and it’s taking focus away from your day-to-day work, then you don’t have to subscribe to the newsletter and you don’t need to know. If you do need to know, I’m gonna make sure to reach out to you and be like “Hey, you might care to know this will be happening and it’ll impact you, and you should be thinking about it. Please let me know if I can help you in any way.”

[52:20] But yeah, in terms of information sharing, I think sharing information is really important and it helps folks do what they need to do. I also agree to what you were saying in terms of having good processes, like an operating system. I think that’s true, that that helps organizations be well set up for success when we have good practices in place. Some of the things that I’ve enjoyed at The New York Times is that there are some rituals, for example when engineers are working on a big, new initiative typically they’ll write what we call an RFC (request for comments), and it’ll detail everything that the team’s been thinking about, and then it’ll be sent out to the entire organization, and folks can have a chance to submit comments on what’s proposed.

This is a really interesting way to build knowledge across teams, because you can kind of get some information about what’s the problem that a team is looking to solve, how they thought about potentially solving it, and then other teams have a chance to push back on certain proposed ideas, and help improve.

Or, if you don’t have time or you don’t care, you don’t have to submit comments, but it’s open to anyone. And that’s really interesting, because I’ve heard about projects from other teams by just seeing what was the latest RFC that was published. So I agree, having good processes can really help an organization.

So we’ve spent a lot of this time talking about big companies, and operating within this big business model… But I wanna ask both of you - if you were starting a startup… Just you, you have this great idea. Do you need a product manager? Is that gonna be one of your first employees?

Maybe not, I would say… [laughs] Maybe this is controversial. It depends on what the startup is doing. I think – yeah, it depends on what it is that you’re doing. I’m thinking some of the earlier folks might need to be actually building things. That might be one of the most important skillsets to have at first. And in my mind - we’ve touched on this; there’s really no reason why folks can’t go and ask people questions. If it’s your potential customer, try to show them a prototype, be like “What do you think of this?” and learn from the feedback. I think anyone can do that, and it doesn’t necessarily have to be a product manager… But I think the product manager later on can become really valuable, because they can go really deep with the user research. [unintelligible 00:54:49.27]

Okay.

But earlier on, I think you might need different skillsets.

Okay, so you’ll be with the “A product manager is only really effective when you have a larger existing product” - is that semi-accurate?

Yeah, I think so. I have not been a part of a startup so that’s the disclaimer, but…

Fair enough… I’m just wondering.

But yeah, I’m thinking a startup is looking to move fast, and as a smaller team probably I think the team can be closer to the customer. You may have less of a need for having really detailed product requirements and conducting industry research and looking at more of the financials… It depends. Maybe it is helpful to have a product manager that can do some of that work. Maybe, you know, it’s step two.

[55:47] See, I disagree… I think you don’t necessarily need to have a product manager, but you definitely need someone who can do that product thinking. Because my view is you’re gonna launch the startup, and if it’s gonna be successful, you need to know that that’s actually a need, you need to know those user needs, you need to know what is gonna get that kind of financial backing, you need to go pitch your product, you need to tell people why it’s important to get angel funding or whatever you need to get that thing off the ground…

I think for me you do need a product manager from day one, more so than established, larger companies. Kris? Thoughts?

I’m just gonna say flat out no, because a) I think that people that start the company should – like, I think that the best people to start companies are people that are building products for themselves. I think it’s not a great idea to try and go build a product for somebody else, or a product that you don’t understand or don’t have that – because it’s gonna be slower; you’re gonna be way slower than someone that knows that need… So in that way, I don’t think you need a dedicated product person, because I think that – at least initially, the founders, at least one of the founders, has to be the person that can do that product work… And I also think that you really need to hire engineers that can do product-like work.

I think the problem with trying to bring in a product manager at a small company, or just when you’re starting, is that that means that there’s some extra translation that you’re doing, to someone who doesn’t understand product. If you have someone separate that’s doing product, that means that there are people within the organization that can’t do that work themselves, or otherwise you wouldn’t need them. So either your founders don’t understand, or your engineers don’t understand… And in that case, if you’re a team of five or six people, why have someone that doesn’t understand what you’re building? Why have someone that’s not gonna be able to contribute to actually being able to kind of carry more of the weight?

I think one of the luxuries of being in a larger organization is you don’t have to carry as much. You don’t have to be the person that does both engineering and product work. You can just be someone that picks up tickets, does them and goes home at the end of the day. But I think in the smaller companies that’s not really the environment for that type of thinking or that type of work, and I think that could really lead to some of the bloat that smaller companies start to get, because they’re just like [unintelligible 00:58:20.17] But then they don’t really understand what we’re trying to build, so half the tickets are wrong, and we’re just doing all this work that we didn’t need to do.

So I think there are probably many other roles that are even more important that I don’t expect founders to be able to do… Things like culture-shaping, hiring a D&I officer from the beginning… I think that’s super-important, because I think a lot of people that start organizations - they know products they wanna build. They might have sales experience, they might have engineering experience… Unless you’re building a product that’s targeting diversity inclusion, you probably don’t have that sort of experience… Unless you’re targeting a product that’s meant to build cultures you probably don’t have that sort of experience.

So I would say don’t get a product person as one of your first people, because you should have some of that skills yourself if you’re gonna go on this endeavor. Hire someone that’s gonna add something substantial. If you wanna start a company, you’ve gotta get a lawyer, you’ve gotta get an accountant… I think there’s these fundamental roles that you really need to feel, and I think that product can come later on down the road. I think that’s something that can fill in, and also, you probably wanna build it when you can actually build out a whole product organization, not just like one person’s way of doing things, and whatnot. So I think it’s something that’s just like later on down the road. There’s both other roles we can fill, and this is a role that basically everybody should share in the beginning.

And there I was, thinking you and me, Kris - I could be a product, I could do all the business strategy, you could build the beautiful backend… Dream shattered.

I mean, you’re an engineer, too. You can write code… If we want to start a company, we could start a company.

You heard it here first…

We’re both doing multiple things…

…me and Kris starting an amazing company… [laughter]

[01:00:15.23] You don’t even have to hire a DEI person, because I can do DEI, so…

Oh, my gosh… And I’ll do project, I’ll do frontend engineering, I’ll do some Flutter work… I’m so ready. I’ll do some security… I’m so ready. [laughs] Awesome. Well, we are coming to time… Thank you so, so much for joining us for this fun discussion. But I’m not gonna let you go yet, because we’re gonna be diving into my favorite section, Unpopular Opinions.

Jingle: [01:00:45.20] to [01:01:04.21]

Awesome. So I’m gonna go to you first, Gaëlle… What is your unpopular opinion?

I guess my unpopular opinion is that cereal should be eaten with orange juice, not milk. That’s the better way to eat your cereal. And I have gotten some feedback that not everybody agrees with that… But that’s the way I eat my cereal. I’ve always done it that way, and I’m going to continue doing it that way, and I think it’s delicious.

Do you have a preferred brand? Is it Tropicana, is it freshly squeezed? Is there a preference?

Yeah, I typically use Tropicana, but freshly squeezed brings it to the next level. I just don’t always have oranges or the time to do that… [laughs]

Okay… I’m not quite sure what to say to that.

I conceptually understand. Milk seems like this random thing that we put in cereal… What you want is some liquid to go with your cereal, so it’s like – I would hope people switch from cows milk, to goat milk, to oat milk… It’s like, why not orange juice? It’s basically just like orange milk, so yeah. We’ll call it that.

There you go. It’s more happy-looking… You start your day off in a bright note, lots of happiness…

I feel like I’d just go crazy.

What’s not to like?

I don’t think anyone would like me after a really sugary cereal, and then naturally sugary orange juice. I’d be going into stand-up like “HEEEEEY !!!”

I mean, I think some folks do need a bit of extra [unintelligible 01:02:45.15] in the morning, and here you go. You could just have your cereal with orange juice.

I feel like it wouldn’t be weird if someone was just like “Yeah, I have cereal without milk, and then I have a glass of orange juice.” That doesn’t seem weird to me at all. It’s just like, I don’t know, maybe you’re eating some Frosted Mini Wheats, or something… You’re just like eating them with your hands, you have a glass of orange juice that you’re also drinking… That doesn’t seem weird to me, so it’s like, just pouring the orange juice into the bowl, that doesn’t seem – I see where you’re coming from. I see where you’re coming from.

It all ends up in your tummy in the end… I think I might have to try this tomorrow.

Yeah, but the experience of eating food is like – it’s a special thing. We don’t blend all of our food together. Most of us don’t blend all of our food together.

That’s what I do. I just get my dinner, shove it into my blender, give it a good buzz, and… Done. [laughter] Thank you so much. I’m not sure whether that will be unpopular or not. As always, the view was given, and then Kris rationalizes it, and it becomes no longer unpopular…

[laughs]

Do you have a truly unpopular opinion, Kris?

Hm… Let me think. I’ll just make something up. Something I’ve been thinking about that’s awkward.

[01:04:08.05] “I secretly love product managers and think they’re essential at any startup…” [laughter]

That sounds like it could actually be popular. That’s not good. I guess this one’s like super-nuanced, so it’s not even gonna be one that lands heavily… But I think that we should stop trying to use academic terms in the general populous to explain things.

Okay.

The main thing that I’m thinking about right now is the word privilege. I think that we should find words that are less prone to people immediately misunderstanding them, because they’re not coming from a kind of academic or semantic understanding of the word. I think we should find words that people can grapple with more, because what we’re trying to get across is a concept, not the word. And also, I don’t like it when people are just like “Check your privilege!” I know what you’re trying to say, but… So yeah, I think that’s it. Don’t just spew academic terms into the general populous as if they work when it’s stripped of all of its nuance.

Yeah, bringing in those laymen terms… Which actually applies to our topic of the podcast, in that - I don’t know about you, Gaëlle, but when I got into product management, the amount of business terms, random phrases, academic language that I had no idea what it was until I asked… And then I was like “Oh… Why don’t you just say it’s XYZ, which is so much easier to understand?”

Yes… I think I can get behind that. On the other hand, sometimes I think there’s words that are very specific and are useful, because they really get at the thing we’re trying to talk about… But yes, I think laymen’s terms can help more folks be a part of the conversation and also talk about the same thing… And that’s more valuable, being able to exchange ideas in a productive way, because we’re talking about the same thing.

Yeah, for sure.

I will say though, I think there’s a lot of acronyms and things in engineering, really specific words in engineering that I had to learn so that I can [unintelligible 01:06:20.18] as a product manager… So it goes both ways. Not just business talk, also lots of engineering nuance.

Those acronyms kill me. It’s like, “I’m a PM.” Is that a product manager, a project manager, a project manager? Are you a TPM, a PPM, an APM? Like, so many…

Hot take - acronyms are terrible. We should stop using them. Also, hot take, I know they’re initialisms, not acronyms, but we’re just gonna call them acronyms anyway.

Sigh… [laughter] Okay, awesome.

There are too many of them.

There are too many.

We have [unintelligible 01:06:58.00] I think that we also tend to use these academic things as like showing that you’re in the in-club. It’s like “Oh, you know what CAP is. You know what the CAP theorem is. You’re special.” And “Oh, you know the different levels of strong consistency? Oh, you’re super-special. We like you.” And it’s like, “Can’t you just make these so that it’s easier to understand?” You’ve gotta make up a word like linearizability? Like, no one knows how to spell that. Linear-izabi – what? No. Absolutely not.

Do we feel like using letters is – oh, sorry, what did you say, Kris? What was the right way? I can’t say acronym.

Oh, linearizability, or CAP?

No, previously. If I’m talking about acronyms, you said that we should call them something else.

Oh, initialisms.

Initialisms. That thing. Are they okay in technology to refer to specific technologies? Like GCP, AKS, AWS. Should we get rid of those?

I mean, we’re never gonna get rid of them…

Because if someone said to me in my first week as a product manager like “What is GCP?” I’d be like “I don’t know… Go Product Software?”

[01:08:06.02] I mean, I would prefer people just had boring names for things. Google’s Cloud - they have boring names for all of their stuff, whereas Amazon is just like… What’s that thing that was the meme on Twitter? AWS… I don’t remember what it was, but there was this thing that was like “That sounds like a perfectly legitimate Amazon product”, but it was just like massive ****post on Twitter of just like “I could just make up something.” And then it was a thing that people were talking about.

So if you are going to use fancy language, at least make it plain and simple and boring. Amazon is getting a little too overboard with their product names. They started out simple. I prefer EC2 and S3 to Aurora… Like, what does that have to do with databases?

I’m on the bandwagon for boring names. Clear, simple, boring names so we all know what’s happening.

So Kris, our startup - it’s called Bob. [laughter]

Just Bob.

Thank you so, so much for joining us. It was a pleasure having this chat. I wish we could talk more. I’ve had a million and two brainwaves of different things I wanna chat about with you both, which I probably will… Look out for a coffee invite… Unfortunately, we’re gonna have to go. Thank you all, thank you all who listened, thank you to all those who are listening live, in a week, in a month, in a year… This has been Go Time.