Leap to Scale
Leap to Scale is for technology curious leaders of service firms who want higher margins without adding headcount. Each week, Justin Davis and Greg Ross-Munro show how to turn firm expertise into repeatable, sellable technology products: SaaS, packaged workflows, and AI-powered tools clients can buy again and again. With AI, more of your know-how can be captured, standardized, and protected as IP instead of being rebuilt in every engagement.
We focus on practical decisions: what to productize, how to price it, when to build vs. buy, and how to use AI responsibly without risking delivery quality or margin. Clear steps, real tradeoffs, usable examples.
Leap to Scale
Intro to Product Management
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Click here to watch the video version of this episode on YouTube!
In this episode, host Sara Altenhoff is joined by Greg Ross-Munro, CEO of Sourcetoad, and Justin Davis, VP of UX at Sourcetoad.
They discuss a very important role in the world of digital product development: Product Management!
Tune in to learn all about the basics of Product Management, including:
- How Product Management differs from Project Management
- How Product Owners fit into Product Management
- How digital product management differs from traditional product management
- The phases of digital product management
Hello and welcome to Decoder Podcast. I'm Sarah Altenhoff, and I'm joined by some awesome guests here today. Would you like to go ahead and introduce yourselves?
SPEAKER_02Hi, I'm happy Halloween, Sarah. It's Happy Halloween. Can't see my microphone. I'm Greg Ross Monroe. I'm CEO of Source. Oh man. That's hot. I'm taking that pig hat off. Yeah, just uh, you know, podcasting and been building software for 20 years. So Cheers, nice to see you.
SPEAKER_01My name is Justin Davis. I am the VP of user experience over SourceTode. I've also been building software for about that long as well, and my uh my Halloween costume is not nearly as suffocating um as yours was.
SPEAKER_02You look great though. Both of you, but Sarah, you win with the princess on an okay outfit. Uh unbelievable.
SPEAKER_01Yeah, without a doubt. All the points. If you're listening to the audio only version of this, go find the video version right now, because it is not to be missed.
SPEAKER_00Yes. Very special episode today.
SPEAKER_02My son picked this out. This is a four-year-old picked out this pig, this completely terrifying scarecrow pig outfit. Um it sounds about right. What are we talking about, Sarah? Sorry, other than Halloween costumes.
SPEAKER_00Thank you both for joining me today. So we are going to be talking about a really fun and exciting topic for both of you, and I hope our listeners will think so too. Uh, product management. So why don't we start out by just giving a high-level overview of what exactly product management is? Um, Justin, would you like to kick us off?
SPEAKER_01Absolutely. It's one of one of my favorite subjects, uh honestly, product management. You know, product management is the I think of product management as a kind of full life cycle of seeing a product from kind of in in your head, either from conception or the different features and releases you go through, all the way through to getting that thing built, figuring out what it should look like, how it should come together, organizing those pieces, getting it out into the world, and then doing that loop again and managing that full process, right? And so everything around that, which is slightly different than project management, which we'll get to, um, but that's how I kind of think about what product management involves.
SPEAKER_02Yeah, I I I would I would tend to agree. I I would say that this probably um kind of a more traditional view of product management, right? Which is um, you know, we were, you know, 30 years ago we would start a business and we would say, hey, we're gonna make some widgets and we're gonna sell these widgets at the store. And um, and then that kind of product management that were was required to put those widgets together and make that a business, was then slightly different from like the first iteration of digital product management. And um and that's kind of the you know, our first kind of software products, the you know, you buy QuickBooks on a CD, uh, you you download the you download the freeware freeware version of some software, like I'm dating myself now, and then you uh you get people to convert by paying you you know the 150 bucks to open up the rest of the software. You buy Photoshop in a big box and comes with a manual and stuff. And then and I think then that digital product management actually changed a little bit in the way we look at that, even to the more kind of the SaaS model that we have that is pre prevalent today, right? Like I think there's been changes throughout the uh the history of product management. I I still think traditional product product management exists in like the world of things, and there's kind of a lot of uh stuff that is like well known and well understood about how to do it well in the digital realm.
SPEAKER_01Yeah, and I think I want to add to something that you said here because I think that what's interesting about what you said is that there was a time right in digital world, in the digital world that we're in right now, sometime in the late 90s, early 2000s or so, where the switch got flipped to SaaS software, right? And we went from the CD-ROMs and the installable stacks of discs to software that you could consume online uh completely. And that had a it had a modality shift in terms of how we consume content, right, and consume products because we we didn't install them anymore, we didn't we didn't interact with them that way, but it also had a really big change in how we manage products from the producer side of things, right? Those of us who are releasing software now, unlike traditional product management, where you had very stayed release schedules, very slow release schedules, because you gotta print it to a disk and you gotta mail it out somewhere. And then when SaaS came along and it became easier to update products on the fly and push things out into the world at any given moment, the the way the product management was executed changed quite a bit because the frequency of what was happening increased so much and required all of us who work in tech to really take a different look at how do we manage this thing that really is now this ever-living organism. It's not a thing that you design once and ship once, it's really this thing that's always living and breathing, and how do you then support that and give it a support system? And that's what I think of as kind of the modern product management that we have today.
SPEAKER_02Yeah, um, although I do kind of miss the days where I got like a CD on the back of a magazine, and then like I was excited to play the playable demo, but whatever.
SPEAKER_00No, yeah, the days of actually owning Photoshop was so nice.
SPEAKER_02Yeah, I have uh in in the off in the office we have um uh in the office we have uh I I was my outfit has like pellet BB guns that were like attached to me somehow. Oh wait, they're on my chair. There we go. So there's BB guns that are attached as part of my corporate um pig assassin, whatever thing. Anyway, point is uh these BB guns play a small role in this story, which is that at our office, uh the Sorcered offices in Tampa, if we've got this like big wall or these like shelves of um technology from a bygone era. And in the one of the bookcases is my copy of MS DOS 4.something. I don't remember which exactly it is, but it's like it came in like it was an IBM branded version, and which is kind of strange on its own. Um, and it is it has this beautiful canvas box which opens up to um all the five and a quarter inch floppies. We've got enough topic here, but five and a quarter inch floppies. There's like, I don't know, there's like 15 of them or something to install the OS. And all the manuals. But the box is filled with little holes and divots because my brother and I, when we were kids, used to use that thing as target practice. With the connection with the beam. No, we took the we we needed something that was just like it was a cardboard box to us, and now it's like probably a collector's item.
SPEAKER_01So by the way, I do remember from those days, you know, you would take the uh little three and a half inch floppies, the little the hard floppies, right? The three and a quarter, were they? I think three and a half. Three and a quarter, yeah. Three and a quarter. Um, and uh I you would take them and then flip the rewrite switch, and then you could use it as a disc that you could back things up on, right? So you could just like gank the software disc and overwrite it if you needed to.
SPEAKER_02Those are the good old days. Yeah, yeah. Sorry, Sarah. I think we derailed your question with our with our nostalgia.
SPEAKER_00Sadly, the days of materiality are behind us when it comes to digital products. Um well to bring us back to product management, um, why don't we talk through like what are the different roles um involved in product management? How does a product owner differ from like a project manager? Um, how do product owners fit into Scrum? How do all these roles work together?
SPEAKER_02I mean, yeah, it's a it's a very, very big question. I think it partly depends on the type of organization you are, right? Um if we should probably talk a little bit about you know the digital side versus in a in a traditional company that's building widgets still. Um I think ultimately the top of the you know okay, so a product leader in both companies, the person who's like the who's who's in charge of actually uh translating business goals, taking the strategy from the business, working out like how that should affect the product, um, and what we should be building, that person can be called a product leader, right? Uh they're kind of listening to the stakeholders, they're talking to the CEO, they're um and then they could they could be the VP of product, something like that. They could be the um chief product officer. Justin can probably speak to these things. I think he's had these titles before. Um but that role in a digital digital world is slightly different from I think in a widget-based world. And I keep using widgets as a um uh like I don't know, just an analogy. But in in the the widget-based world, the one big difference that you have is when you're trying to translate that's those ideas into an actual product, is you're looking at your typical kind of like uh market ramp and decline. What we would call like when when I went to college, it was called like the pro um like the product development lifecycle, as opposed to like what we now call the SDLC, the software development lifecycle, which is which is much more about engineering. But on the product development lifecycle, there was always this well, we would start with sales and marketing, and we would do marketing research, and then we'd move into ideation, and then the that would then move into the product, and then like competitors would start to enter the market as we started to sell, and then the product would eventually hit its peak, and then would start to decline, and we would need to replace it with the next product. Um, you know, planned obsolescence is kind of part of this product cycle, whereas those roles are different, I think, in digital product management and digital product development, because there is no planned obsolescence. There is, you will never buy, I know well, I mean, I don't think I will ever buy, and most of us will never buy uh QuickBooks uh whatever 10.2 where that we're on now, and we're gonna go to like 11.1 and we're gonna go to staples. Wow, look at all these terms, and we're gonna go pick it up out of that box and we're gonna bring it home. And as a result, and because it's never gonna happen because we just put our credit card number in and and it's always gonna be there, right? We're just paying for the constant life for the life cycle of the product to move in a different way rather than in a in a curve that kind of ramps down. We're just in a cycle, and that no one's ever gonna buy like Salesforce 2.0, and Salesforce isn't gonna promote Salesforce 2.0. And so some of the reasons, some of the like the some of the knock-on effects of that are actually like product role effects. I mean, Justin's been a Justin, you've been like a chief product officer. Um you know, like what do you think? Do you think like I'm am I crazy? Like, is the digital version of widget design different in its thinking because of no planned obsolescence?
SPEAKER_01Yeah, I mean I think it has to be, right? Because now you have a loop instead of a straight line in a lot of ways, right? Instead of a series of straight lines, right, of product releases, you have a loop that just continues going and going and going. And that really changes how you interact with product roadmaps. It changes how you manage things and how you it changes how you think about prioritization, measurement, feedback loops, all of these things are different when you change the shape from a straight line into a loop. And that's what that's what's that's how software is so much different than the widget-based stuff. Um, I was gonna say of your, it's not really of your because I mean that stuff is still done, but not not the way the software tends to be built anymore. Um, at least most of it, unless you're building like crypto hardware. But we were we won't go into the crypto hardware. Um I think like you know, from a role perspective, I think, you know, if you like super simplify it down, and y'all don't like don't like leave a bunch of one-star comments because I simplified this down too much, please.
SPEAKER_02I'm trying to just make a real um we're gonna like get really into the nitty-gritty between a product manager and like a product owner and versus like the user interface designer. Oh, we are okay, cool. Let's do it.
SPEAKER_01Fine, all the way, but I want to explain because I think a lot of times this kind of like project management, product management, like what is the difference between that? And it gets munged up a lot, right? And I think it's a helpful thing to understand where these kinds of things sit. And the way that I think of it, the way that I see it in my own head is I kind of simplify it like, okay, there's a business that needs to build a product, right? Well, you got a business that's gonna go make money and sell a thing, right? And make and do it that business stuff. And then you have engineers and developers and the people who actually build products, building products, right? Well, yeah, this is this is like the office of this is like office space, right? Well, why don't the business just why don't you just tell the developers what you need, right? Well, the thing is that there has to be some layers in the middle to kind of make sure that we're we're building the right things, we're doing it correctly, we're measuring it correctly, we know what we're doing as far as that whole life cycle goes. And I think there are two different roles in that stack product manager and project manager. And the way that you can kind of think of this is product manager sits a little closer to the business side in that chain. Product manager listens to what the business needs to do and thinks about how can the product accomplish these business goals? What are we measuring? How do we know if this works or doesn't work? When do we know if we need to pivot? When do we know if we need to change things? How are we collecting feedback from users? Those kinds of questions, right? And that goes into basically what are we building, when are we building it, and generally at a high level, how are we building it? The project manager is really about taking that mandate, taking that roadmap and that vision and translating it into what the engineering team needs to actually make working software. That means managing how the work gets done on a weekly basis, managing things like backlogs and priorities, and making sure that you're putting the right developers on the right parts of the product, right? And so those two roles work very closely together, but are both very instrumental in ensuring that the business to product translation, that link of the chain of links there, all works really well together.
SPEAKER_02Yeah, I mean uh I think that that that that linkage between what is being done at the day-to-day working level and like the very top-level strategic goals of the company is the the big difference between like a well-run product organization uh and like a poorly run one. You like and this is kind of where agencies like like software development agencies and in-house companies will kind of diverge a lot of the time, which is that if you want to build a a digital product and you are not a digital product development company, uh so for example, you're an in a technology-enabled company, right? Like you you you are a you sell um coffee cups, you are a you're like you're gonna sell like the coolest new coffee cup, and one of the things about your coffee cups is like there's gonna be like a huge online sales push, and they got a cool QR code, and you can collect them all, and like you can collect like digital versions of them. Your expertise is in selling coffee cups. You guys are traditional product development, you're a traditional product development company. Great. You have all you know how to build widgets in this situation, coffee cups, but now you want to add this like second layer for your customers to um to enjoy their coffee cups in a different way. This is I don't know, this is a terrible analogy or not. This is like I saw a coffee cup out of the side of my uh corner of my eye. Oh, then okay, well, I'm gonna just keep going with it. All right. So so you go out and you you have two choices. You can hire um, you can try and build that organ that that talent inside of you, and that's very difficult to build an engineering organization inside of a existing company that is not a digital company. Um, or you can go and outsource that, right? Let's just ignore for a second product companies, digital product companies that that is their product. The only thing they sell is their digital product. So you come in now that now there's two kinds of companies that you're gonna work with, right? Company A is uh they are a software engineering firm. All they do, they will take a specification that you write and they will try and translate it as best as they can into your new product. Or as a company that has their own kind of like their ideals and their ideas of product management and maybe product leadership inside that organization as well. And they're gonna be much more of a consultative, um, that's gonna be a consultative experience. They're gonna try and understand the vision of the organization, they're gonna try and understand who the stakeholders are inside of that uh company, they're going to try and mentor, teach, um, guide the actual business owners through the digital process, and they're going to then like help actually make the decisions, right? Those decisions are the small links in the chain that end up running down to the people who are actually ultimately going to be closer to that product ownership and then the logistically the product uh project management side. And so it it really depends on how high up the chain and how close you're how close you are to having a seat at the table with coming up with a vision. And the problem is that a lot of the time that the people who are close to like having the vision of what something should be are very far removed from like understanding what the actual moving pieces required to get that to market actually are. And so there's a lot of people in that chain to get that done. I don't know if you agree there, Justin or Sarah.
SPEAKER_01I think that's yeah, it's exactly right, right? That's that that's that link, the the the chain of links, right? And I think it has to you have to have it because you have to have you have to have somebody in the in that picture that can straddle one foot in the business objectives and one foot in the technical requirements and technical know-how, right?
SPEAKER_02And okay, so okay, so well, if if if I if I I run a car dealership. I don't know, no, no, no, I run a car franchise. And I got Kias and whatever, and I'm I want to and and and Hyundai's and I got a four-for dealership. And now I'm gonna I want an app, right? And I go I go and I'm like, well, okay, so I want to hire I'm gonna uh we've talked about this in the past. Like the first choice, you don't go and hire a developer. You don't go and hire one person because you don't know how to manage that person. You probably maybe you don't even want to hire a CTO first. Maybe maybe you do, maybe you don't. I don't know. But one of those first hires, we I always say should be like an executive position products person. What does that person look like to you? Like you were talking about roles, like what skills does that human being have?
SPEAKER_01Yeah, I mean, I think that that person um has to have a pretty unique mix of both the maybe not like so. Let's take your example here. Let's just go down the car dealership thing for just a second here, right? So sure, it's better than coffee mugs. I mean, I got nothing else.
SPEAKER_00Lamps?
SPEAKER_02You weren't really supposed to be lamps always a lamp. Halloween must, they're a Halloween chain.
SPEAKER_01Halloween chain. There we go. Spirit, the spirit comes and they want to know. Um yeah, so anyway, like so the car dealership or Halloween store, either one.
SPEAKER_02Sorry, Drelldian.
SPEAKER_01I think when you hire someone in, right, like you're not going to get somebody that comes in, probably who, and you probably don't want somebody who is like an who has who knows the entire car industry in and out for 20 years because they've worked in it for 20 years. You're probably not gonna find and because the people who know that probably also aren't product developers and know how to get products developed, right? So you're gonna hire somebody, you're gonna bring somebody into the team that the first skill is the ability to really be able to be empathetic and learn and understand the business and really lean into like what are the real goals here of the business? What is, what is, what is, what are they trying to achieve here, right? Not what do they want to build. And I I've written down this note that if you're hiring somebody for this, there's a difference in the questions that they ask. There's a difference between somebody who is just a developer, somebody who's just gonna build for you is gonna ask what do you want. Somebody who is a product owner is gonna ask what do you want to achieve. And those are two completely different um things. And you want the person who's gonna say, What do you want to achieve? That person has the ability to understand the business side. Understand what is important to a business, probably not at the level of the CEO running the car dealership, but well enough to understand the levers that are important, but also understands all the dynamics and the details that go into bringing a digital thing to market. What do we build this on? How do we ensure that it scales? How do we ensure we know how to track it and get feedback? And what are the best practices for design and what platforms should it be built on, right? And so it's somebody that has a good mix of those two things, the ability to understand a business and the passion to want to understand a business quickly, right? As well as, yeah, the thumbs up on the screen. Wow. Yeah. Go to Apple. And and also somebody who has enough technical know-how, again, they don't have to be a developer, but they have to be able to understand what are the what are the colors of paint that are available to me and how can I use them to get to this objective. That's the person that you're looking for in that role.
SPEAKER_02Yeah, and I I I think that when people go out looking to build software, especially for like a tech-enabled company, or like you, you know, like something like a franchise or a you know a medical health system or like a you know financial services company that already exists that wants to build something on like for their customers. That is the one thing that I wish they could know. That you don't need a development team day one. What you need is that you need what you need is that person.
SPEAKER_01Really, they're an architect. I mean, not like in the way that we we say software architect. I don't mean software architect, architect, but they are an architect conceptually. They're involved in designing the thing at a high level. Exactly. They don't have to write the code day one.
SPEAKER_00So why don't we now um run through? So we've talked about the different roles involved in product management. We've talked about the differences between agency versus in-house and how all these roles fit together. Uh why don't we talk through the different phases of digital product management? Um, I know that there's a lot in common with the traditional product management lifecycle, but let's focus on digital product management. What are what do those phases look like?
SPEAKER_02Yeah, I mean, uh this is going back to, you know, uh my B school days, which is like, you know, we get our uh we we start renting a product in the widget world and we um we start to grow excitement by growing a customer base and then we get early adopters, etc. And and and and then eventually there's you know there's like the growth stage, the maturity stage, the decline stage, and those are all I mean still to some degree valid. Um but in this day and age, I think it's quite different. I think that that loop that Justin was talking about, if you want if you want to go back into it, Justin is like that is that's the way though like it's not just the loop, but it's it's inventing yourself, like innovating yourself out of the n the next out of your competitors. Like what's gonna come and like eat you and and like to be honest, like most big companies don't actually do this, they don't they don't innovate anymore based on product life cycle, they go and do that through acquisition. Acquisition is at the large scale is product development, right? Like, and maybe that is a cynical view, but it I don't know, you just fight means just microproduct development, right?
SPEAKER_01Yeah because if you if you go back to the statement that it's about what do you want to achieve and what are the product levers we can pull, acquisition is a is just another lever, right? Build versus buy is another lever that the product owner might say, or whoever's in charge at that level might say that's the right way to achieve this from a product standpoint, right?
SPEAKER_02And it depends on your budget, right? Like if you're like, oh, okay, well, we'll go and buy we'll go and build this piece of software for like two million dollars, you know, for a startup, that's uh you know, an exorbitant amount of money. But if you but if if you could go and buy that for 30 million or for 50 million dollars from you go and buy an entire startup and you're GE, it doesn't matter. There's no way you could there's no way you could build that internally for $50 million. Like you would just be burning money. So yeah.
SPEAKER_01Right. Right. Economically makes more sense. Yeah, for sure. I think that like, and again, I think, you know, versus a kind of a traditional product life cycle, I think This is really with you watching you, you have you watching you adjust your pirate hat while you do this with passion.
SPEAKER_02Please continue. I'm sorry.
SPEAKER_01I'm really just trying to like keep this a little as closed as possible. Oh no, no, no, please let it out.
SPEAKER_00It's Tony Blair on holiday. I like Tony Blair on holiday.
SPEAKER_01Amazing. Amazing. Amazing. So I think that like the the thing about um the traditional product lifecycle, if you think about it, right? Like if you're gonna if you're gonna ship a coffee mug or you're gonna ship a car, right? You have to do a lot of the same things. You gotta come up with an idea, you gotta figure out if you should make the thing, you gotta design it, you gotta build it, you gotta get a part, you gotta put it together, and you have to release it, right? Like all of that is sort of the same, but there's a really big difference, and I think a lot of people miss this, which is that in software, you can change the car at any given time. And the thing that's important about that, and this is really, I think, hard for people to wrap their minds at around if you haven't done this a lot, is that like a lot of times you get really scared of sort of putting something out in the world. You're like, we need to get this perfect, we need to get this right, it all has to be checked, tested, da-da-da-da-da. Right? And in software, that actually hurts you more than it helps you to at uh at some point, right? Because you can keep changing the product while it's in somebody's hands. There's no other thing in the world like this. There's no other thing where you release a product and as someone's holding it, it can literally change as they're holding it. That is not a thing anywhere else. And that's what makes software so different. So the phases are similar, but the fact that it loops back on itself and it can do that on a daily basis means you have to think about the problem differently. Are the phases the same? Yeah, they're ish the same. There's some differences here and there. But the fact that they continue in that cycle over and over and over and over and over again changes how you manage the entire process. And when you come into it with that traditional mindset and you and you kind of haven't sort of made that turn yet, you end up falling into a bunch of traps that you that um you don't need to get stuck in in software development and actually end up hurting you quite a bit.
SPEAKER_02Yeah, I and I think um I I know that we we've talked about that we should do an episode on pivoting and pivots, but to like tack on like you know, we every product starts the same way, exactly like how Justin's saying. Like, so you know, you get ideation, you start with ideation, oh this is a great idea, whatever, and then like you move into like research analysis kind of phase, right? Like we're gonna, is this a great idea? We're gonna do some market analysis, we're gonna do some research, other competitors, etc. Then we do some design, and then we do some market testing that design, hopefully, right? Uh Justin's really good at doing this because like a lot of the time we like I in a lot of time in my career where I did not do this, and then like I learned, see like Justin doing user interviews with wireframes, blows my mind. Anyway, it doesn't matter. Then you move into development, all the same is like pretty like hey, we show our prototypes of the product to our potential customers, everything's basically the same from there. We do some testing, some QA, all the same up into there, but then it changes. And I think this is kind of back to your point, Justin, which is deployment. Once once we go into the cycle of of um releasing of product releases, product releases do not require anything other than an email. Right? We don't need to put out, we don't need to like create a new stamp in the machine in China to make the new Bobby and market a new version of the Barbie. Um we just need to sorry, that's because our lead our freaking uh head of engineering shut up is Ken today, by the way. In spectacular from the Bobby movie. Spectacular, phenomenal, just all the points. Um uh but anyway, uh so once it's in deployment, your feedback cycle changes, right? Usually what you would do in a product in a traditional product cycle is you would get feedback and then you'd go back to the design phase and you'd get like you'd move forward, and now that's a continuous cycle. The other thing that's different is normally what you would do is you would get customer feedback and like defects would be reported, and then you would like have a return slash like warranty cycle, which doesn't exist in digital product management. What exists instead is a maintenance and um application like support cycle. And what I mean by that is your yes, it is magical that the thing changes in your hand, and there's nothing else like that, but the thing in your hand that is presenting you that piece of equ that piece of magic also is changing, right? And so what you need to do is like um something that's not available and that's not required in traditional um product development is you don't need to account for the type of plastic that your toy is being wrapped in might suddenly change halfway through the the like deployment cycle, right? Like of but like if Apple or Android release a new i uh OS update, you need to know about it coming up six months before it does. You need to be testing your software on that. And we're talking about like just one thing in the operating system, and that's the most obvious. Modern software is built up of like one million Lego bricks, and each one of those Lego bricks is being updated all the time. You have to be ahead of that all the time. So you are in a maintenance cycle before you even get to market most of the time. You probably are not doing it at uh at first, but as you get closer and closer to market, you're doing it more and more and more. So more of your actual product development becomes maintenance rather than actual development. And then the other thing about that is uh the other thing that's very different, I think, is scalability. Right? If you are in traditionally, if you are building like a widget, you ramp your factory in, you know, wherever your factory is, like up, you but you own the molds, right? Please own the but by the way, guys, if you have if you don't own the molds to your machines or your parts, whatever it is, we've been through this before, you don't own the product. Um make sure you negotiate with your factory to own the molds. I know that's a weird thing. We've built lots of actual hardware, but um so when it c but when it comes to digital the digital side, scalability is oftentimes the last thing you think about. Unless you're Bank of America or you're GE and you know that day one you're gonna have 10 million users using the thing. Most of the time you have the luxury of saying, well, we don't have to worry about scalability day one. But as your product ramps, you're gonna have a choice to make. Maintenance is gonna be required, ongoing maintenance and support for like keep making sure that runs on your and neurosystems and your ahead of security patches, etc. But you're also gonna have to worry about the scalability because you probably didn't build the system to make it run for 10 million users, because that would be an insane waste of money to build something to make it run for 10 million users. You probably wanted to make it run for 10,000. And then the second that you start, you just can't ramp up with more, like you don't own the molds, you just can't stamp out more with more factories. You can throw server power at it, you can do whatever, but eventually it's gonna break, it's gonna be a dumpster fire. And so you need to plan the product ownership, your product ownership and your product development teams need to understand that scalability is a thing that is planned less at the beginning and is more important as you ramp up.
SPEAKER_01Yep. And again, just to wrap that up, another thing that makes that so different than the traditional marketing or traditional product development process, sorry, is that it the thing about technology is your distribution is now uncapped in theory. With physical products, you have like a natural cap. You can only fit so many units on a truck, you can only fit so many things in a distribution center, you can only manufacture so many things on a line at a time. You know, we talk about things going viral, blah blah blah, right? And depending on whatever. We won't talk about that word and the loadedness of that word. But the fact of the matter is that software can on one side scale very quick and do that very well, to your point. It can also catch you off guard, right? And if you're thinking traditional factory mindset and you're thinking, well, I mean, we can't, like that can't happen, right? Like it can't, the servers can't melt, like whatever. And then all of a sudden the today show picks you up. Yeah, like all of a sudden you have demand curves that are very different than you would have in a in a traditional business. So where and the product suffers uh sometimes, if you haven't thought about that scalability shelf, but so does the organization support, other things like that that also get hit as a result of that. So yeah, you're playing in a very different space when you're playing with these kind of products.
SPEAKER_02Oh yeah. We hit all of now we've just terrified everybody.
SPEAKER_01Yes, we we have. But it's awesome.
SPEAKER_00Wow, this has been super fun, and I learned a lot from both of you today. So uh just a quick recap. We went through what exactly product management is, how it differs in the digital realm versus the traditional realm. Um we talked about uh software as a service disruption and how that changed everything. And we also walked you through the phases of digital product management and how uh that also differs from the more traditional product development lifecycle. Um so thank you, Greg and Justin, for joining me here today. Um thank you, listeners, for joining us as well. And if you would like more insight into the world of software development and digital product development, then subscribe and follow Decoder Podcast. And with that, we bid you farewell.
SPEAKER_02Yeah, yeah, but if you but if you do if you can actually see how good Sarah's costume is, you should do that.
SPEAKER_01Tune into the video, y'all.