Plaid's product management discipline in platform teams

Abi: Russ, thanks so much for coming on the show today. Excited to sit down with you and chat.

Russ: I’m super happy to be here. I’m a big fan of the podcast. The folks that you’ve had on thus far are all people I look up to one way or another. Really value their opinions. And so, that I could even be included in that collection of platform engineering and engineering enablement luminaries is pretty sweet.

‍Abi: Well, thanks for saying that and grateful to have you as well. You recently joined Plaid as a product lead for the tech foundations and data platform team. Would love for you to just share the current snapshot of your role there, what you’re seeing, and what it is you’re trying to do at Plaid?

Russ: I started at Plaid not too long ago, a little over seven months ago, and I was hired as the product lead for the Developer Foundations team. Plaid is a super successful company working in a great space. And as the company’s grown, so has the platform team and their investments. The leadership team there is definitely forward-thinking and has adopted this product-led approach to developing products, and they’ve started to apply that to their platform team as well. And so, that’s what I’m there to help out with.

I had a similar experience at Twilio prior to Plaid, but the way I talk about product to people at Plaid, just generally is … I picked this up from one of the PMs at Heroku. We’re a heat-seeking missile for value. And so, I’m here to help the platform team at Plaid identify the most valuable things to work on. That’s a broad subject, but we can go into that as deep as you want. At the end of the day, that’s what I’m at Plaid to do.

‍Abi: I love that analogy of being a heat-seeking missile for value. It’s awesome to hear you’re trying to help introduce the product management discipline at Plaid. First, I want to just call out that one of the reasons we’re so excited to have you on this show is that, in my view, platform product managers are a little bit of a rare breed in our industry as a whole. First off, would you agree with that?

Russ: Definitely agree. They are a rare breed. Just anecdotally, when I introduce myself as a product manager in a platform, they’re like, “That’s interesting.” Not something folks are accustomed to seeing. But I think that’s changing. Just again, anecdotally based on the number of folks reaching out to me and just being on LinkedIn and seeing the posts. I’m excited to see that.

Abi: In your experience … I want to go into your personal background next, but just broadly speaking, what kind of people do you see moving into platform PM roles? What kinds of people do you see having the most success? What kinds of people should organizations be looking at recruiting, internally potentially, into these types of roles?

Russ: That’s a great question. I don’t love to generalize in this area, but I will. Because there are certain patterns that I’ve seen that are successful. What I want to say is, I don’t think typically speaking you see a product manager come from a non-platform or engineering background.

The folks that I’ve seen have the most success are people that have either operated as an engineer previously in their career or in engineering management, but one way or another are really passionate about the platform space in general. They’ve seen up close and personal the impact of working on platform products and services.

Abi: I would agree with that having seen people like you. Again, we’ll go into your background in a minute, but lots of former engineers or technical product managers bridging into becoming platform PMs. I asked you that question though … It did pop into my mind that one of the counter-arguments against having platform PMs is that a lot of organizations just have their lead engineers or engineering managers essentially responsible for the heat-seeking missile type work and the PM work.

What are the pros and cons of that approach? What are the limitations of putting that responsibility on just your engineers or EMs?

Russ: I think ultimately it’s a scaling question. Another way to get super direct about the question is, “Do we need product managers on a platform team?” My first answer is, no, you don’t really need product managers on a platform team. At least or however from the start. If you’re a small team, I don’t know that that’s where I would invest in headcount is putting a product manager there.

However, as the organization grows, you start to see specialization. This isn’t limited just to product managers and platform. You start to see data scientists. We start to see SREs come on. We do see product designers, we see tech writers, and I think product management and platform is just an evolution of that.

And so, the downside to once you reach a certain size is that you’re not making the most effective use of your engineers or your engineering manager’s time by having them pursue what is really a dedicated discipline of product management. And so, if you’re at that size, you might as well start to see the benefits from somebody that really thinks about that space deeply.

Abi: As you’ve talked to other engineering leaders and platform across the industry, what are the biggest arguments against ever having platform PMs? Like you said, it’s sort of a specialization. You can maybe get away with not having them.

There is that argument of maybe not having them at all. Where do you draw the line? How would you help a leader make a decision as to when is the right time? Or if they should move forward with that?

