Episode 137: Answering Questions About Platform Product Management and What That Means
Episode 137: Answering Questions About Platform Product Management and What That Means
In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about platform product management, including the challenges of re-platforming products at the enterprise level; the fundamental differences between end-user product management and technical product management; and the significance of product discovery in platform teams.
Have a product question for Melissa? Submit one here, and Melissa may answer it in a future episode.
Q&A:
Q: Dear Melissa, we are re-platforming a product at the enterprise level. My product will need to build the specifics we need once the enterprise infrastructure is in place. It's a platform that today is tech-heavy to manage and maintain. I want to shift the approach to give ownership to internal users to maintain their own pieces and make their own updates. However, putting dollars in value to something conceptual is challenging. What's a good way to sell a different way of doing something that will drive long-term improvements in a manner that can bring data and dollars to the table in an analytical environment?
A: So, doing a re-platforming or changing something like this does actually translate to dollars. Sometimes it's hard to think about it, but it does. So if you think about what you are trying to do, which is putting the things in the hands of the internal end users and allowing them to make changes instead of the developers to do it, you're actually streamlining operations, and you're freeing up your developers to work on other things, which is opportunity cost at the end of the day. So when you're thinking about doing a platform change like this, from what I understand, what this means is that you want to make it possible for people to go into the system and change things themselves to enable the end users to do that. And there's a cost associated with doing that if you are doing it for them.
Q: Dear Melissa, we recently grew our engineering team and are now able to reform into three squads. One of the squads is more platform-based, and I was moved to that squad because I am the most technical of all the product managers. While it makes sense on paper, I am no longer doing end-user product management, which is what I love doing. Thankfully, the engineers that are on my team are incredible, experienced, and, best of all, great peers to work with, so I'm at least excited to learn and lean into the infrastructure and DevOps experience. However, I'm at a bit of a loss for understanding what the day-to-day should and could look like as a technical product manager to make sure I'm doing the best I can in this role. I know what it looks like for end-user product management, but this feels foreign, and no one on the team is able to give proper guidance. Do you have any advice on this type of transition and role?
A: Platform product management is weird because now you have to start to think about who your end user is, and your end user is the people internally. So this is an opportunity for you not to just prove that you can do great technical product management and learn from your peers, which is fantastic, but it's also an opportunity for you to get some goodwill because you're helping the people who sit around you all day long, and they're gonna be very excited about that, so you should get excited about that too. So when you think about going into a more technical backend team what you're doing is worrying about the user experience, but the user experience from a workflow perspective of the people around you.
Q: Dear Melissa, I'm soon starting a new position as a product manager for a platform team, and I could use some advice on how to approach it. Having internal teams as end users and not having a designer on the team is new to me. How do we run product discovery in a platform team? Does a product trio become a product duo? Any tips to get started?
A: Hopefully, the tips I just gave will help you as well. But let's dive into that one key part of product discovery because I think that's important. I've heard a lot of people say, oh, you don't need discovery on platform teams or backend teams, and that is just straight out wrong. Product discovery is still extremely important on a platform team, you're just not gonna have a designer working with you. Instead, you're gonna work with your tech lead, so you and your tech lead are going to be joined at the hip, your trios going down to a duo. And that's totally fine. And what you really want to do as well is partner with the other product managers around the company and other tech leads and other developers.
Resources:
Intro- 00:00:01:
Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is The Product Thinking Podcast. Here's your host, Melissa Perri.
Melissa Perri - 00:00:37:
Hello and welcome to another episode of Dear Melissa. Today we're going to talk all about platform product management and what that means. And I just want to remind you that you too can ask me any of your questions about product management by going to dearmelissa.com and dropping me a line. If you leave me a voicemail, which I love to hear your pretty voices, you will get prioritized, so I tend to answer those first. So definitely go and let me know what you're thinking about. Let's dive in to our first question.
Dear Melissa, we are replatforming a product at the enterprise level. My product will need to build the specifics we need once the enterprise infrastructure is in place. It's a platform that today is tech-heavy to manage and maintain. I want to shift the approach to give ownership to internal users to maintain their own pieces and make their own updates. However, putting dollars in value to something that's conceptual is challenging. What's a good way to sell a different way of doing something that will drive long-term improvements in a manner that can bring data and dollars to the table in an analytical environment?
All right, so doing a replatforming or changing something like this does actually translate to dollars. Sometimes it's hard to conceptually think about it, but it does. So if you think about what you're trying to do, which is putting the things in the hands of the end users who are internal, right, and allowing them to make changes instead of the developers to do it, you're actually streamlining operations. And you're freeing up your developers who work on other things, which is opportunity cost at the end of the day. So when you're thinking about doing a platform change like this, from what I understand what this means, is that you want to make it possible for people to go into the system and change things themselves to enable the end users to do that. And there's a cost associated with doing that if you are doing it for them, right? Just like in a product, you could take an example of a normal workflow app that we might sell to businesses.
Let's pretend you have no way to onboard them and they have to call your sales team and you have to put in the user account and do all this stuff manually. It takes developers and it takes people in your company time to actually do that. So what I would do is look at quantifying what type of changes you want to make. And maybe you don't start off really big as we want to re-platform everything at this enterprise level and open this up so people can do things. I think instead what you want to start with is quantifying how much cost it takes the development team to work on these issues for the rest of the company. Then you're going to want to translate that into the product strategy. And then you're going to want to make your business case. But let's start small. Can you come up with some examples that people can actually empathize with? I would look around the company and say, “hey, here's some common scenarios where if we were to rebuild this platform at the backend or open up these workflows for people to do this themselves, we could save 20,000 hours of developer time or 200 hours a month of developer time”. What are those workflows? And what are the most common workflows that you find that you're doing over and over and over again on a development team that doesn't make any sense, that you could hand off to somebody else? There's a cost associated with that. In larger organizations, sometimes we tend to neglect those costs or eat them, right, and forget about them. And in smaller organizations, they become apparent because you don't have a lot of people.
So if you're in a larger organization, I would really think about making those transparent because people are cost conscious in larger organizations. Like they do care about those things, but you want to show the value. So there's one side of really looking at the efficiency that it will provide and how you can take the work away from the developers so they can work on something else. And that becomes the opportunity cost. So first it's the efficiency of how much time can we save, how much money could we save by not doing this work? And then the second part of it is looking at what you might be able to do otherwise. So for example, if you re-platform and you're able to build applications on top of it faster or maintain it faster or free up the developers to work on some critical functionality that's been kicked down the roadmap. Now you're starting to get into things that stakeholders work their ears up at and go, oh, we can get that thing on the roadmap that I want. And that's really what I would start to look for. One, efficiency metrics and then two, opportunity cost. What could you bump up? What could you do faster? And there are metrics associated with that. So don't think that you can't get those out into dollars and cents because you could. And what you want to do is start to model it out. So you want to start to model out hours being spent on things, the cost of that being spent. You can do that by taking an average salary in your company and getting it back down to hours and then multiplying that out and showing how much money is actually attributed to that. Then when you make the product strategy for this new replatforming that you want to do, show how much time it would take, show what the investment would be, because they do want to understand the ROI, but then show how that scales over time. There's probably also a way to show people, and I would maybe model this out in a graphic, about how this might not be sustainable over time too. Can you show where it breaks? Can you show where you need to hire more developers to do these changes instead of replatforming? So I like to break things down into options and start to show people that like option one, we do nothing, this is how our tech that builds, or we need to hire people, that's the cost, right? Option two, we invest in replatforming, we start with these pieces, we start small and then we move over, that's this type of investment, here's our ROI, this is what it's going to cost. That's the type of thing you really want to get across to stakeholders and when you need a big push like that, that's really what works, you got to speak their language. So as hard as it is to kinda think about dollars and cents when it comes to backend stuff, it does equate to it. You got time to market, you've got speed, you've got opportunity costs to work with and you've got efficiency metrics within your own organization, try to work with that and see where that goes, so I hope that helps. Facilitation is a skill I see as a fundamental difference between good and great product managers. Yet it's often overlooked. Great product managers focus on guiding clear conversations and steering stakeholders to the best outcomes. You can develop these facilitation superpowers in Voltage Control's Facilitation Certification Program. Ready to unlock your greatness? Apply today at voltagecontrol.com/product. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. All right, next question.
Dear Melissa. We recently grew our engineering team and are now able to reform into three squads. One of the squads is more platform-based and I was moved to that squad because I am the most technical of all the product managers. While it makes sense on paper, I am no longer doing end user product management, which is what I love doing. Thankfully, the engineers that are on my team are incredible, experienced, and best of all, great peers to work with. So I'm at least excited to learn and lean into the infrastructure and DevOps experience. However, I'm a bit of a loss for understanding what the day-to-day should and could look like as a technical product manager to make sure I'm doing the best that I can in this role. I know what it looks like for end user product management, but this feels foreign and no one on the team is able to give proper guidance. Do you have any advice on this type of transition and role?
All right, so platform product management is weird because now you have to start to think about who your end user is, and your end user is the people internally. So I actually worked on a lot of products in my early career that were not customer facing. They were more internal for what we were doing and those are important as well. And they tend to get neglected. So this is an opportunity for you not to just prove that you could do great technical product management and learn from your peers, which is fantastic, but it's also an opportunity for you to get some goodwill because you're helping the people who sit around you all day long and they're going to be very excited about that. So you should get excited about that too. So when you think about going into a backend team that's more technical, what you're doing is worrying still about the user experience, but the user experience from a workflow perspective of the people around you. So you're going to want to get up to speed, especially if you're working with DevOps or anything like that, on how those people do their work, right? How are the developers deploying? What's frustrating about it? Let me understand the back of the platform, these backend components, and you want to get up to speed with that.
Most developers are happy to sit down with you and help explain that architecture and dive into that. And I would try to get up to speed with some of those more technical terms. So you want to understand things like what a platform is, how APIs work and how they're built, why APIs are powerful, how to read API documentation and get into those types of things. We want to understand more about DevOps and how those things work as well, and all more of this technical side of the world. So sit with your developers, ask them what they do, watch them, watch their workflows, watch them go in and out of the different programs that they use, watch them go to deploy stuff, see if they're using things like GitHub or something else for deployment pipelines. They usually have a lot of models and a lot of schemas for those things as well. Get your architectural diagrams, get your development pipeline diagrams. Sometimes they live in programs, sometimes they live out in Google Docs. Find out where all that lives and study up on that. And then start to think about what you can do to make their lives better according to your remit. So ideally you've got some kind of product strategy that's coming down to you. There's a reason you got moved to this backend team. Think of it like I am building the infrastructure and the thing that runs this company, right? You're doing the engine of the car. Nobody really looks at the engine unless you're like a car guy, right? Just like our developers. Nobody cares what's under the hood unless you're like really into those things. But you need to make sure it's good so that it scales. So you're going to worry now about things like scalability, load, all of these more technical issues to make sure that your company could be successful and healthy as it goes. Sounds like you have three squads now. That's fantastic.
Hopefully you get to 50, you get to 100. It's your responsibility to work with the developers and make sure that that works well. So you're going to want to care about those things. You're going to want to care about architecture and scalability. So that's what I would worry about getting up to speed on. Now, as a product manager, that knowledge is new for you. But what you do on a day-to-day basis is usually not that different. You're going to go talk to your customers who are internal. You're going to go talk to the CTO. About their scalability options and what they're planning. You still need to understand deeply the whole product strategy of the company. Like you need to go and understand where you're going, how many customers you want to start onboarding, how you're going to scale, what types of products are coming up. So now you're going to partner. With the other two product managers on the other squads. And try to understand what their roadmap looks like. And when you're thinking about your roadmap, you want to make sure you're enabling. The customer facing money making side of it. Right? So they're going to be out there thinking about what do we sell? And then they have to come back to you and you're going to be saying, how do I unlock that value through our platform?
How do I make sure that they can use the platform to build on top of it? How can I make sure they can use these backends to build on top of it to scale? When you're thinking about a platform roadmap, you do have your own strategy, but it always follows a commercial-facing strategy. And then you put a lens on it to think about what amazing technology can we use to even like amp up our commercial side of things? Like there are areas when I can suggest to them that AI might be better or different types of APIs that we can architecture in here can make this more scalable, more sustainable, and even more powerful for our customers. So you don't forget about the customers that are really paying you at the end of the day, but you're going to be working through other avenues to do that. So that's the kind of mentality that you need to accept as a platform product manager. And I'll tell you this, platform product management is extremely hard, like extremely hard, and a lot of people get it wrong. I've seen people go out there, build a whole strategy for their platform and never involve anybody else on the commercial side or the customer-facing side or any of those other product managers. What happens is you spend millions and millions of dollars all of this time and you build this whole platform and nobody uses it. And it breaks and things aren't scalable and people work around you and all of these things happen. So you want to make sure that you're a high collaborator. You're going out there, you're still building your strategy. But you deeply understand where the business is going because that's important. And you're bringing that into the technical side. You are the voice of the business in the technical side and making sure that you can enable the sales, you could still enable the things to be built on that side.
So you're the voice of reason that looks at all the cool things we could possibly do with tech and make sure that it's in service of the business growing. And that's what a platform product manager does on a day-to-day basis. So you're probably not going to be working with UX designers. You're probably not going to be out talking to end user customers all the time, but you're still keeping a pulse on what's happening with the business. You're translating that into tech and you're thinking about how we can do that with different components. It's no longer workflows and UI, right? Instead it's back end components. So same mentality, but thinking about how do we do that on the back end with my tools and your tools are now technical tools. So that's the mentality that I would adopt as a platform product manager. Critically important, we need a lot better platform product managers out there. It is one of the biggest skill gaps I see. So you are setting yourself up right now to be in high demand soon because platforms are growing like crazy and we need great product managers there. So best of luck. All right. Last question, which is in the vein of what we just talked about.
Dear Melissa, I'm soon starting a new position as a product manager for a platform team, and I could use some advice on how to approach it. Having internal teams as end users and not having a designer in the team is new to me. How do we run product discovery in a platform team? Does a product trio become a product duo? Any tips to get started?
All right, hopefully the tips I just gave will help you as well, but let's dive into that one key part about product discovery, because I think that's important. I've heard a lot of people say, “oh, you don't need discovery on platform teams or backend teams”. And that is just straight out wrong. Product discovery is still extremely important on a platform team. And like I said, I've watched people just build these architecture maps for these platforms and these strategies without ever talking to anybody else in the organization. And they build it and they waste. I've seen people waste millions of dollars doing this. So please understand that product discovery is very important. You're just not going to have a designer working with you. Instead, you're going to work with your tech lead. So you and your tech lead are going to be joined at the hip. Your trios going down to a duo and that's totally fine. And what you really want to do as well is partner with the other product managers around the company and other tech leads and other developers. So your end users are now those people internally. So you're going to go do product discovery with them. So let's take an example. You're going to go out and look at one of the product managers, talk to them about what they're building, what their roadmap looks like. You're looking at that and you're saying, “okay, that means that on the backend, we're going to have to be building certain APIs and certain different components that will help feed back into these applications that are sitting on top of it that the users can actually interact with”. You're going to want to work with those developers and with that product manager to figure out and to understand what types of information are going to be passed through, what types of information they're going to need to want to come back to them. And you're going to want to do it in a way that's easy to plug in. So when you're looking at your product strategy, you need to design it in a way that's great for the other developers there. So some of this discovery that we do is not exactly the same.
Like let's say we still do discovery, but our toolkits are not exactly the same as what we would do with a UI. We're not doing prototypes usually, we're not doing A/B testing. Instead, we're still clarifying what people need and we're thinking about more things like architecture and the way that we set up the product strategy for success. So you're always going to be digesting things that are coming from the other product managers. But again, maybe you surface up solutions that make things run faster or more efficient or contain more data. Sometimes the product managers on those application sides don't even understand what the full platform can do. So that's your responsibility. So during discovery work, you're going to be working with them, you're going to be looking at what's coming up in the roadmap, you're going to be asking them about how they tested it, how users used it, you still want to understand those things. And then you're going to help them translate it into what does that mean for our platform. The second part that you would look at for product discovery when it comes to platforms is thinking about how it grows and how people want to use it. So you're going to be wanting to study. How people digest different parts of the platform. What kind of user analytics are on there, how many people are hitting different databases or different APIs and components, and you're going to work with your tech lead to figure out how that scales, how you want to model that out. And you're still doing those customer interviews. So some of this stuff might not be so unknown unknown as in a UI world where we have to work with a customer and show it to them, but you might have some unknowns on a technical side. And this is where you might work with the developers to do things like spikes, is one thing that developers call it, to go out and investigate if we can technically feasibly build something.
So you might be doing some discovery work like spikes on your platform to see if you can architect it different ways or build different ways or get data or plug into APIs that are external that you never knew about to see if they work or use things like Chat GPT, which everybody loves to talk about to actually power up your data, right? That's your type of discovery. So it's discovery in a more technical world. It's not so much discovery in a prototype UI type world, but you're still doing discovery and you still got to prove that's the right thing to do. So as long as the product managers on the front end as well who are talking to end users are doing discovery and you're doing discovery, this should work pretty well hand in hand. And like I said, A lot of people think you don't need discovery, that you can just go in a room and architect this out, but the more you talk to the people who are consuming your platform, which are the developers and the product managers and the other tech teams. The more you'll understand how they use it and the more you'll get comfortable with thinking about how to architect it and how to make sure that it's scalable, it's usable, and people are not going to just drop it when it gets too hard. You could still build an awful platform and nobody will use it. That's still a risk. Everybody's like, “oh, we have to use a platform”. I've been in a company where they did not. So definitely think about who your end users are now and it's those people internally, go talk to them. Those are the people you do interviews with now. So that's it for Dear Melissa this week.
Next week we'll be back with another fabulous guest on the Product Thinking Podcast. We release episodes every Wednesday, so make sure that you subscribe so that you never miss an episode. And if you have any questions for me, remember, go to dearmelissa.com and let me know what they are. We'll see you next time.