Episode 129: Answering Questions About Product Management Career and the Difference Between a Product and a Feature
In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about how to get your dream PM job, resources for young product managers, and how to determine if a project is a standalone product or a set of features.
Have a product question for Melissa? Submit one here, and Melissa may answer it in a future episode.
Q&A:
Q: Dear Melissa, I've gotten an interview with a recruiter at a dream product-led company. It's an experimentation platform, a PM position. I don't have direct experience in this area. So what should I highlight about my experience that proves I can excel at this position? Is it seeing the developer as the customer, seeing the importance of larger operational needs, not just the technical experience? Please help me get a second interview.
A: So it sounds like you are going for a platform product management position. So in a platform, in a product management position, which is different from a user-facing product management position, your developers are the customers, so you definitely have to remember that. It also requires you to be a little bit more technical. That means that you should get up to speed about things like APIs and how they work and how they should be designed, and understand data structures and algorithms and different stuff like that. But no matter what, if you are working on a platform, whether or not a developer is the customer, you still need great product management chops for that. So remember you are still thinking about what the customer is.
Q: Dear Melissa, I have a young and inexperienced product team, but they are all learners and aren't afraid to take courses or read books to advance their skills. Do you have any recommendations for courses or certifications I should get my team to take? I would especially love some recommendations as it relates to Q&A and testing.
A: One thing to look at when you're trying to bring new product managers up to speed is what kind of knowledge they need to know and I think you first want to start with a good basis of what product management is, and that's where everybody should start. Then, what you're gonna do is go deeper into the different aspects of product manager and get them up to speed on those areas more. So you really want a nice broad course that teaches you about product management and to end, what that looks like, then you want to start to dive deep into things that are more specific for you.
Q: Dear Melissa. How do you know if the thing you're working on is actually a standalone product versus a set of features behind a packaging and pricing tier? What signals do you look for when determining this?
A: This is always such a hot topic. Everybody gets into these huge debates about whether I am working on a feature or is it really a product? And I think from the standpoint of you doing product management, it doesn't matter that much. Like if you're a product manager on a team, rarely are you actually working on a full product. You usually have a feature set that's going to improve the product that you're in charge of. And those feature sets could be huge in really large companies.
Resources:
Melissa Perri on LinkedIn | Twitter
MelissaPerri.com | CPO Accelerator
Transcript:
Host/ 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. This week I've got three questions for you, two around careers, and one is about the difference between a product and a feature, which is a question I get hit with all the time. So we're going to dive into that as well. We're going to kick it off with our first caller and go to the phones.
Dear Melissa, I've got an interview with a recruiter at a dream product-led company. It's an experimentation platform PM position. don't have direct experience in this area. So what should I highlight about my experience that proves I can excel at this position? Is it seeing the developer as the customer? seeing the importance of larger operational needs, not just the technical experience. Please help me get a second interview. Thanks.
All right, so it sounds like you are going for a Platform Product Management position. So in a Platform Product Management position, which is different than a user-facing product management position, is that yes, your developers are the customers. So you definitely have to remember that. It also requires you to be a little bit more technical. That means that you should get up to speed about things like APIs and how they work and how they should be designed and understand data structures and algorithms and different stuff like that. But no matter what, if you are working in a platform, whether or not a developer is a customer, you still need great product management chops for that. So remember, you are still thinking about what the customer is. You're going to be thinking about how they're using the platform. And a really big thing as well when you're starting to think about how do we prioritize roadmaps when it comes to platforms is understanding the user facing side of the road map. Let's assume that this is a platform with user facing applications on top of it. If you are looking at what people in the company are building and digesting and using that platform for, you're going to be able to prioritize your roadmap against that to make sure that people are actually going to be using it. Now, if this is just a platform where the developers are the customers, but they're not internal to your team, I can't tell that from what you're saying, which is totally fine. We're going to give you both use cases here. If you are just building a platform for developers and then you're selling that platform, let's say it's a little bit different. Obviously, you want to understand what the developers are going to be using it for, how they're going to be running experiments, what kind of products they use, experiments on all of those different things to be able to prioritize your roadmap. But you won't have many dependencies internally on other teams, which is good. So two different cases. One, you're building the backend platform inside a company where people build stuff on top of it.
Then you got to match up your roadmap to their roadmap and make sure that you're building the infrastructure for them to get their things done. If you don't, a lot of people will not use your platform, guarantee it. Second side, if you're not doing that, you're just building a platform, we're going to keep that same mentality, but we want to understand the use cases that are people outside the customers are actually going to be using this form. So I would try to explain that, focus on those different areas. Also, it sounds like it's an experimentation platform, which is very relevant to product management. So talk about how product managers and developers should be running experiments. Talk about what you would want to experiment on. Talk about how you would want to run experiments to make sure they come out good and with statistically significant data. Those are the types of things that you can bring from your experience as a product manager into this interview to show that you know what you're talking about when it comes to experimentation and product management. I think a lot of people get really nervous going into product management in a domain where they've never worked there before. That's natural. I think we start to think that product managers have to be domain experts, but that's not always the case.
I think domain knowledge is really important in places like healthcare and finance and things where you have a lot of regulations, let's say, and you need to know how it works. That does not mean that people can't learn those domains as well. But when we're talking about an experimentation platform, you are a product manager, this is what we use it for. So you can take some of your experience there even if you haven't worked on a platform before. But I would really hone in on maybe what's the differences between Platform Product Management and user-facing product management to really land that interview. And that's going to be that there is no UX, so you're not usually working with designers, but you have to design those APIs and those ways that people plug into it better, right? That's the key with platform product management. You still need to have a roadmap. You still need to have a really firm understanding of what the customer is and how they use your product and what the use cases are and prioritizing it that way. You need to get a little bit more technical now and understand how developers work and how they integrate it and how they want to use the product. And you can do that by watching them, by talking to your developers, by understanding technology better and going online and just trying to get up to speed on all the different components of it. Those things are really going to set you apart. So have no fear. Really concentrate on the core aspects of product management and then maybe just be ready to talk about a little bit how they're different when it comes to a platform versus a user-facing application. And I hope that helps. All right, we're going on to our second question.
Second question. Dear Melissa, I have a young and inexperienced product team, but they are all learners and aren't afraid to take courses or read books to advance their skills. Do you have any recommendations of courses or certifications I should get my team to take? I would especially love some recommendations as it relates to QA and testing.
So you really want to start with that broad course, and then you want to go a little bit deeper. If you're looking for something specifically around QA and testing, I'd highly recommend looking at people like Lisa Crispin and Janet Gregory, who wrote books about Agile Testing. You're going to find a lot in the agile world about QA and testing, and that will be relevant, I think, for what you're looking for there. I would stress too, that product management isn't just about QA and testing, and it would be good for your people to understand it, but that's usually what developers are going to be looking at with continuous testing and continuous integration and all those different things. What you want your product managers to really look at is, do I understand the customer? User research, customer personas, empathy mapping, really diving deep on who they are and doing good customer interviews. Then you want to really look at how they can form and help their teams form solutions to solve problems. Now this one is usually where inexperienced product managers have trouble. going to want to break down why certain products work with them and how they can think about it. So they need to understand structures like what a platform is, different types of workflows, why reporting is necessary in certain situations, dashboards, visualizing data if your things are data heavy. They've got to get used to and start seeing different apps and different products and how people come to a solution about them. So that's going to help them start to think about concretely how do we solve problems that arise in the user research. In that area, you're going to introduce them to methodologies for discovering what that solution should actually be. So that's where your MVP testing comes in. Then you're going to want to make sure that they can work well with the developers and the designers. So you're going to look at that. How do they partner well together? What are facilitation techniques? Also with stakeholders, can they manage stakeholders?
How should they communicate with them? Good presentation skills. Then you're going to want to teach them about road mappings so that they can actually scope out different projects, know what to cut, know what not to cut, give them prioritization frameworks so that they can figure out what's the most important things and then line it up in a roadmap and then communicate that roadmap. And then you're going to want to teach them about metrics and goals so that they can measure their success. I think that's a really good way to think about structuring. an introduction to product management course for them. We do have a lot of courses at product institute where we do have a nice foundations course and then we go a little bit deeper on things like User Research or UX for product managers that don't have designers. So if you are interested in courses, I'd love for you to check that out. But if not, there are other ones out there as well. I think you also have to think about how do you build a community of practice around their learning journey, which is very important for people to be able to learn from more experienced product managers in your company or from you to discuss these things and actually put them into practice. So think about how you build that community of practice. Petra Wille is actually creating a new book on community practices. It should be out soon, if it's not out already. And it's going to tell you how to stand that up within your company. And that's how you should think about structuring their learning journey. I'd also caution you to watch out for certifications. I do not certify people in product institute that they can be an amazing product manager. Some people actually guarantee that, which I don't think is right when we teach product management. I'm not the person who's there every day watching these people perform and can put a stamp on them and say, yeah, they're a great product manager and we can give them the tools to learn and the knowledge, but then they have to put it into practice. Then it's your job as a leader to make sure that they can actually do that job and if not find another place for them in the company that's comfortable and up to their skills. So when you're looking for certifications, if anybody's like, oh, you just take this course and I certify that you're a great product manager, I'd be cautious of that. I will say right now that anything where people were just learning or reading and doing a couple different exercises does not guarantee they can actually perform the work. That's what they're going to have to do in their job and learn from.
We've had a lot of issues, I think, with agile certifications in the same way where people go to a two-day class, take a test, and then they're like, great, they're a fantastic scrum master, only for them to get into the job and not be able to perform. So I don't think certifications matter as much. In some large companies, people do care about certifications, but I don't think that's right. I don't think that's a great mindset. So I'd focus more on making sure that they learn the most important things to really succeeding as a product manager and not worry that it's a certification course or not. Really focus on those different buckets I broke down for you and then help them. Watch them. Have them discuss what they're working on with you. Make sure they have peers to actually learn with. Buddy them up. Let them go through different projects together. Talk about what worked. Talk about what didn't work. Bring in some expert speakers are always a good way as well to show people different sides of different stories. Study other companies, study other products. Do a product tear down together. I love that. Put a product up on the screen during lunch one day and just be like, let's talk about why this works and what we can improve, and then tear it down. Talk about who's the customer, how they're using it, what you think the use cases are, what do you think could be better if those are true, all of those different things, so that you can dissect it and learn how to actually analyze products. And I think that's what's going to make a great product manager on your team. So I hope that helps.
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 shops 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.
Next question. Dear Melissa. How do you know if the thing you're working on is actually a standalone product versus a set of features behind a packaging and pricing tier? What signals do you look for when determining this?
This is always such a hot topic. Everybody gets into these huge debates about, am I working on a feature or is it really a product? And I think from the standpoint of you doing product management, it doesn't matter that much. If you're a product manager on a team, it's very rare that you're actually working on a full product. You usually have a feature set that's going to improve that product that you're in charge of. And those feature sets could be huge. In really large companies, they're gigantic. There's many of them, and we need a lot of people to actually work on it. In smaller companies and in startups, you may actually be a product manager over the whole product. But how can you tell if it's actually different? Well, when you think about a product, it should be able to be sold standalone and solve the user's problem. So it's something that's desirable enough for them to just use that piece of functionality that you give them or whatever the bounds are around that. and they're happy with it. And they're like, great, that solves my problem. When we scale products, what we do is we typically then go, okay, let's solve a different problem and introduce another product. Or let's enhance this and make a feature set off of it.
A feature set is a piece of a product where if you were to carve that out and give it to a customer, it would not be enough to solve their problem. So if you want to know if you're working on a feature set versus a product, What I would do is look at the bounds of the thing that you control. and say, is there anything else functionality-wise, flow-wise, work-wise, workflow-wise, I guess with your customers? that is needed for them to realize the full value. And also, what is the full value? Right, like what's the job to be done that's being solved there? If you can't carve that out, and pretend to put a price on it and sell it to somebody, like think of it as a startup. If you were able to carve that out and make a new startup out of there and sell it and make money, you've got a product. If you can't, that's a feature set. So that's how I would really think about feature set versus product, but at the same time, you got to manage them the same exact way. You're managing a product end-to-end, looking at what's the value that we're optimizing here, what's the value for the customer, who is my customer, how do they use my product, how do they use all the different features to come together and solve their job to be done, or multiple jobs to be done. With the feature set, you're going to be optimizing it the same way, just on a smaller scale. so you still need the same mentality. whether you're managing a product or managing a feature set. but you want to think about how we actually think about selling. And that's what's going to tell you if it's a product or not. So if you can sell it and people want it, and they'll just buy that thing and not the other things, that's telling you you have a product. Now, when it comes to pricing and packaging, a lot of companies do some fun, like Mumbo Jumbo, where they do take several products and bundle them together, and then they sell them for a different price. Like it's under one price, right? That's all right. Because what we're doing here is trying to maximize profit we're making for our company. So the pricing and packaging actually has nothing to do with whether something is a product or a feature many times. But knowing if it's a product or a feature can help you with pricing and packaging. It can help you design the right package, the right price, because you'll know, am I selling a full end-to-end product or am I just selling a piece of it where people aren't going to actually buy this? So when you look at pricing and packaging for your product, you're going to want to think about why did we price and package it that way? Did we make a bundle of several products so that we can maximize our price and encourage people to try new products that maybe weren't getting so much attention? Did we do it so that we could sell individual products standalone because we have different audiences coming to our product pages to buy? All of these things go into pricing and packaging. So I'd say it's not really a hard and fast rule to just look at your package and pricing. It's not really a hard and fast rule to just look at package and pricing. It's not really a hard and fast rule to just look at packaging and pricing and say, oh, product or feature, this isn't bundled, this is bundled. So don't look at that. Really think about the value that you're delivering to the customer. And also think about if I were to spin this out and make my own company on the set, would people actually buy it? Do we have enough demand for just those pieces? So I hope that helps.
So that's it for today on Dear Melissa. I hope my answers were helpful to you. And if you have a question out there, go to dearmelissa.com and let me know what it is. I do this every other week. I tend to answer the voice memos faster than the written questions. So if you want to pop to the top of the list, leave me a little voicemail. I'll see you next time.