Russ: I think there’s two things there, “Why not,” and, “Why should we have?” One of the arguments I’ve heard is ironically on this podcast. I think it was with Will Larson who said it’s difficult to find platform PMs. And a lot of times, if you do find one, they might be interested in pursuing more typical customer-facing product work. And I think that’s there.

I’ve seen that pattern before, where I have hired an internal platform product manager and they have expressed interest in doing it. I’ve supported that. That said, I do see, once you start to see some of the value that’s associated with internal platform work and the force multiplication factor there, folks do get excited about it, PMs do want to specialize in that, and that’s where they’re comfortable.

In terms of trying to find a concrete litmus test for when you might want to add a product manager … Maybe I’d come back even to another conversation that was on this podcast, which was like, “What’s a reasonable percentage of your engineering capacity that should be put toward platform investments? What percentage of your staff should be working on the platform?”

If you’re really grappling with those sorts of questions, to me, that might be a sign that you could benefit from having a product manager or product management team come in and help better rationalize or otherwise quantify the value that the platform organization will be providing to the rest of the business.

The alternative there is you find an understaffed platform team. Maybe you’re not putting enough, I don’t know, investment in security or reliability and that sort of thing. A product manager … My opinion is they can really help out with that and lend some more firepower to making those arguments. And frankly, benefiting the business, which is what we’re all here to do.

‍Abi: I think that’s a really great insight. I love the idea of, if you’re not sure about what your platform investment should be, or not sure how much you’re getting out of it … If there’s a lack of articulation of clear value and strategy around your platform work, then that might, in and of itself, be a sign that there’s an opportunity to bring in product management to help define and convey that strategy to the business.

Absolutely agree with that. Because you are such a rare breed though, I want to ask you, how did you personally end up becoming a platform PM?

Russ: That is an excellent question. I never had any aspirations to be a product manager. Let alone a platform product manager. Just a real quick background on me is I started my career right at the cusp of the dot com implosion. I was working for a small fantasy sports startup. It kind of went downhill. I was doing basically support stuff. And then, I went and I started working at National Geographic. The magazine and the channel.

They had a Unix team there and I was like, “These are my people. I want to be a Unix admin.” And so, I spent more and more time on that. There was this hobbyist operating system, which most of us are familiar with called Linux. I started really spending a ton of time learning a lot about Linux, and there was a scientist there doing tornado modeling on Linux. I was asked to work on that. Anyway, got really passionate about that space. And then, eventually got into working a little bit in the Usenet and CDN industry for a public cloud provider. Then, another public cloud provider.

Then, I started working for Twilio. When I’m at Twilio, I was actually hired to be the manager of cloud operations, and that pretty quickly transitioned into a role where I was working with a platform team that was responsible for building out the operating system images that we use at Twilio. We have that immutable infrastructure pattern, where all the binaries were put in place in this AMI image.

Anyhow, there was an adjacent platform team and they had a product manager join them. Twilio is very much a product-led company, very focused on serving our developers, that sort of thing. Since the platform is ultimately a vessel for serving our internal developers, somebody decided, I’m not even sure who, that we should bring a PM into the organization.

That team that had that PM in the platform org so far outpaced the other platform teams, with respect to delivering value to the organization, I became totally enamored with the idea. It was just so cool to see. I went in somewhat blindly, where I was like, “I could do that. I get to figure out what are the most important things to work on. I’ll just really champion those things.” But I just went in headfirst and really invested a bunch of time in that.

And then, slowly but surely, I got into a spot when I left Twilio as the director of product for their internal developer platform. At my heart, I still consider myself to be an engineer. Sometimes that’s where I like to spend my free time. On the weekends, I’ll write code, et cetera, but I really feel strongly about the product position within platform.

Abi: I want to ask you about something you brought up. You referenced Will Larson’s point on an earlier podcast episode about how it can be difficult to recruit PMs or retain PMs in platform, because there are often potentially more impactful problems PMs could be working on the customer-facing side of the business.

I’m curious. As someone who’s now been in a platform PM role for several years, what are your thoughts on that? Have you considered moving out of platform into other types of PM work? Or do you see being a platform PM as its own career path or function?

Russ: Personally, I haven’t considered going out of a platform product position. I think I’ll always be in an internal platform role, whether that’s as a product manager or otherwise. But I will say, there’s some nuance there, where there are externally-facing products that consumers are using that are in that platform space. Cloud platforms like AWS and GCP come to mind immediately and there is some overlap. And so, I have seen people make that move in between.

