In this Dear Melissa segment, Melissa answers listeners’ questions about internal products and prioritization.
Show Notes
In this Dear Melissa segment, Melissa answers subscribers’ questions about pragmatic versus ideal product management, internal product management, and determining how to build products for a two-sided marketplace.
Q: Do you think there should be a difference between ideal product management and pragmatic product management?
Q: What kind of metrics are you looking at when customer-based internal users are forced to use the software? There's no LTV, CAC, revenue models, or any of the normal user metrics in B2C or B2B.
Q: We're building a product for renters, our end users, and landlords, our customers. I'm struggling with prioritizing whose problems to solve first. Is it better to build for our paying customer first, or do we build as fast as possible for renters but risk more turnover with the landlords?
Resources Melissa Perri on LinkedIn | Twitter MelissaPerri.com
Episode Transcript
Hello, and welcome to an episode of Dear Melissa, from the Product Thinking Podcast. The lines are now open, and we're ready to answer your most pressing product questions. Which prioritization framework would you recommend and why? Hi, Melissa. Do you have any suggestions on developing a product strategy?
Whoa, whoa, whoa, whoa, whoa, that's a lot of questions. All right, let's dive in. Hello, everyone, and welcome to another episode of Dear Melissa. This week, we've got some really great questions about strategy, about pragmatic versus ideal product management, which I think is very interesting. Great question there.
And then also about internal products, which is a topic I get asked about a lot. So I'm excited to dive in and answer these questions. So let's start off with one of my favorite questions I've gotten so far, which is about pragmatic versus ideal product management.
It says, Dear Melissa, I read your book and all other great ones available on product management, but I see a lot of noise about how the principles and methods in these books can't always be practiced in the real world. Do you think there should be a difference between ideal product management and pragmatic product management? Oh, I love this question.
You know, my answer is probably not what everybody expects, but so in my book, I write a lot about ideal product management, what we should be doing. But in practice, I know that you can't always work this way. And sometimes you make a deliberate decision not to work this way because it's in the better interest of your business.
I'll give you an example. I've worked with a lot of companies that sometimes had to forego following the roadmap exactly and make a deal with somebody that, you know, they would not have prioritized immediately because it was going to save their company. It was going to get them a lot of money. It was going to open up a strategic partnership.
Now the difference between ideal product management and pragmatic product management in this case is that if that type of deal is the exception, you're going to be fine, right? Like if that's a once in a while, we have to make a hard choice and not follow the ideal path. That's normal product management, right?
Like you are making choices every single day in product management. You are making decisions as a product leader. And sometimes those decisions are not going to match up with theory. In theory, should you follow the roadmap? Yeah, you should follow the roadmap, right? You should follow the strategy.
You should stay the course and focus. In reality, sometimes you make a deliberate decision that says, you know what? I think it's in the best interest of our business, up for our customers, maybe to win over somebody on the sales team, to foster relationships, to say, you know what? We have to make an exception here and we have to go a different way.
The problem is if your exception becomes a rule, if you are always making exceptions for why you can't do ideal product management, that's when you get into trouble.
Many companies can work the way that I outlined in my book. You should be experimenting. You should be learning about your customers. You should be setting strategy. You should be doing product operations. You should be building a culture of learning all of these wonderful things. You might not be able to do it right now.
You might be working your way there. You might be at a point of transition where your company is getting started with product management or you are, you know, building your product management team or you're transitioning from, you know, an older way of working in IT services or something like that and trying to stand up better strategic product management. Are you going to be able to do ideal product management out of the gate?
No. That's not practical. You're going to have to start small and build up that practice. But once you get there, should you be practicing ideal product management? Hopefully, hopefully you're doing it like 90, 95% of the time. That other 5%, right, maybe you have to make those trade-offs that we just talked about because there are business decisions that are bigger than the ideal, right?
There are factors that are in play that are not just about following, you know, a rote recipe. And I think that's true for any organization. So the way that I would judge it and make sure that you're not straying too far off of an ideal path is look at the things that you're making exceptions for. Are you always making an exception when it comes to experimentation, for instance?
Like if you're always going, well, we're a really big company and we can't get in touch with our customers, so I guess the exception should be that we're not going to do customer interviews ever. Like, no, that's not good. That's not good. You need to be able to talk to your customers. And in this case, it's not like, hey, we're special.
We can't talk to our customers. You have to figure out how to put that into place. And I hear the we're special thing from companies all the time. I'm going to tell you this right now, and you probably don't want to hear it, but every company thinks they're special and you're not. Do you have to adapt product management to fit you?
Yes. But there are certain things that every company needs to do.
Talk to the customers, set a strategy, experiment to learn. The experiments that you do run could be drastically different. A B2C experiment is going to be different than B2B. But should you be testing things? Yeah, you should be testing things. Should you be learning about your customers? Yes. Should you be setting success metrics?
Yes. Should you be building roadmaps? Yes. Those are things that don't change company to company. How you execute on them might differ. And depending on your stage and where you are and the maturity of your practice, those things are going to differ. So you have to look at what are we doing at our core product management practice?
Are we doing modern product management where we're focusing on outcomes and learning about our customers and iterating until we find success? Are we doing those things? Or are we saying, well, that's not really pragmatic. Let's make an exception where we never do those things. That's bad. That's a trap that you can get into.
And you'll end up in the build trap when you do that. So I think that's the way to look at it. Are we doing good product management 99% of the time? The exceptions that we do make, are they always for the same thing? Or are we using an excuse that, oh, that just won't work here, or, oh, we're special so we can't do that, to get around doing those things?
In that case, I think that's a culture problem. I think that's a problem with your product management practice. I don't think that's good. I think you should be examining that and really looking at how can you bring those things back into your practice. But yeah, you're going to have to make trade-offs sometimes.
I've seen many chief product officers make deals that they didn't necessarily want to make, but they had to give in at that time because it was the right thing to do for the business. You know, you can only make a plan that goes so far. You can only decide things to a certain point. But relationships and people and circumstances of businesses, they all come into play when it comes to execution.
That's why we need experienced leaders in our organizations to make those tough decisions. And I think we also have to make them explicitly. We have to sit down as an organization and say, we know this isn't ideal. We know this isn't right, but we have to do it this time because X, Y, and Z, and we decide going in there with very clear eyes that this is the right thing to do in this situation.
In that case, it's totally fine. And that is how business gets done every single day. But if you're doing that every day, if you're doing that every week, if everything seems like an exception, then you're going to run into problems. So it's a really good question on that. Pragmatic product management, definitely a way to go, but don't fool yourselves into thinking that everything's an exception to the rule.
That's my thought and advice there. All right, we're going to move on to the next question about internal product management, which I really like. So, dear Melissa, I'm an internal product manager, and there isn't much out there related to managing an internal product.
What kind of metrics are you looking at when a customer base, internal users, are forced to use the software? There's no LTV, CAC, revenue models, or any of the normal user metrics in B2C or B2B. Great question. I don't know if a lot of people know this, but I got my start doing a lot of internal products when I was at OpenSky.
Internal products was my thing. That's what I did. I ran all of the backend e-commerce tools, and all my users sat around me. And there used to be a line of everybody in the company at my desk asking for new functionality. And that's because my products sucked at the beginning, and it got better as we kept going along, and I got better at doing product management.
But I love internal products. I think they're so valuable to companies. When you're building an internal product, you have to remember that there's always value to internal products. And the trick to figuring out what is the right metrics to use for success, or what are the right metrics to measure, is getting back to that value.
So everything in our business comes back down to cost, and it comes back down to revenue. And internal products could do either one of those. A lot of times we only think that they do cost, but they could also be revenue drivers as well. So you have to figure out, is your internal products a factor of saving costs, or is it a factor of driving revenue, or sometimes it's a little bit of both.
So let's think about that, right? The tools that are cost savings, they usually save time, they streamline operations, they automate things, they make things more efficient. And you can measure efficiency usually in time savings, in cost of people doing this, and being able to deliver value to the user faster.
But sometimes tools that look like internal tools also boost revenue. So here's an example, right? Let's pretend you work at a bank, and you are creating a way for the advisors at the bank to suggest better products to their clients.
Now your user in this case is the advisor at the bank, the person who works with you. But they're advising different products using the algorithms and all the tools that you make to suggest something better for the customer. So there's a direct line to better revenue or more adoption of products right there.
But you may get into the trap of thinking, well, my user has to use this, and they are the advisor at the bank. And you're like, okay, maybe they do have to use it, but maybe they don't, right? Maybe you think they have to use it, but maybe this person is looking at your product going, hey, it actually sucks.
And it doesn't help me make better choices or better decisions on behalf of my customer, because I know them better than the software knows them. So they're actually working around your internal tool to make those recommendations themselves. And they're not making the same recommendations as you suggested.
Oh, interesting, right? Now we've got different things to measure. Now we have to go out there and figure out, is our product actually performing and suggesting better recommendations for our customers?
That's where I would start, right? How do we break down your product that you're building into what is the value for it? What is the value for the business? What is the value for the user who's actually using it? And then try to extrapolate that into what to measure. You can measure usage as well, but you're going to have to also monitor people, just like I mentioned with the advisor in the bank, to see if they're working around your product.
I have met so many teams where somebody is working around their product. They're like, oh, they have to use it. And they go out in the field, and they sit with their customers, and guess what? They are not using it. I've watched so many people. One of my more recent ones was working in healthcare, where we had doctors writing things down on paper because the system was so hard to use.
So this happens all the time. You may think it doesn't happen to you, but it does happen all the time. Now there's also satisfaction metrics.
Just because somebody has to use your product doesn't mean they're satisfied with it. And low satisfaction of using your product can lead to churn in your company. A lot of people leave companies because of the tools they're forced to work with. They try to find other places where they feel more empowered, and they could do better things with it.
So what about that? Are you satisfying your users? Are you giving them better ways of working? I think it's so important to treat internal tools just the way that we treat other tools that are going to external customers. You have to think about satisfaction, and adoption, and giving people the power to do the things that they want to do in the best way possible for them.
So I think you can use a lot of similar metrics that we use for customers, but also just bring it back to what the business is looking at. You don't have to talk about lifetime value or CAC, but there is revenue models associated with your product. There will be cost models associated with your product.
And it's your job to trace that line all the way up to the business and figure out, what is my thing driving? Is it driving costs? Is it driving revenue? Is it driving both? And then back that out into the user actions that occur to have that revenue or cost be generated. Right? Back that out. And those are the things that you need to measure on a daily basis.
And then the outcomes that you would measure are those cost and revenue things at the end of the day. And then also the outcomes for the value for your user. Are they satisfied? Are they able to do their jobs better? Are they able to do the things that they need to do to further the business and to further the value that they need to provide to their own customers as well?
So that's how I would start there. But I love internal products. I think they're really important, but I do think there's this dismissive kind of notion when we teach product management. I hear it a lot because I just work with tons of big organizations who go, well, we do internal products. Like the stuff that you teach, it's more for external products.
And that's not true.
You know, just as I said, you have to think about these things in how do they apply internally? And how do I think about my users internally? Just the same way I would think of my external customers, how do I provide them with satisfaction and with tools? Now, again, the way that you execute or the tools that you use as a product manager to satisfy internal customers might vary, but the process is the same.
You still have to do discovery. You still have to deliver. You still have to iterate. All of those things are incredibly important. So make sure that you're really looking at that. All right. Let's move on to our last question. So it says, hi, Melissa. Our company is three months old and we're building a product for renters, our end user, and landlords, our customer.
Our mission revolves around renters' needs, but we want landlords to pay us. I'm struggling with prioritizing whose problems to solve first with limited dev resources. We're starting as a B2B for distribution's sake with a long-term plan of transitioning to B2C and going directly to renters.
So is it better to build for our paying customer first? Or do we build as fast as possible for renters, but risk more churn with the landlords in the meantime? Thanks for your help. Okay. So here we've got a two-sided marketplace, and this is a very, very common question and something that we have to make a decision on early on when we build startups.
So you've got two-sided marketplace, two different customers. The way that you figure out who to build for first is who is the highest risk of not using this thing. So you've got to think a little bit demand and supply, right? Will landlords not come if we don't have renters? Will renters not come if we don't have landlords?
The answer is yes in both cases. So now you have to figure out how do I get just enough on my platform to start facilitating these connections, right? And then you have to figure out which one is in danger of churning the most. And the person who's in danger of churning the most is going to be the person who doesn't have as strong of a problem as the other person in the marketplace.
So if landlords don't have as strong of a problem of finding renters to take their building, I'm assuming that's what this does, but let's say that they have tons of people coming to rent from them. They don't have a problem. This is really more for the renters, right? In that case, landlords are your riskiest customer because you've got to build it so that they want to use it.
You've got to make it so valuable for them that they look at it and say, oh yeah, this really helps me. I'd be willing to get off my other solutions and come over to this one. On the flip side, it could be the renters, right? Maybe the landlords have a really big problem trying to find renters and the renters are like, oh no, I don't have any problem.
I just use Facebook. I go on something else to find it, Craigslist, whatever. Now you've got to get the renters on the platform and you've got to make it really easy and sticky for them. So while you want to satisfy both sides of the market, the one that's not going to adopt it because they don't have as strong of a problem, that's really where you want to spend a lot of your time.
Because if you can't get both people to the party, there will be no party, right? Your party's canceled. Everybody has to go home. So how do you spend just enough time on the ones that have a strong problem to satisfy it, to get them on, to make them really want to engage with this, but then how do you spend a lot more time doing the discovery and working with the other side so that they go, oh, this is something I need, right?
They have that light bulb moment. In order to learn who's who, you're going to have to do a bunch of user research, right? That is the only way to learn about this. So you've got to figure out what is my competition? Why do they like it better? What is the value points that they're really hitting on?
And then how do we compete with that? How do we differentiate ourselves and market ourselves in a way where we have more value than those other options? And that's how you're going to get that other party to come over to your product to get in the party and start working with you. So think about this in terms of risk, right?
What is the riskier party to bring on board?
That's where you should spend most of your time, but you're not just building one side of the marketplace. You want to build both, but the other part you spend less time on and you come back to that as soon as you got a very strong product for the riskiest party. So I hope that helps. If you have any more questions for me, please submit them to DearMelissa.com.
I love answering your questions. I think it's a great way for everybody to hear the answers as well. It satisfies my need of scaling this advice to a lot of people. So I hope you're enjoying it. And if you are enjoying this, please leave a review on our podcast on either Apple Podcast or Spotify or wherever you're listening, as that helps a lot more people find our podcast and listen to it as well.
So make sure that you're subscribing. We have an episode out every Wednesday. So next week, I'm really excited to have Ben Foster on the podcast. He is the chief product officer of WHOOP, which is that really fun fitness band that's making the rounds these days.
Ben is such an experienced product strategist and leader, and we're going to be talking about his new book. So if you love product strategy, you want to hear more about product strategy and how companies form it, Ben is the person to listen to. So make sure you subscribe to the podcast because next Wednesday, we're dropping that episode. And in the meantime, submit all your questions to DearMelissa.com. Thanks for listening.
