Episode 68: Answering Questions About Product Management Outside of SaaS
In this Dear Melissa segment, Melissa answers subscribers’ questions about product management in software vs hardware, SaaS vs e-commerce, and within the governmental sector. She covers the differences in product strategy, things all of these product jobs will have in common, how to figure out which tools apply to your industry and product type, and how to measure impact over time for products where results could take years to come by.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: Do you see a difference in the strategic and tactical delivery of customer value between a digital product and a physical product created through discrete manufacturing processes? Are there any major pitfalls that I should be aware of as I work with the product roadmap and product lifecycle management of a non SaaS product? [2:01]
A: Yes, there are definitely differences between physical products like hardware and software. There’s also differences between non software products where we sell things like credit cards or pharmaceuticals and we can use software to harness the value of those products and make them better. When you're thinking about the product development process for somebody who works on the software side in any of these industries, it's going to be very similar, but you're gonna have to integrate into the full product… I'd really suggest you go out there and try to find somebody who develops hardware products. [2:29]
Q: What are some key differences in SaaS product management teams versus product management teams inside of retailers? What advice would you give for someone in the new role who is also becoming a VP or an executive for the first time? [9:02]
A: Remember that not all the tools work in your context - you have to figure out what the right tool box is for your context… The difference between enterprise SaaS and e-commerce is probably the way that you're thinking about selling and monetizing your products. In e-commerce, you're selling physical goods that get shipped to people; in enterprise SaaS, you’re selling software itself so your revenue is derived in e-commerce from different products… The other thing about e-commerce is that a lot of it has been fine tuned already and there's a lot of best practices out there. Sometimes we're creating the wheel depending on what our product is and what the landscape looks like for e-commerce. In a retailer, you might want to go out and study best practices. [9:25]
Q: How do you find good metrics when the effects of an improved road maintenance program might not show or pay off until years or decades later? How do we handle these kinds of outcomes when trying to measure the impact of our products? [12:12]
A: For every product out there, no matter where you work, there's outcomes. Sure, revenue is super straightforward, but there are a lot of products out there that don't go off of revenue. There are things that just aren’t monetized, and we value their business on other things and other outcomes. Government would be like that, so your outcomes always have to be for whatever you help your constituents with… The biggest thing here is that there's a long delay in these outcomes for your people… Good tracking will help with that, but you have to have leading indicators that show that you're on the right track for those types of things. You might not be able to prove all those leading indicators yourself, but through research and collecting the data and measuring all those things you can actually start to see trends that lead to better outcomes. [12:52]
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of dear Melissa. Today. We've got three questions around different types of products and the approaches for them, physical, digital retailer, SA private companies, public companies, government, all those wonderful things. So that's what we're gonna dive into today. So to kick it off, wait, scratch up.
But I also wanna REM, but I also wanna remind you that you can submit all of your questions to me as well@dearmelissa.com. We go through these every week. We pick out the ones for every other episode, and I'm really excited to see what you are trying to learn and what you're struggling with. So hit me up, let me know any of your questions. All right. Let's dive into today's topic. Dear Melissa, do you see a difference if any, in the strategic and tactical delivery of customer value between a digital product, for example, SAS and a physical product created through discreet manufacturing processes in short, from your perspective, are there any major differences, pitfalls that I should be aware of as a work with the product roadmap and product life cycle management of a non SaaS product?
Well, yes, there are definitely differences between physical products like hardware and software. There's also differences between non-software products like non SaaS, where we sell things like credit cards or pharmaceuticals or something else, right? And we can use software to harness the value of those products and make them better. Now, when you're thinking about the product development process, for somebody who works on the software side, in any of those industries, it's gonna be very similar, but you're gonna have to obviously integrate into the full product. There's gonna be differences in the way we set strategy. For example, the strategy of the overarching company is probably gonna be very different than the product strategy. Whereas in SaaS companies, product strategy and company strategy might be a little closer together. They might manifest each other a little bit more, but the way that you do your processes as a product manager on a team are gonna be very, very similar.
There's a few key differences that we wanna look at, and I'm gonna talk about hardware first. Now I'm not an expert in hardware. So I'd really suggest you go out there and try to find somebody who develops hardware products. Um, but I'll tell you what I've seen from talking to people who do hardware and from knowing people who have manufactured, things like printers in the past and all that different stuff. Um, hardware, much harder to iterate, obviously, but you're gonna follow the same overall methods. And this is true for any type of product management process, too, right? Like we're understanding the needs of our market. We're understanding the goals of our business. We're understanding what our customer's problems are, doing deep research there, narrowing down on what's the right problems to solve. We are going to be testing and prototyping to figure out what's the right solution to solve those problems.
We're gonna be putting it out to our customers, getting feedback on that iterating, and then, you know, obviously launching it and making sure that it goes through the normal product life cycle, um, scale up stage into maturity, and then eventually it'll go into decline, right? Like that's typical of any type of product that we build. Now, when you do hardware, obviously you're not gonna use the same testing methods you would in software. I'm not AB testing a printer like that's expensive. I wouldn't really be doing that, but people still prototype these types of things in hardware. They're still building different models. Even if you look at like rocket ships, they're building scaled down models of these types of things. They're trying to make sure that it works right. They're testing every individual component. These things are just different in practice, but same step right of testing, iterating on it, trying to figure out what that solution is.
It just costs more to build the final solution. So we really wanna make sure that we're doing all of our testing upfront, um, before we build that thing, because especially if we're building like a rocket ship, it better not fail. right. That's, that's a big problem. So we wanna make sure that we're doing that way more upfront. Whereas in SaaS products, we do usually have a little bit more leniency to, um, fix bugs after they're shipped to, um, test a little bit lighter because we can deploy updates through the cloud or, you know, even if it's on-prem, you can eventually just deploy a, deploy, an update there. Software is just different in that way. So testing becomes incredibly important when we are doing hardware or, um, anything that costs a lot to build the final product. Uh, so we're just gonna have to test a lot more upfront. Testing cadence too, you know, is gonna be different.
So usually you're gonna have a much higher, you know, a much bigger testing team that you're gonna have to work with. You're probably gonna have to be really specific about the requirements for testing in a product where you can't iterate on it as much. You gotta make sure that you actually think through all of these things before it's launched. So there might be a little bit more waterfall in your eyes, but the idea is that you bake in your iteration cycles before you get to the final product. Now, there's also a difference, I guess, with hardware too, when you think about innovation, um, sure. We'll update some of the products and, you know, go like model one, model two, model three. Um, but a lot of times too, when you get to an innovative point, you like literally throw something out and start over and it might look completely different.
So at the end of the day, right, the process is overall similar. Now, if you're working in a non SaaS company like banking, pharmaceuticals, all those things I was just talking about, um, you're gonna usually be able to iterate a little bit better than hardware, but not crazy amounts sometimes because, uh, it depends on how fast you can deploy and how much we're iterating on, right. It might be harder to iterate on like a specific credit product that you've offered out to a market compared to iterating on the website. So there's a delineation between like what we can iterate on and what we can't iterate on. So that's something to be aware of as well. Um, when you're think about product roadmaps and product lifecycle management on both of these things, I think it follows very similar threads. Product roadmaps might need to be well way more defined in a company that's more complex, either non SaaS or hardware, because you have other people who are dependent on you.
So project management is probably a lot more important here, product management, especially in a software perspective, can't oversee everything, right? You can't usually oversee everything that perspective. So you've got a lot more dependencies to think through. At the end of the day, the nature of building these two things is just different, right? And you have to figure out what is a toolbox that I need and methods that work for e-commerce for instance, are not gonna work for building printers and that's okay. But that, but really as a product manager, it all stems back into the way that we do our job. Following those steps that we just talked about, right? Like it, we always start from what's the need, what's the customer. Who am I building those for is my solution, the right solution to solve this problem. Like we still need to think through all of those different things, but the tools that we use at each point to actually execute on those steps might be different.
And that's what I would say is probably the biggest difference between these two things. It's also the length of time to make these decisions. It's the length of time to get things out there. It's the dependency management, probably stakeholder management around that. That's all gonna be different as well. But I think the core of our job as a product manager is the same at those areas. I would just say like, you can either think you can either do two things. One don't think every advice out there applies to your context. Um, and I think that's huge, right? Like take what works for you and leave what doesn't. Um, but two, you might wanna look at other industries and what people are doing and say, can I actually apply that in my space to be more innovative? And if the answer is no, that's fine. Right? You can just move on. But if the answer is yes, now you've got an opportunity, right? To set yourself apart, to try new things, to maybe be more, more successful in your industry too. So I would say don't just dismiss everything that you read out there in context, but also know that not everything works and that's totally fine that doesn't make you a worse product manager or the industry worse or anything like that. But you can learn always from different industries. You just gotta take what works for you and what, and leave what doesn't.
All right. Second question.
Dear Melissa. I recently joined a tier one retailer, but previously I was a senior director of product for an enterprise SaaS commerce product. What are some key differences in SaaS product management teams versus product management teams inside of retailers. And what advice would you give for someone in the new role who's also becoming a VP or an executive for the first time. So I think some of the things I said in the previous answer are going to, uh, going to apply to this. So yeah. Remember that not all the tools work in your context and you have to figure out what's my right tool box for my context. Now let's specifically dive into e-commerce here. Um, I've worked in e-commerce, I've done B2B SaaS. I've done a lot of these different places. I've worked in banks. all over the place. So here's where I've seen the differences in an e-commerce retailer.
You've probably got, well, sorry, in a retailer in general, let's start there. You've got e-commerce side and you've got the internal tools and your supply chain and all that wonderful stuff. Then sometimes if you are in a physical location, you're gonna have the software that teams use to check people out, all that stuff, inventory management, all those things, internal tools can usually be managed the same around most organizations. So that's like a pretty typical build the product. You have your customers go talk to your customers, make sure that you're going into the stores and seeing how they're using it and all that wonderful stuff, stuff we typically do as product manager. Now, the difference between enterprise SaaS and e-commerce is probably the way that you're thinking about selling and monetizing your products in e-commerce you're selling physical goods that get shipped to people in enterprise SaaS you are selling the software itself.
So your revenue is derived in e-commerce from different products. So in e-commerce our goals are usually around conversion around, um, getting people to make a purchase. That's gonna be very different than SaaS products, which might be more about enhancing people's overall experience or workflow tools or things that help them do their job better. That's fine. There's goals at the end of the day, right? Like if you're a great product manager, figure out how to hit those goals, just know that the goals look a little bit different in your different contexts. Also in eCommerce and retailer too, there's usually more focus on, um, marketing and, uh, awareness, right? So like you need to be finely in tuned with how growth marketing works for like SEO and bringing people to your website. And then you are responsible for helping to convert those people into a sale. Now e-commerce has been done a million times out there too.
The other thing about e-commerce is that a lot of it has been fine tuned already, and there's a lot of best practices out there. And B2B SaaS, sometimes we're, you know, we're creating the wheel depending on what our product is and what the landscape looks like for e-commerce in a retailer, you might want to go out and study best practices. There's usually a lot of reports that give you data on like how people buy, um, how you can convert them. What you're gonna want to do, which is, uh, a little bit different is figure out like, where is my opportunity to innovate, right?
And like, where should we be innovating? Should we be innovating, you know, on our e-commerce site? Or should we be innovating on the backend? Like what's where do we get more leverage if we turn to software for cool products and it might not just be on everything and that's fine, like you can borrow and use the things that have already been proven to work out there. And then what you're gonna do is try to figure out where do we have an edge and that will help create your strategy for, um, product management, for software, product management in these organizations.
Next question, dear Melissa, I'm a new product management in the governmental sector and I'm struggling with measuring value of what we do. Private sector seems easy one way or another. You always seem to be able to quantify your impact in money in government. It seems so much harder to find meaningful, accurate, measurable metrics, healthcare. For example, you can always measure in the number of treated patients per time or money, but that's not really the point is it. Isn't good healthcare rather related to the quality of life of a former patient. And how do you measure that or maintenance the effects of an improved road maintenance program might not show or pay off until years or decades later? How do we handle these kinds of outcome when trying to measure the impact of our product?
So for every product out there, no matter where you work, there's outcomes there. And sure, like revenue's super straightforward. We just measure revenue easy done, right? But there's a lot of products out there that don't go off of revenue. They're not measured by revenue. Um, there's things that just haven't monetized and we value their businesses on other things, other outcomes they actually provide government would be like that. So your outcomes always have to be for whatever you help your constituents with. You can always survey those people later. You can always go out and ask them about it and see how it's impacting them. Once you bring somebody into the software in your government sector, right? Like you have their information. How do you track that over time? But I think the biggest thing here is that there's a long delay in these outcomes for your people, right?
Uh, it's like it could be years, it could be decades until they might feel the full effects of these things. Now, good tracking, making sure that you can follow up with them will help with that. But also you have to have leading indicators that show that you're on the right track for those types of things. So how, you know, you might not be able to prove all those leading indicators yourself, but through research and, um, and collecting the data and measuring all those things. You can actually start to see trends in, okay. If we help X, Y, and Z, and these people do X, Y, and Z, that usually leads to a better outcome. I think that's there too, but I'd also suggest for you to go and study people who do work in the government sectors. Who've been doing a lot of this work too. So Dana Chisnell has been working in the government sector for years, um, as user experience researchers and running these workshops and helping usher through a lot of these different programs, she'd be a great person to go. Um, you know, study, read her books. She has a lot of books out there about usability testing and future tense, texture and all these different things. She writes a lot about this stuff. So go study that.
Then there's people out there who have been practicing product management in government sectors for a very long time, like Kathy Pham. Um, so Kathy has a lot of stuff out there about, um, product management in the government sector. She talks about this a lot. She talked about biases on our podcast a while ago. It's another person that I would go look for as well. But I think at the end of the day, you do have to set up structures and no matter what business you're in to help measure the impact that you created. So yeah, for healthcare, the point is trying to make sure that they have a great quality of life of the patient. Is there a way that you can keep in touch with these people and monitor them? Um, we do have like systems in place for that, right? You'd have to figure out where are the touch points of that patient with different doctors throughout their patient lifecycle?
Um, as a government, you know, person too, maybe you create that system. That's also something to think about, like, not just what is out there for us to harness, but what could we create in the government when we have a centralized view of different things to help make sure that we're following our citizens. That sounds creepy. I don't mean it in that way, but I mean like we're following our citizen's journey in life to make sure that we're providing the most value for them. I would really think about what are the opportunities we have to make a difference there and to connect into other things so that we can track, um, success of our programs. So it's not easy. I don't think measuring any kind of outcome is easy and it usually has. It's a lagging indicator, right? You usually have to wait a very long time to measure certain outcomes, but that's okay.
That's the nature of it. And the whole point of measuring data, and this is something to remember measuring outcomes, measuring data is so that we can make informed decisions about what success looks like and make the next decision on what we're going to do. So you need just enough data to make decisions that's, what's important there. So we don't have to be paralyzed, waiting for success every time let's look at some of those leading indicators, let's look at context and let's talk to our customers and let's get out there and study our markets and our people and all these different things let's do that so that we can make more informed decisions. That is really what our goal is as a product manager and yes, product management, you know, I'm looking at all these things, we got hardware, non SaaS type things. We've got retailers, we've got government, like product management is harder in some places than others.
That's okay. Right. We all have the same foundation of what we do. We all have the same benchmark. Let's say of what we do. And that's why we're here. Um, and the context in which we're operating will change and you probably won't stay in the same industry for the rest of your life. That's okay. I've jumped around to pretty much every industry that you can possibly see out there. Um, a couple more, I would love to see as well, but you know what, the foundation of how we do our work doesn't change as product managers. And I could tell you that from working in all these different places, what we do and how we do product management does not work. Um, how we get the data sometimes is harder. How we measure outcomes sometimes is harder, but we still do the same things over and over again.
So you just have to understand that and you have to try to figure out how do I do this within my context within my system, um, and stay grounded in the way that you do product management in the fundamentals and then stay flexible in the way that you do other things, right? Like that's what we have to do to make sure that we can flex into different environments, different markets, different industries, and different contexts. And that would, that's what makes powerful product managers too. So I'd encourage you to not like, feel completely overwhelmed by these choices and by these different things. Um, there's always a way to figure this stuff out. Um, but it doesn't, it's not necessarily easy, but what I would say is try to really find other people out there who've been doing it that you can lean on as well. So thank you very much for these questions today. And again, if you have any questions for me, go to dearmelissa.com, we'll be back next Wednesday with another episode of a product thinking podcast.