However, for me personally, I’m pretty much in love with the platform space, which gets to the first part of your question around, “Is there more value to deliver externally?” I don’t know. I have to think about that, but I don’t know if I completely agree with the premise there. Because I really believe in the leverage that a great platform team can provide by removing the responsibility for undifferentiated work from those customer-facing product teams.

We can talk about what I mean by that, but if every team’s having to figure out how to build software or secure software or deploy software, I see that as energy wasted. That time that could otherwise have been spent by those product teams investing in the customer-facing product. Again, that gets back to what we were talking about earlier with the scale of the organization. If you’re in a place like Twilio, where you’ve got 100-plus product teams, there’s a lot of value in figuring out how to get your platform right.

Abi: I definitely agree with that point. I don’t know if you heard the previous episode with Ryan Atkins at Asana. He actually talked about how he quantified the potential leverage and impact his org could have on the business. If you just take a small percentage of productivity or efficiency increase and multiply that by your headcount, you usually get a pretty big number that’s pretty significant even compared to revenue gains that other product teams may be delivering.

On that note, I do want to ask you … I’ve also been a product manager before. Of course, in any large tech organization, the way you move upward in your career is through demonstrating big impact on the business and on the business metrics. ARR, MPS, MAUs. As a platform PM, how have you navigated that? Especially, when you’re competing against other customer-facing PMs in the performance review cycle, for example. How have you navigated articulating the impact that you have on the business?

Russ: I love this question. I think as a platform PM … Even if you’re not a PM, but you’re on the platform team in general. One of the most important things you can do is what I described as capturing the currency of the platform. What are the units that you operate within? I think the DORA stuff is a fantastic place to start.

When we’re talking about lead time for change, deployment frequency, et cetera. Change failure rate. Those things. Because of the great research that has been done in that area, we know that that’s statistically predictive of positive business outcomes. That’s a huge shoulder or shoulders to stand on. But then, there’s also just the cost of the platform like the AWS bills. But then, I think the really important thing to capture there is, “What’s the most expensive expenditure for the business?”

In most cases, it’s the employees and the engineering team. Can we start to think about the fully-loaded cost of an engineer? How much value does that fully-loaded cost get us per engineer? With respect to some of those other metrics I was talking about. Anyway, with some assembly of those different metrics and dimensions, you can start to make, I feel, a pretty sound case for how you’re delivering impact as a platform team.

Abi: If you were to, not even at Plaid, but join some fictional organization out there as their new platform product leader … Say, 500 engineers. What’s a dollar figure? Do you think you can get 20% more ROI per engineer per that fully-loaded cost? What do you see as the opportunity big picture for these gains?

Russ: Obviously, it’s going to depend on the business, the engineering team, and where they’re at. I can’t say a specific percentage, but what I can say is, through those metrics I described, you can start to come up with projections there. There’s estimates that you can start to put in place with respect to, “If we get this right, we’ll see some fewer number of incidents.”

Or we’ll start to see higher rate of ships. We’ll start to see the number of new product features going out at a quicker clip than you otherwise would have. But you’re not going to get to … I haven’t seen it. You’re not going to get to that P&L-type holy grail statement.

You can do that in some areas. A big thing right now is obviously controlling cloud costs. And so, you can start to say, “We’re going to reduce the amount of cloud costs,” but that’s slightly different than the amount of value delivered. Except for when you start to put it in a little bit more abstract terms of new features you’re going to ship or the acceleration of the product teams.

Abi: Got it. That makes sense. Well, this has been an awesome conversation about platform product management in general, how you got there, and some of the advice you’ve shared around how to navigate career success and team success as a platform PM.

I want to bring it back to the current state at Plaid, and more broadly, what you’re seeing on the ground as you enter a new organization. What do you see as the biggest gaps that can be filled at Plaid? Or more broadly speaking, at any organization in a similar situation. What do you see as the biggest opportunities for introducing that product management discipline?

Russ: I think it’s getting crisp about the value that the platform team is providing to the rest of the business, and ultimately, helping better prioritize what work the team should be pursuing. There’s a great book out there called The Build Trap by Melissa Perri.

