Episode 56: Answering Questions About AI and Platform Products, Being New To Product Ops, and People Management in Product
In this Dear Melissa segment, Melissa answers subscribers’ questions about data, AI, and platform products, transitioning from project management to product operations, and how to navigate a lead engineering role that is intertwined with both product and people management responsibilities.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: How do you do discovery and write requirements for data, AI and platform products? [1:09]
A: [While] it’s true that you don't need a wireframe when you're doing an AI, data or platform product because there's nothing visual to look at, that doesn't mean that you're not communicating through diagrams and not doing discovery work… What you need to do is look at the product roadmaps from an application standpoint, trace back all that value into how you enable it through data, AI and platforms, and start to understand that. Once you have that, meet with the product managers who are building those applications… then figure out how their roadmaps fit into your platform vision and what to build. [1:52]
Q: What are some tips and tricks you would recommend for a first time product operations manager coming from a project management role? What do you think are the most important things to do during the first 30 days on the job? [8:17]
A: One of the big things you have to remember coming from a project management role is that this role of product ops is not the stuff that you've been doing as a project manager… In your first 30 days, you should meet with your product managers… Look at what they are doing now, where the gaps and the biggest red flags are… You have to put your detective hat on and try to figure out what's burning right now, and what the first thing you can roll out is. [8:28]
Q: Can people and product management really mix? Do you have any tips for making sure both domains can run smoothly without interference? [13:15]
A: Can people and product management go together? Yes, that is the number one path for product managers to get promoted… It can be really easy as a lead engineer to get into the mindset of technology first instead of needs, problem solving, and customers first… You need to be prioritizing [customer needs] and what’s going to get you to product market fit, then make sure the technology follows that… If you’re overseeing all the product people, then you’re the product manager. If you want to concentrate on engineering only, then you want to be the lead engineer. You [should] separate products from that so that somebody else can be making those decisions… They can all work smoothly without interference so long as you understand what the roles and responsibilities are of each. [13:55]
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another product thinking podcast today. We're doing dear Melissa and diving into all of your questions.
So I've got three great questions for you. Um, one's about data and AI and platform products. One is about product ops and one's about becoming an engineer who really runs, uh, product and people management as well. So interesting things to dive into. Let's get started. Dear Melissa. I have a question about the job of the product manager for data AI and platform products. I mainly have experience with products like thinking apps, marketplaces like job sites and self-service areas that are very visual by nature. For these types of products. You typically start from a problem in an opportunity due with customers, define a solution and describe it in a PRD with wire frames or a prototype, build it and launch it and then iterate. How does it work for data AI and platform products? It's clear that you still start from problems and opportunities, but I imagine that the way you do discovery and describe your requirements is very different eager to learn more about this. So this is a great question. And one, I get asked all the time and I'm gonna answer it for you right after this message.
All right, we're back. And we're talking about how do you actually do discovery and write requirements for data AI and platform products. So, yes, it's true. You don't need a wire frame, um, when you're doing a AI data or platform and product, because there's nothing visual to look at, but that doesn't mean that you're not communicating through diagrams, um, and not doing discovery work. You have to do discovery work as well. So when you think about AI platform and data products, uh, usually you are enabling other product teams to be able to do their job or consume into their products. Uh, so for instance, a platform product usually sits underneath a bunch of applications. It feeds data, um, or different processes or, uh, services. Let's say services is a great word for this, um, into the applications through APIs. And why do we do this?
Um, we do it so we don't build the same services over run over and over again, across multiple applications. So incredibly important in really big companies, but you know, just important in any size company actually. So, um, data AI, similar, uh, AI, obviously we're gonna be doing some complicated algorithms on the back end feeding those into, um, applications and it could be spread across us, you know, many different types of applications, uh, and same for data now. Yes, there's nothing visual to look at for this. But when you think about it, your customers, um, your customers are still the customers that are consuming those applications that you fed into at the end of the day, but your users are the people internally in your company. So what you need to do is look at the product roadmaps from an applic standpoint, trace back all that value into how you enable it through data, AI and platforms, and start to understand that.
Now, once you have that, what you do for discovery work is go to meet with the product managers who are building those applications. You understand their roadmaps, you understand the company priorities the strategy at a higher level and gives you some insight into what are they going to be consuming short term and long term on the roadmap. Then you have to figure out how that fits into your platform, vision, and what do I build now? Um, this can be really troubling to some companies. Some companies think about building platforms in isolation, uh, not looking at the real roadmaps of others or they think, Hey, everything needs to be dependent on the roadmaps of others. It's more of a balance. Um, you wanna prioritize the work that you are doing on the platform side or this backend side against the roadmaps for the applications. So you can't build a roadmap for your backend platforms without a roadmap for your front end stuff.
That's gonna be consumed by users, right? Customers, I mean like real end user customers. Uh, you need to be able to build things that could be sold, you know, really enabling that, uh, value chain to come out there. Now here's an example, uh, of when that doesn't actually work out. And when we build things in isolations, I worked for, with a company quite a while ago. Uh, they had everything built as a big monolith. Uh, they had many different applications and many different business lines across it. And they said we wanted to build a platform because we all exchanged the same data. Uh, it doesn't make sense to have copies of this data over, you know, eight different applications. Let's build this platform. Uh, they did not have product management help when they first start specking this out. They did it totally in the engineering team.
They built the vision for the platform, and then they started to build the services they thought people would need for the platform. They spent tens of millions of dollars building the wrong thing because they didn't talk to the product managers or, or look at their roadmaps about what they would be consuming. So they started prioritizing the hardest services to build or the most complicated ones or things where they thought they could use fun AI techniques or something to enhance it. And it had nothing to do, uh, with what was on the roadmap for sales and what was being promised to customers and what was on the map for the product teams. So what happened? They built all these things and none of the developers on the applications teams ended up adopting any of the APIs or any of the services that was actually built. That's where you started to run into trouble.
I have seen that happen lots and lots and lots of times. So what, um, does good product management look like on a platform product, a data product, AI product, yes, you will have product managers. First of all, let's put it that way. That company in particular did hire a VP of product over the platform and then did great management to get it back on track. They recovered, built a great platform. Now, what do you do as a backend product manager on a team like this? Uh, your discovery work should be meeting with the engineers that will be digesting your data and using your data and tapping into your services, find out how they'll be using it, find out how it gets integrated to their products, find out how it delivers value to the customer. Then spec out what needs to go into that to make that successful.
You're not gonna be building wire frames, but you'll be doing things like data schema, uh, data schema will probably become your best friend. Uh, database schema are what they're called. If you don't know what that is, and you're working on a backend data product, uh, meet with your engineers and find out that is incredibly important. The engineers are gonna wanna know how all the data talks to each other. Um, what works, you know, together, how you should be structuring it, what types of applications we'll be pulling it in. Uh, usually you're gonna be writing out a lot of these things. It's gonna be a lot more words and technical diagrams than it is like visual wire frame. Uh, if you are working on an AI product, you have to specify what the algorithm should be doing. Um, you have to write a bunch of test cases to talk about like what the algorithm should be returning, things like that.
So the whole process of discovery through delivery is gonna be very similar, but the types of documentation that you use are probably gonna be more technical. And a lot of times we look for people, um, in these roles who have enough of a technical background to work with the engineers and to, um, understand how data works and data schema and all that different stuff. Now you don't have to have like a super extensive, uh, experience. No, cut that. Now it doesn't mean that you have to be an engineer, but you really deeply have to understand how these things are built. So that's gonna be different than like a consumer facing visual type thing, for sure. So, um, that's really what it looks like to be a backend product manager on these, uh, platforms or these, uh, you know, data products and AI products. Uh, you still doing a lot of product manager, but you're not prototyping or wire framing things out from a UX experience, but you are doing it from a technical experience, uh, data schema experience, and you're still building it, launching it and iterating on it based on the feedback from the developers and keeping in line with the roadmaps of the application teams that are consuming it.
All right, next question, dear Melissa, what are some tips and tricks you would recommend for a first time product ops manager coming from a project management role? And what do you think are the most important things to do during the first 30 days on the job? Good question. Um, one of the big things you have to remember coming from a project management role is that this role of product ops is not about scope and time and budget and the stuff that you've been doing as a project manager. Now you're definitely gonna be using your project management skills and thank God for them, because if you're a great project manager, I believe if you can do this role very well too, but you also have to put your product hat on, not just project but product, right? You are building systems and processes and, uh, optimization for the product management team.
So I'd say like in your first 30 days, get together with the product management team, understand what their processes look like. And then start to figure out where they're inefficient from like a data gathering perspective, a data informing perspective, um, a communication perspective. Uh, let's see what else we got. We've got market research perspective, um, and then cadences, uh, strategy deployment, all of these things that we talk about with product ops, I've talked about it a million times. If you don't know what these things are. Um, I have many episodes on product ops in the Melissa dear Melissa segments, Ugh, all that. Let's take it from, uh, you need to meet with your product managers. Now you should be really looking at their processes and starting to think about them from a what's inefficient about the way that they gather data or inform data, do market research these days, uh, set up their cadences, set up their strategy and deploy it.
All of these things that we talk about, what, uh, great product operations looks like. You need to go look at what are they doing now? Where are the gaps? And also where are the biggest red flags like, Hey, let's say that there is no strategy. All right, I'd start with, how do we get information to inform the strategy so people can actually set it. Uh, maybe there is no communication tactics for roadmaps, but there is, you know, a roadmap floating around somewhere. Okay, let's start with that many different places to start. You have to put your detective hat on and then go in there and try to figure out what's burning right now. And what's the first things I could start to roll out. So I think that's really important. I would get really familiar with, you know, how they do their job. What are their frustrations?
What are they outside the scope of their job? Like your job is to take away a lot of that work. That's inefficient for them or things that they shouldn't be doing so that they can maximize their time making decisions. So, uh, you know, where are they gathering data from? Where does it live? Are they using analytics tools? Are they not using analytics tools? Uh, are they doing market research or are they doing customer research, but it takes too long to get in front of a customer. All of these types of things are gonna help you inform where you should actually start. So I'd start there. And then secondly, I'd start looking at all the other roles that surround product managers and, uh, you know, help to get product products out the door. So I'd look over at the sales team and I'd say, Hey, sales, how are you tracking your feedback from customers about like our win and loss, uh, reasons like why do we lose customers? Why do we win customers, worry, keeping your notes? Oh, is that making it to the product team? No. Okay. I, that's an opportunity for me to start streamlining this and help them be able to get this data.
So I'd go to all these other teams and I'd also see how are they exchanging information with product management and also how is product management communicating with them and maybe how could we do it better? So, um, trying to figure out what their frustrations are. They may complain about a lack of transparency of what's coming on the roadmap. That's a pretty popular one. All of those different things are things that you can actually help with. So coming out of those first 30 days though, you need to have a plan and the plan should really address where do you see the biggest gaps as it relates to product operations? Um, is it in data and insights? Is it in, uh, you know, cadences and strategy reviews? Is it in processes and tools? So where are the biggest gaps there, then you're gonna wanna present that back to the team, um, make sure that aligns with what the product managers would think are most helpful. And then you wanna communicate that out to the other roles as well, especially if you're gonna be doing cross-functional work, um, you know, things that really tie into what they're doing on a daily basis and things that other people need to know as well. So that's what I would really look at, but I'd say, and a caution, just remember like product ops manager, product operations manager, very different than a product project manager role, very, very different.
So use the project management pieces to help you streamline a plan, get that plan done, figure out what needs to work. Um, those things are really important to actually implement your plan and put it together, but don't just try to streamline it in a, a task list oriented thing. Like you need to bring product management into your thinking so that you build systems that are repeatable and robust, and you're not just doing one off fixes on inefficiencies. Uh, so for instance, if you are going to help people streamline their customer research efforts, like build that into a system that all the product managers can could use. Don't just go out there and do a little stop gap thing for one or two project manager. I mean, product managers do it for everybody, right? Build repeatable systems. So that's the hat you need to wear when you're a product operations manager and that's gonna be different than project management. So I want you to really, um, understand what it means to be a good product manager too, cuz you're basically the product manager for the product managers. Uh, and that's going to have a really big impact on your business.
All right, last question, Dear Melissa. I've just taken the step up from regular engineer to lead engineer, which has both product and people management in a small 30 person startup. Can people and product management really mix. And do you have any tips for making sure both domains can run smoothly without interference? Thanks. Uh, so one thing that concerns me about this question too, is that you see yourself as a lead engineer running the product as well. So it's like product people and engineering. I imagine. Uh, I need you to think of yourself, not as a lead engineer right now, but as actually the lead product manager. And I'm gonna describe what that means. And if you feel like you can't do that role, this is where, or you don't wanna do that role, which happens a lot. Uh, this is where you have to have a conversation with your boss. So can people and product management go together?
Yes. Like it is the number one path for product managers to get promoted is like you become the people manager, the director of product, the VP of product. It all has people management responsibilities. So there is nothing weird about that. That is a commonplace thing everywhere. Um, but you might not wanna do people management. Uh, that's common as well. A lot of people get into these roles and they say, Hey, I'd rather execute. I don't really wanna manage people and that's totally fine. And that's where these IC senior principal, engineers and principal managers come from, but you usually don't find them in a 30 person startup. So let's take a couple steps back and start talking about like engineer lead versus product lead. It can be really easy as a lead engineer to get into the mindset, especially at a small company of technology first, instead of needs and problem solving and uh, you know, customers first, like what do the customers need and what are they gonna buy from us?
You need to be prioritizing that way and thinking about what's gonna get you to product market fit and then making sure that the technology follows that like the technology plan follows that, um, I'm not saying technology is not important. It is critical Absolut critical, but you don't want tech leading. Like you don't wanna build things that will never get used by customers. You don't wanna build things that won't get used by customers tomorrow because you're a startup and you don't have a lot of money, so you don't wanna run outta money. So that's critical. Now lead engineers are usually, uh, overseeing their developers, helping standardized process, uh, doing code reviews with them, coaching them up so that they're a little bit, you know, more proficient in their craft, uh, implementing DevOps, implementing all these different things that help you be a better engineer, uh, standardizing like those processes too.
Sometimes a little bit of architecture, certain in there as well. Uh, but that's a common for a lead engineer now, lead product manager. Who's kind of overseeing a bunch of other product managers in a people management space too, is usually working with the stakeholders to figure out what's the next strategy, uh, building the roadmaps that are informed by their teams, communicating it up to the, um, the leadership, uh, negotiating with leadership about, you know, what can we let's say this, leadership's always gonna want everything, especially in a startup, you need to be able to push back and say, no, this is what we can commit to. Or here's your choices. We can either do a, or we can do B, but we can't do both. So which one would you like to have first? That's a completely different conversation. Then usually what the engineers are having, um, usually with the engineers and product managers, there's definitely gonna be negotiation there, but you're gonna be having it on a business level and you have to understand what's the financial impact of doing X versus Y uh, tracing all that up is absolutely critical when you're overseeing the product roadmap and you're overseeing all of the product backlog and all the product managers.
So that's kind of why I ask here, like, do you wanna be a lead product manager? Cuz if you're overseeing all the product people, congratulations, you're the lead product manager, but if you wanna concentrate on engineering, uh, only then you wanna be the lead engineer and you'd wanna separate out product from that so that somebody else can be making those decisions, negotiating with crazy stakeholders and pushing back on sales when they wanna add everything to the roadmap. So you have to decide if you wanna do that work. And if you do wanna do that work, understand that it's actually very different than what a lead engineer or does. And if you don't wanna do that work, then you're gonna have to have a conversation with your boss about getting somebody in there to help you and partner with you. Not somebody to oversee you, but somebody to be your partner, uh, so that you can manage the developers.
You can, uh, be the people manager and slate architecture and everything in there, but then you work with somebody who's gonna oversee the product managers to, but yeah, they can all work smoothly without interference. Uh, so long as you understand what the roles and responsibilities are of each and where does product need to lead and where does tech need to leave in different scenarios? All right, that's it for dear Melissa this week. If you have questions, please go to dear melissa.com and submit the I'm. There we go through these every two weeks and I pick out three questions to answer. So I can't wait to see yours. Feel free to get as deep as you want. I like reading them and hearing your feedback. And if you like the product thinking podcast, please subscribe, uh, wherever you're listening to this hit that subscribe button. We will end up in your inbox on Wednesdays every Wednesday. So thanks for listening and we'll see you next time.