She kind of describes the alternative, which is you get in this pattern of getting really good at executing, but you’re just building things for the sake of building things and you’re using the number of outputs produced as your definition of success.

I think if you can get into this pattern of operating more from a platform as a product perspective, you can get into a situation where you’ll have higher confidence, higher conviction that the things that your platform team is pursuing are the things that are most valuable to the business and its broader goals.

Abi: As you mentioned earlier, one of the opportunities you see is getting crisp on the value and on the priorities. It reminded me of a couple of other conversations I’ve recently had, one of which was with a leader who discussed a platform team that was recently laid off by their organization. Partly, due to a lack of clear articulation of value.

I want to ask … Not really discuss layoffs and things like that. But earlier, we talked about, “What are the signs that it might be the right time to bring in product management?” But conversely, what are maybe the symptoms that you might see in an organization that the organization has a need for product management to come in and more clearly articulate value or direction?

For example, do you see people questioning the value of the platform as a whole? Is that a good symptom? Are teams upset or resentful towards the platform teams, because they don’t know what the platform teams are doing at all? Or they believe they’re working on the right things? Curious what your perspective or experience is on this.

Russ: I think those are both great examples of … You called them good signs. I don’t know if they’re good or bad. They might be bad symptoms. But I think those are both things that are worth looking at. But as product managers, the thing that we task ourselves with is answering the question of, “Why?” Why are we working on the things that we’re working on? And so, if you find yourself having difficulty answering that question of, “Why,” that might be something to consider with respect to bringing on a product team.

Just to dig a little bit deeper in there. When I say, “Why,” it shouldn’t be, “Somebody asked us for this thing.” Or, “This is what we’re expected to do.” It should be, “Why is this work that the platform team is pursuing, why is that critical for us achieving our objectives as a business more holistically?” Why do we need them to be building out this or that thing to make consumer-facing product X, Y, Z successful?

If you can’t articulate that, you might want to think about bringing in some product folks. Or otherwise, at least brushing up on the product discipline as a whole. Getting back to that earlier point of, “Hey. Maybe you don’t need a product manager right now given the size of your company.” But if not, I think there might be a benefit to at least applying product thinking.

Abi: I love that point and 100% agree. I was laughing in my head as you mentioned that. Because I work with a lot of platform teams and meet with a lot of platform leaders. I was asking myself what percentage of those teams could actually answer that question you posed. What percentage of teams could actually clearly articulate what is the value that their team is bringing to the business in service of the business’s goals, and which goals?

I’m curious. You’ve seen other teams. What percentage of teams would you guess are able to articulate that question? Even at Twilio, would you say that most teams really could? Or was it an ongoing work in progress to define that?

Russ: I think it’s certainly an ongoing work in progress. Twilio was an interesting company in that they were really focused on being product-led. It was just in the DNA. I know that there’s other companies out there. I’ve talked with platform PMs at Spotify. I asked the question of, “How do you all know that you need PMs on your teams?” They looked at me puzzled like, “That’s just how we operate. What do you mean?” I was like, “Huh?”

To answer your question directly, I don’t exactly know. But I definitely have encountered, even at Twilio and other places, pockets where I think folks are caught up in the day-to-day weeds of, “Here’s my Jira backlog. Here are the things that I’m supposed to execute on. This person requested this or that from the team. We’re going to deliver on that thing.” But I don’t think they can come back to say, “Hey. This revenue-producing product needs my support to be successful.”

Abi: Can you share maybe a fictional example of a really good … I don’t want to call it a mission statement. More a strategy statement, let’s call it. Or answer to the question of, “Why?” Can you share a fictional example, almost like a template, for people listening to this to help them come up with their own?

Russ: I think it’s something related to … Different businesses are operating at a point where they need to focus more on innovation or stability. You’ll hear this classically described as a Horizon 1, or Horizon 2, or Horizon 3 product. I think your mission as a platform team is to find the appropriate balance of platform tooling to enable the business to succeed wherever they are within that product lifecycle.

If you’re just early on trying to find product-market fit and you need to ship things quickly, then your platform team should be building something out to support that. If you’ve got a more stable business in place, where your customers value the resiliency of the platform, then you should start putting in place platform tooling to serve that need.

And so, I know that’s not a neat statement, but the idea there is, “Can your platform find homeostasis with respect to where your business is within its broader lifecycle and in the portfolio of products it has?”

‍Abi: I love that and love the emphasis on … Basically, you said it depends. And it depends first on understanding the context, where the business is at, and what’s important to the business. My version of this, the advice I share with platform leaders is a little more of a blunt way to put it.

I say, “What is keeping the C-suite up at night? What are they worried about? What are they most focused on for the business? What are they losing sleep over?” Those are the things that you should probably align your platform work to. Those are the things you want to solve or accelerate or enable. That’s my version. What do you think of that?

Russ: Absolutely. Definitely. I think that’s something that product within your platform can really help with is making sure that there’s that conduit from what the business is trying to achieve broadly, with all the work that you’re doing on the ground floor in the platform space.

I’ll just use that as an opportunity to harp on something, which is I think a lot of times I hear within platform teams … I even do this myself, just for shorthand, but we will talk about our internal users as our customers. We’ll say, “Hey. Team X, Y, or Z. They need help with standing up a new Kubernetes cluster or something like that.”

I’ve even been in meetings where I’ve been talking with users on different externally-facing product teams and they’ve said to me, “Hey. You need to listen to us, because we’re your customer.” What I say to them is, “You’re not my customer. You’re my partner. We both have the same customer.” The customer is the people that are paying us money for the products we’re delivering as a company.

I want to make sure that I’m providing you with the right tools and capabilities to make sure that we are successful delivering a solid product that our customers want and need. And so, just that nuanced thinking gets back to, you have to establish that connection to what you’re trying to do with the company’s products more broadly.

Abi: I love that. I would maybe add to it. At least in my mind, not only are your actual customers the end customers of the business, but really the business itself is a customer in a way.

Russ: Right.

‍Abi: Because as we were just discussing, your ultimate goal might be to save the business money or improve reliability for the business. I love that way of thinking that you’re sharing.

Russ: Exactly. Exactly. If the business has decided we really need to cut costs, how can the platform enable that? What sort of things could we be working on to make sure that that happens as quickly as possible?

Abi: It’s funny. My brother actually recently had a product at Gusto and took on this larger product role. I was having a conversation with him about the same problem. Even for a customer-facing PM. I think a lot of, especially new PMs, when they come into a PM role, they become hyper-focused on the customer.

What are the customers requesting? What are the customers complaining about? What’s a vision that serves the quote, unquote, customer? The advice I gave to my brother was, “Don’t forget that you’re operating within the context of a business that is trying to also do things.”

And so, finding that balance between your end user and the business and having that impact on both in a balanced way is one of the challenges for any PM role. But particularly, easy to maybe stray or veer when you’re a platform PM. Because internal developers are such vocal and accessible customers.

Russ: Yes. They are. Totally. I mentioned the cost thing, but there’s also security related things that you have to factor in for your business to be operating within the confines of the legal constraints. There was a lot of other things to consider.

Abi: I want to ask you more about Twilio, because I know a big part of what you’re doing at Plaid now is trying to introduce or re-implement or adopt some of the learnings and things you saw at Twilio. I want to first ask, you talked about how at Spotify it’s just assumed.

It’s a forgone conclusion that platform teams have product managers. What was it like at Twilio? Did every platform team have a product manager? Where did product management sit in relation to these different teams? What did it look like?

Russ: I would say … I’m just thinking through right now. If I can think of any teams that operated without a product manager. If there were, they were few. The majority of the platform teams at Twilio did have a product manager or at least product management coverage.

There was some product person that was consulting with them on identifying the most valuable things to work on. In most cases, there was a … I guess you would call it a line PM. Helping prioritize the backlog and some of those more traditional things that a PM might be expected to do day-to-day.

‍Abi: In your personal experience, was there a specific product or a project you worked on or you saw someone else work on as a PM, where you really felt like, “Man. This really highlights the value that a product manager can bring.” Was there a big win there that was product-led that comes to mind that you could share?

Russ: For sure. I’ll give you one where I was like, “This was super cool,” which was we had this problem with the time required for systems to boot up was taking way too long. This is just the time to bootstrap a new system. We spent a bunch of time. We instrumented the system and all that. It was really important for us to solve this problem. The way that sort of captured the problem was every time a team wants to deploy new software, they’ve got to boot up a new machine.

Again, we had this immutable infrastructure pattern. Somebody came over to us and they were kind of upset. They were like, “Oh my gosh. You guys broke the system. Our machines are booting up in 20% of the time that they used to require to boot up.” “No, no, no. That’s based on some work we’ve done recently to try and improve the developer experience for you and make sure that you have a higher throughput of change.”

The other big one that I can cite, which you can read more about … It’s in Jeff Lawson’s book, Ask Your Developer. This work we did. I was the principal PM for this one. Building out CICD pipelines, continuous delivery workflows, to enable the software developers at Twilio to get binaries basically from the build system out into production safely. And that, “Safely,” thing is very important. There’s all this work we’ve put into orchestration strategies, et cetera.

Prior to having done that work, it was fairly difficult to get new software changes out the door. Ironically, I’m staring at a text message that was sent to me just a little while ago from one of the engineers that’s still at Twilio. This is from someone at Twilio that I’m not familiar with, but they said, “As a noob here, I’d like to say thank you to all the people who’ve built and worked on Admiral. It’s one of the nicest, simplest deployment mechanisms I’ve used right from creating a pipeline in manifest to hitting Deploy.”

I put so much time and energy into that thing. Working with product designers, with the product team itself, putting in place a strategy to roll that out to the developers at Twilio. Super rewarding. An example of where we put a lot of energy into making sure that we understood the problem space and where we could offer the most value to the business.

Abi: Well, that’s awesome. I would ask you probably a million questions about Admiral and how that system worked, but that’s probably a conversation for a future episode. I want to ask you about Jeff Lawson’s book, Ask Your Developer. Personally, I haven’t read. It’s on my reading list. I want to ask you, what is the real point of that book? How is it tied to Jeff’s leadership philosophy? How did it, in your view, influence the culture at Twilio?

Russ: I think it’s probably best captured in the title. I think Jeff is super passionate about being developer-centric. For those of you that may not live in the Bay Area, there’s a big billboard on one of the major freeways that heads into the city on the 280. Where the 280 and the 101 meet, for those of you that do live in the area.

It’s a Twilio billboard and all it says is, “Ask your developer.” I think the idea there is it represents some of the developer-centrism that Twilio embraces deeply. That sort of sentiment I think applied all the way down to what we were doing on the platform team.

Abi: I remember reading the cover description of the book, and I think it mentioned something about how essentially business leaders are overlooking one of the greatest source of insight and strategy in their business, which is to just ask their developers. Is that one of the points of the book?

Russ: I think if you read the back cover, it’s essentially, “How can you best leverage the software developers to deliver an amazing product?” Particularly, for these things. When I use the word, “Platform,” Twilio is a platform, but in the broadest sense. The same way you might say Google Cloud or AWS.

Twilio is a communications platform. When you’re building one of those platforms, they’re meant to be consumed by developers or engineers of some sort. I think what Jeff is getting at there is don’t underestimate the power of considering that developer as the primary persona that you’re trying to satisfy and enable for building a successful product.

Abi: Makes sense. I want to now move forward. We’ve talked about your view on platform product management in general, some background on how things worked at Twilio. Now, coming back to Plaid again. Also, just in general. How do you get started?

‍What does it look like to introduce a PM discipline into an organization? For other organizations that are maybe trying to hire their first platform PM, what should they be thinking about? What’s your advice for getting started?

Russ: That’s a great question. I would say it has to start at the top. I think it has to start at the VP level, frankly. Or wherever there’s that top-level decision making being made. It’s, “How do we operate as an organization?” I think if you just try and hire a PM and embed them in a small platform team in a larger organization, I expect that’ll probably be pretty rough.

Because the expectations won’t have been set appropriately. They won’t have the shared understanding of how the business wants to operate with that PM on the team. And so, I think what’s been great about Plaid is they brought in a very senior platform product leader, my boss, Amit Kaul, who was the director of product for Netflix’s platform. He built a strong partnership with the engineering leader we have at Plaid within the platform space.

That’s really enabled me to come in and start introducing the discipline with the Developer Foundations team. I’m working with now the data platform team. I expect building that relationship I have with my engineering partner would put me in a place where if we were to expand the product role, there’s some model there already in place. Some expectations that have been put in place.

If you read anything about how can product work successfully within an engineering organization, the first table stakes thing is trust. You have got to have trust between your engineering leadership and your product leadership. Without that, things will go off the rails quickly. That’s why I think, in this instance, you really do have to start from the top and decide it’s a priority. And then, start to slowly roll it out throughout the organization at that point.

Abi: You brought up another question in my mind. A lot of platform engineering organizations often operate for a while without product managers, but relatively, I think senior and capable engineering leadership in the org chart.

When you introduce product managers, do those product managers in your view typically report into the existing product management organization? Or have you also seen it where the platform PMs report into engineering leadership, since it’s such an already engineering-led function? Do you think one works better than the other? Do you have a personal opinion on that?

Russ: I’ve seen both and I’ve seen both work. I don’t know that I have a strong opinion on that. At Twilio, my boss’s boss was Jason Hudak, who was the VP of the platform engineering team, and my boss was a senior director of product. He reported to him and I thought that worked really well.

At Plaid, it’s a little bit more where my boss reports directly into the CTO, instead of a VP of platform engineering. We don’t even use traditional job titles at Plaid, and that works well too. It really does come back to that idea of having a shared understanding of what the expectations of the role and the partnership should be.

Abi: That’s good to hear. You’ve seen both approaches work well. I do have a follow-up question. In the case where the platform PMs are reporting into engineering leadership, what have you seen as far as the career ladder or career progression?

Is it typically still tied to the existing product management ladders? Or do you see a bit of a gray area, where platform PMs are treated maybe a little bit more like engineers than they are product managers, in terms of career progression within the organization?

Russ: My experience with that was at Twilio. Twilio is a fairly large company, so there’s a formal career development framework for engineers and product managers. And so, if you were a product manager on the platform team, you were following that career development framework for the product management role.

It never really felt like I or any of my team … I don’t think they would answer differently that we were treated as engineers or something like that. We still participated in the broader product activities and product all hands and that sort of thing.

Abi: The last question I have for you is a higher level thing around how to introduce product management discipline into a platform organization. You touched on this in a conversation we had before recording. You talked about engineering-led versus product-led organizations.

I’m curious how you see that pertaining to platform organizations, which as we’ve talked about, organically tend to be more engineering-led. But as you introduce product managers into the organization, there could be a tension there or a shift that needs to happen.

Russ: I think it’s super important to start with that. When we talk about product-led versus engineering led. I think the other word way I’ve heard it characterized as technology-led is it should be a small P for product-led or a small T for technology-led. What I mean by that is I don’t actually think … This gets back to way earlier in our discussion.

I don’t actually think that you necessarily have to have a product manager to be product-led. Product-led is a way of thinking, which comes back to considering our platform through the same sort of lens that we might consider an external facing product. How does this deliver value? If we do frame it that way, hopefully it alleviates some of the tension. Where folks don’t feel like, “We’re going to have this group of product people come in and start telling us what to work on.”

If that’s the case, it’s going to be bad news. Because the reality is some of the best ideas are coming out of engineering. The role of product management is really there to help frame those ideas, so that we can get to strong conviction about the prioritization there. Again, I think you can do that without a product manager. But in terms of easing that transition, this gets back to a few things that we talked about today.

I do think if you’re going to be a product manager in the platform space, it is really important to have some technical chops that you can lean onto to build trust with the team. Opening a PR, even if it’s not fantastic and something that the team needs to work with you on, goes a long way. Because it shows, “Hey. You’re thinking about the problem deeply and contributing to it on the ground floor,” so to speak.

That helps. But also, going through and making sure that you as a product manager are bringing back value. You are bringing the customer’s voice. Now I’m using using customer in that sense of the internal partners, their voice to the table, et cetera.

And so, folks feel like, “Hey. You are providing a unique perspective here that otherwise didn’t exist.” If you get in there and you’re just saying, “Here’s the things that we’re working on. Here’s the prioritization for the backlog, et cetera,” I don’t think it’s going to work.

Abi: Well, it’s great advice. I was laughing when you said customer voice or voice of the customer. I also hear the phrase, “Voice of the developer,” which avoids the term customer. But Russ, thanks so much for coming on the show today. It’s been an awesome conversation.

I think a lot of leaders will get value out of this as they think about how to make the most out of product managers and their organizations or introduce product management into their organizations. Thanks again for coming on the show today.

Russ: My pleasure. I really enjoyed it.