AA141 - Minimum Viable Product

Minimum Viable Product as made famous by Eric Reis in the Lean Startup is barely recognizable and likely unusable due to the proliferation of different concepts associated with the term.

Enterprise Agility Coach Om Patel and Product Manager Brian Orlando discuss and debate what MVP is, what it's supposed to be, and try to discern any usefulness from the jargon that seems to have coopted and repurposed "Minimum Viable Product!"

0:00 Topic Intro: MVP
0:18 Why Talk About MVP?
1:16 Discussion Framework
3:14 Users/Market Want Everything
5:18 Arguing on the Dropbox Video "MVP"
10:31 Terminology Hang-ups
13:02 Platform Compatibility
15:18 Release Planning (Alpha, Beta, Production)
17:18 Laundry List of Assumptions
20:09 Agreeing on the Obvious
21:43 The Case Against Expansion of the Term MVP
24:47 Assuming Risk (or Gambling)
27:12 Skipping the Learning
29:48 Wireframes
30:41 Arguing on: What is a Product (Again)
34:03 Running Out of Money
35:44 Summary: Test Feasibility
39:29 Wrap-up
= = = = = = = = = = = =
Watch it on YouTube

Please Subscribe to us on YouTube
= = = = = = = = = = = =

Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = = 

Transcript

0:00

Eric Reese in the Lean Startup defines the MVP as the fastest way to get through the build, measure, learn, feedback loop with the minimal amount of effort. Its goal is to test fundamental business hypotheses. First of all, I just want to point out how fun it is to say hypotheses and plural. I wanted to talk about, the topic of MVP because I realized we've actually not had. An episode on MVP and also I've been seeing a lot of posts and I've been reading a lot of discussion between product managers recently talking about MVP in the understanding that it is sometimes required to fully build many features And call it an MVP and I want to challenge that idea in this podcast. I want to explore it. I want to give it a fair shake and explore it in this podcast. Yeah, I like that. So I agree with you. I've seen a lot lately out there on the worldwide interwebs where people say, let's just rename what used to be called MVP. And call it something else. You know M V E minimal viable experience minimal viable, , hypothesis. I've seen so many different variation. I lose track of viable features. Yeah. Yeah. Product increment. I've seen a variation that like so many variations now. I see this topic being covered in two points. One point are the people that are for expanding the term MVP and making the term MVP basically elastic you make it as big as you want, make it as small as you want. It's up to you. Everyone's different. We're all special and unique and we're all different. Om, that's what I'm saying. As opposed to be, as opposed to a focused definition of what it really should be and what it's supposed to really enable, right? Right. Yeah. As a, and the alternate of Hey, do whatever works for your company. As long as nobody's complaining and you still got a job and money to burn. Like, Hey, it sounds good. As opposed to, as opposed to having the goal to test a fundamental business hypothesis. yEah. So I would like to segment the podcast into two parts, one part for expanding the term and the other part for limiting the term. Okay, so I guess one for expanding the term and the other against it. Against it, yes. Basically what I'm saying. I think the juicier part is to bring up all of the reasons for expanding the term. Because as you can already tell, I am not a big fan. Unless you have an infinite supply of money and patience from leadership. Which doesn't really happen all that often outside of specific segments of industry. You know, we talked about this before the podcast how you could possibly get away with it. Although it's getting more difficult if you're in the government. space. Yeah, right. I was reading today how the Department of Homeland Security is now adopting agile . So it is proliferating. But anyway, yes. So if you can get away with it, okay good luck to you. Most of us cannot. I Mean, even they can't be honest, like it's Yeah, that's, that's how like the, the big boys you know, the big contractors that are out there who everyone should know that I'm not going to name right now can get a contract for a hundred million dollars and then two years pass and they've delivered no software like that's they're still working on MVP. They're working on MVP, but I agree with you there. Days are number two. I think they're walking, taking a long walk of a short pier, honestly. You know, it won't be long before they will be extinct. So let's, let's dig into some reasons , the first one that, that people normally bring up in this category is I Can't make an MVP with one feature because my users or my market, demand everything all at once. Yeah. So how do you, how do you know that they demand all of that at once? I mean, what's the rationale behind that? Is it just a gut feel on your part? Well, I've told you. See, I just told you. You've told me, so I believe it. I have the budget. I told you what to do. If you have the budget, I'll be happy to burn it for you. Or on your behalf. This is so like, again, I just outlined an assumption. Yeah. My assumption is a user won't use our software. Won't be interested in our software. Won't look at it unless it has quote all of the features. So again, you could break my assumption into many, many little assumptions of like which feature, right? Right, which users? What kind of users? At what point in their journey? Come on, we can go down this path all day long. You need to validate each and every one of these micro assumptions. If you're not doing that, then you're going to basically get stuck pretty quickly, right? You'll come across a pothole. That's gonna send you flying. Right. The other question I would bring up here is why are you trying to enter a market with an MVP that's flooded with competitive products? You know what I mean? Well, you may have a niche, right? And let's just grant them that you may have a niche, but then if you do, you already know what the others aren't doing. The other competitors in the space. Right. Yeah. So focus just on that. I want to point out, like you started off like debating what I was about to say, you're like, you're like, you're like, you can enter a crowded market where everyone's has the same features. Basically, they're all wrapped in the same. You know, pretty packaging, but they don't have one thing that you've outlined. So you build your MVP around the one thing that they don't have, and then you start adding the pieces that they do have the products to kind of crowbar them away from their current offerings. So again, like we're back to like, we started with like, well, my users have expectations. They had, they need everything all at once, all at the same time, but also they don't have this thing. Right. Right. So what are you going to focus on first, right? Let's cut over to another one that I think is legitimate, which is investor interest. This is the, this is the, the Dropbox example. In the book he gives an example of Dropbox. In the Dropbox example he gives in the book, that Eric Ries gives in the book, he's talking about Drew Huston, the CEO of Dropbox. He believes that file synchronization is a problem that people have that people don't realize is a problem. And In the book he outlines that the investors that he pitched the product to were not keen He said Houston learned when he tried to raise venture capital in the meeting after meeting, investors would explain that this quote market space was crowded with existing products and none of them had made very much money and the problem wasn't a very important one. Drew would ask, have you personally tried those other products? When they would say yes, he'd ask, did they work seamlessly for you? And the answer is always no. So he realized that he, he basically had to train the investors of what they were looking for, what seamless would look like. And that's, that's where the Dropbox video of their product, which of course was a fake. Well, yeah. Also drew was resolute in his conviction that that a seamless experience is what's going to sell. Right. And he just had to do a, I guess, a job of convincing the investors that that's exactly what was needed out there. Right. And they didn't see it that way initially. Yeah. Yeah. Well, again, the video that he narrated, the video, the three minute demonstration of how the technology would work. His it, it wasn't working finished it's not like he built all of Dropbox and that was not even an MVP at that point, right? You don't have a P well, there's no product his, his, his MVP was an MVP , from the perspective of you're you're testing business viability. Mm hmm. You've shown your investors They're not convinced of your business viability so You need to go develop a better MVP to convince them of your business viability. Again, it's, it's, it's because he was trying to get money from investors to go build a product, but at this stage, his MVP was about proving feasibility to investors and they didn't understand the market. They didn't understand the experience he was shooting for, so he created a video demonstration that helped them put the put all the pieces together. Yeah, yeah, the important thing here is the video is not the MVP. Right, the video simply illustrates there is a market need and the investors can clearly see that through the video because he, he did put the video out that was not the product though, right? Initially it was just enough to make sure that the investors bought into the concept so they would invest a little bit more. I think it was the product with a video was the product. I think it was because he was, he was selling that product to the investors. Well, okay. So that wasn't the Dropbox product for the consumers is what I'm saying. Yeah, no, absolutely not. No, it wasn't. No, you, it was really just a way to convince the investors. You make a really great point. Which I hadn't thought about up until right now, which is what audience is this? A quote product of this MVP for right because again, a lot of these pushback items that we're outlining, assume that you're building something and handing it over to the person that's going to buy it right? Not necessarily. So in, in this case, this, your MVP, your product was a video, one time video, you mocked up a bunch of screenshots and made it made magic happen to look like it was working as a product. So that you could demonstrate the experience to someone who could not. They, they, they couldn't understand the story in their head, so you had to learn a different storytelling medium to help them understand that this business is viable. Yeah. So you can take a risk to go build a real product, to go explore another user. You know what I mean? Like that, that's really the product leap though, from my, from my definitional sort of stance. When he created the video, it wasn't a, even a pre MVP, if there's such a thing of Dropbox. That was just a way to convince the investors to give him enough money so he could create. The former right to, to create an MVP or pre MVP, whatever it is. Just enough money to keep going, basically. Yeah. And that's, that's a good point. Your, your investors have to be convinced, even if you are completely like you believe in this, they don't, what do you do? Do you, do you spend the money, which you don't have, by the way, in creating a very small sliver of functionality and show it to your investors. I mean, rather than do that. You know, drew came up with this idea of creating a video and it worked. That's a product to me. Well, it's a product for a non paying audience in that case. I, I a hundred percent agree. Well, actually. Although they did pay because they invested I was gonna say I guess are paying because they're paying by investing in What your company could be in the future? I mean, this is also this is This is a Silicon Valley love story here. It is a little bit different than it's a little divorce from reality however, the the product to pitch the investors to get the money Is all that mattered at that point agreed that that's all that mattered. Because without that investment, it's the only product that existed. It's the only product that existed at that point. anD then later they, they developed an actual, like what we think of in, in. You know, software development as a quote product product, but it certainly was a product from the perspective of getting money, getting money, right? Exactly. But the real first MVP for a Dropbox. Wasn't the video necessarily. It was probably just the first version that did synchronization of files. I'm hung up on the definition of what a product is, I guess, in this case, a lot of people get hung up on that. Yeah. When I was researching this topic viable was a big one that people got hung up on and product was a big one that people got hung up on because of what we're talking about. Investor interest. There's also hang on, let me, let me pivot down here. There's also a, there's also a category that people will bring up about monetization to say if you can't turn around and sell what you developed as is, it's not an MVP again, that, that, that talks about that, that product part of it is you can actually take money from your MVP people will bring up and say, well, if you haven't built, The ability to take money from your product or to be able to maybe, maybe you're not in a, in a, in a B2C market, maybe you're in a B2B market. So if you can't actually sell it to another company and then receive money for it, like that's not an MVP, you need to build more features. So the, all the amount of features you have to have together with a circle around it. In order to receive money for it. Now that is an MVP because that is a quote product. There's a lot of people that say that too that's, which is sort of on in line with what you're saying, which is like, well, the video is not your product because it's not really a product product. All the features together that you actually could sell and an end user will pay for with a credit card or whatever, that's. Cause that's the way Dropbox works. We'll, we'll pay for it with a credit card. Whatever you need to get to, to get to monetization. That is your MVP of your product. Probably one of the most significant ones that I make me kind of sit on the fence. To think about as well, because if this is the way you look at it of what a quote product is, then I, I kind of will agree with you, although I'm still firmly in the camp of, nope, the video is, the video is a product. So, so as a PowerPoint presentation that you pitch on VCs. Fine. Right? I mean. If it knocks out your business viability assumption and check and ticks the box, and it's a PowerPoint. Yes, I'll go with that yes but the monetization one is a really interesting topic it is interesting, but what if you're a non for profit, right? Are you still that interested in monetization or are you interested in doing other things like expanding mindshare or? You know, doing good for the social good, basically. It just depends, right? It depends on your context at the end of the day. I'm struggling to think of an example that is a non for profit or non profit scenario here. I can't think of anything. I can't, I can't. Abandon ship, abandon ship. Women and children first. The other one that people will push back on is compatibility with different platforms. When I was doing mobile apps earlier in my career they may say an MVP requires you to put out both an Android and an iOS release. We were kind of talking about this before the podcast. We were kind of talking around this point, whether it's positive or negative. Usually what you would do is you would either survey the customer, we, we, it was like a B to B to C type of offering, and we'd survey the, the businesses that we were doing business with to say, hey take a poll, it's on you, part of, it's like part of the contract, it's on you, take a poll, figure out what the percentage of Android iOS users at your company are, and then when you pay us for like a white, this is like a white label app, when you pay us for an app and we give you the MVP experience. Basically, it's like, when we spin off a white label app, it's got, you can sign into it, you can get basic functionality, but there's nothing customized, and we'll add customization later as the relationship develops and pay us more money. But the MVP version, this spun off, relabeled white label app, if they said, our customers are 50 50 Android, iOS. Well, okay, you probably need both. In your MVP unless, unless, or do you, unless you wanna, you can try with one. What we, what we would do is we, we would ask them to, to have a test pool of users for the MVP, and then we would usually, we would say, Hey, it's better if you choose one operating system or another. Sometimes they would be adamant about both but then they would pay extra sure for this This reminds me of some of the the apps early in their Lifecycle where they would only work on Android and then, and then he would say you know, a an Apple version is iPhone or whatever. Yeah, it's coming later. There are still apps like that. Yeah. Apps that only work on iOS apps that only work on it. There's still apps like that in the app store right now. So there's ways to test what's basically what we're saying, right? Yeah, and if you have no information I mean, if you have no information and you're in business, you probably have, you probably can do your network traffic analysis and see what percentage of your users are on iPhone or Android or whatever. Just try to get an idea of which side you go. I mean, for us, it was like. It was like, it was, it was the data was very clear. It was like 75 or 78 percent Android. And then a small percentage of Apple and other, other devices. So for us, it was like Android all the way, you know what I mean? It was, it was an easy decision. Yeah. The other one people will bring up is a regulatory compliance. Well, I can't test the new thing. I can't even consider it until you've got all these features required for regulatory or whatever. And that one, I kind of I'm, I'm, I am less inclined to consider that a legitimate reason for an MVP, unless your MVP is a regulatory product, I guess. There's very few of those. I, I agree with you. I think by the time you consider the regulatory compliance type of requirements, you've moved way past MVP, way past MVP. At the point where you're talking about regulatory issues or you're talking about really deep features of an application, way beyond basic features of application. Yeah. At that point, you're talking about release map or release planning or story mapping or something like that. That you're way beyond MVP. Absolutely. You're into like lanes of other releases in the future. And you could say like, Oh, the customer doesn't want to pay for it until you get to. This release, but also there's a whole different discipline other than MVP for dealing with this stuff. It's it's alpha beta GA that you know that kind of stuff so so if you're if you're creating a new product Again, assuming you're creating a new product, if you're creating a new product and you have all these regulatory features that must be in before your customer will adopt it in production or whatever, like cool, no problem. Go with test users, have them in quote production until a point where you feel you can cut over and you have your GA set of features. And then you go GA when you want to go GA, that'll be your milestone and you can, you can have Gantt charts or whatever you want, to make your compliance people happy, but alpha beta production, release mapping, all that kind of stuff, story mapping. That's a whole different podcast. And it's also, it's a whole different discipline, which I feel is conflated with this MVP stuff. People are talking about alpha beta production as if they are well, beta. MVP, alpha, MV, p. Yeah. You know, so limited. MVP I don't know, , I'm throwing my magic. I haven't even heard people talk about pre MVP and post MVP and all of this stuff where the actual middle of it. Isn't even well defined. There's a couple more points that I wrote down here that aren't, they aren't very good, I, I, I'm going to let me list them all because they're all going to sound like assumptions when I say them. I assume that our competitive advantage has to be part of our initial features, otherwise no one's going to use it. I, I assume that there needs to be some sort of basic end to end user experience in order for anyone to use it. I, I assume that in order to attract any early adopters, I've got to have feature X and feature Y and feature Z that like all of these. Are all assumptions all of which if you're if you're doing a story map I did a bit of research before we stepped into this podcast And a lot of people were doing Story mapping, so think of like columns with epics and stories under that and they were like drawing lines around these are all the minimum stories that have to be in the MVP, right? How they know that is beyond me, but okay. Well, again, like I feel every single one of those epics, or whatever you want to call them, features, whatever you want to call them, every one of those columns, that you decide one or more stories or work items or whatever you want to call it must be. In the MVP for every single one of those, I think there should be a business viability. MVP attached to each. So if you have, let's say for example, you have seven features that you want in the MVP and you and you and you go with your team and you par that down to three. Three, absolutely must have great just banger features. That's gotta be the MVP three, like three, three full features, fully working in the code, full database, tested, et cetera, et cetera. And then you say you have to do that. Right. So if you come to me, at Brian and Om's software development company, like Brian and Om own the purse strings here. Therefore we control the agility in the organization. That's a, that's a statement on another podcast, by the way. And you say, okay, Brian and Om this is my story map, and these are all my features, and these are my stories. And I've outlined here with the circle, these are all the stories I want in the MVP. And you see that out of the seven total features that we talked about that we needed in our application I've only taken stories from three of them to say that this is our MVP. And Om will say, you did a great job, good job kid, you're doing great. We're really proud of you, Brian Ohm's development company, software development company. And Brian will say. What have you done to validate what have you done to validate that what you say, what you assume are the must have features are viable for the business? Yeah, that's pretty much what I would say. I would just say, well, you say feature one, seven and nine or whatever it is. How do you know? How do you know that that's what's needed in the MVP? What data do you have that shows that, right? If you haven't done the due diligence, you don't have data, then it's just conjecture. And I'm not investing in that. So go, go do the research, go figure it out, and then give me the data points. And we'll make a data driven decision on any of those features. It may not be three, it may be only two, or it may be three. Five, but we'll know that because we'll have the data. Well, what would you say to the counterpoint of this is so simple that we don't need to validate it. It's, it's so obvious that we don't need to validate it. Again, it's a simple, that's a simple one to kind of come back on it and just say, well, if it's so obvious. Why is it obvious? What data do you have that shows that this is a real thing, right? If you can't show that to me in hard data, then I'm going to basically dismiss it. mAybe. I was going to say, maybe we would dismiss it, but also like at Brian Ohm's development company software development company, we we value speed as well. So maybe there may be like a convincing case. From a PM uh, I could, I could see leaving the door open to say a convincing case from a PM might uh, I could see cases where a convincing enough case gets put together that makes us take on the risk of not doing the business viability test. It, it, that may happen. You'd have to evaluate that on a case by case basis. Right. You'd have to say, well, why this feature and the flip side of it, the, the cost, right? Yeah. We'd have to look at that and say, okay, well, this is so, this is such low hanging fruit. We should do it. Well, okay. What, what would happen if we didn't do it? Right. And based on that discussion. Sure. I might, I might renege and say, Oh, okay, well, maybe we'll just do that because it's only two hours worth of work or whatever it is. So it's a case by case. Yeah. I would also point out the opportunity cost equation there, as I often do here, right? In those two hours, what else could you have done that's more valuable? So the, so we, we walked through a few categories for the expansion of the term MVP. So let's let's, let's talk through a few categories against the expansion of the term MVP. So like aside from, aside from which I realize is not in my notes today about the dilution of the term mVP were basically I can't use I can't say MVP anymore goodness. Yeah. Well forget about the synonyms of MVP, right? Yeah, I can't I can't say MVP anymore. I can't use it because it's so it's everyone has a different expectation So some people think it's like everything In the world altogether, all the features before the customer will buy it. Some people think it's a slideshow. Some people think it's a video. Some people think it's a, a website with nothing under hood. Some people think that it's just a, a site or application. Riddled with technical debt barely stands up on its own that I, that I've seen that more than once. Oh yeah. And in actuality, I've seen that pitch as an MVP more than once. I hope there's some savvy VCs out there that look through that and say, what are you asking me to invest in? Yeah. Well, I mean, the, if you're, if you're lifting lean philosophy. The actual lean philosophy not like expanding just past Eric Reis's book and actually looking at like Toyota production. Sure Like a quality is not compromised with any of these features even with the MVP. Well, he's not compromised So it like again if you're if you were if you're having that problem Where you're picking up a piece of software and it's so bug riddled and they're calling you an MVP. I mean, there are some wools being pulled over some eyes here in disguising poor quality as an MVP. Yeah, and whenever I've seen that, which has been fairly often actually it's always because the organization or the people in it are prioritizing delivery dates, hard dates. Over quality, right? But think about it, no matter how you define your MVP, M XP, whatever the middle initial is, do you not care about the customer's experience? Right? So if you're putting out things that are buggy or riddled with defects, etcetera, that experience goes south immediately. And this is, this is something that I've seen outside in the outside of the world of of software to the shoe manufacturing company that put out a cheap version of the line of shoes that they eventually had as a way to test the market. And obviously they, they cut some corners, but the glue is what Came undone. Ironically. And they knew that glue wasn't strong enough to hold up if if it's out in the wild and they still released it because they wanted to see if people like the design, the fashion statement, right? And all of that, the fit. Well, yeah, they did. But most people complained about the fact that it comes unraveled within three days of trying it on. So you can look that up. I won't mention the name of the company as we don't do that here, but yeah, definitely. So it just goes to show you where do you care about your customer experience at MVP level? I would argue it is more important to have a positive experience in that usually goes with built in quality. Again, , I'm not saying that I don't understand any of the, the four expanding the term points that we've outlined. I completely understand why people do that in the, in the different organizations. Like some, some founders or some VPs or some executives that run companies are. We'll, we'll say like it's my business and I'll take on the risk and I I say that I know what the customer needs and I know I just don't want to spend time I will take on the risk of overbuilding, for example, I'll take on the risk of over, but we've built too many features and we made too many assumptions and we were going to gamble. It's not even risk because it really is a building building too many features is gambling It's not a risk. Like if you build the wrong features and nobody's your product you lose you lose everything right a gamble like a risk is You've got alternate that you you're weighing options And you've not bet everything on one idea or one assumption. A risk is different than a gamble. I agree with that. So as long as the gamble isn't just simply, you know free will or somebody's highly opinionated decision if one saying is if it's a calculated gamble and there's the willingness to take that on by by the VCs or the funder funding people, right? People that are putting the money on the table. Okay, fine. Go with that, right? But quickly test that too. And then come back and say, Okay, we took a gamble. Here's what we learned. So you can pivot if you needed to. But if it's just a Somebody saying, well, I think they will buy this. Like, I don't know. Having said all that though, there are products out there that didn't really have a market need. They just happened to be popular. You know, like the chia seeds or whatever. I don't know. The clapper. Was there really a need for a clapper? So you clap your hands and the light comes on? No. Were they popular? A lot of people bottom 1999 operators are standing by. Anyway, so yeah, I mean, there's like pros and cons to either side. But most the majority of the time. All of those gambles they really need to be vetted and validated. I was going to say, don't, don't talk to me about lighting in the seventies and eighties. Like having to walk into a dark room and turn the light, turn the light on. Like that still blows my mind. Whenever I see a housing from the seventies that has like no lights anywhere over your head at all, right at all, you have to walk in and turn a lamp on, turn on the lamp. Um, Oh man, I think one of the points against that I think is not going to be overcome with any of the points that we talked about for is, You're skipping a chance for iterative learning. If you're not vetting, the MVP is like the story mapping example where you're like, Oh, we got the, the VP comes in and says, Oh, no customers, no customer will sign up unless we have these. And no customer will even look at it because that's what we're talking about. We're talking about getting a customer's attention. We're not talking about taking money potentially. But this is what you should be. That's what we're talking about. Mindshare. No, nobody's going to let you in the door. And you'll never have a chance to get anyone's opinion unless you have all three of these features built top to bottom, front to back, etc, etc, etc. And they're completely functional. And people can sign up and you can take money from them. Okay. Sure, there's that, but also that, like that statement is in and of itself an assumption that I can test, I can go try to get people's time and find that all the doors get slammed in my face. The point here is they have given you assumptions, cemented them in stone, and told you, you can't question these assumptions. The idea of build something quickly, whatever the minimum is, each of those stories Or features or epics or whatever it is each of those columns that I was outlining earlier Each is an assumption that could be vetted for business viability in In its own little ecosystem without the rest of the features with its own user that it's targeted toward. Yeah, I'd, I'd agree. And I would say instead of saying that it could be vetted, it must be vetted because otherwise, like you said you're just pinning yourself into a box there and you're losing I think that's where you're going with this. You're losing the valuable opportunity to learn, right? From those little increments, right? There's little features. And also we haven't even, we haven't even dipped into, this has been a very like producty, businessy type of podcast. We haven't even talked about especially if your team is new, if you go and get a bunch of engineers or designers or whatever, and you go through the trouble of making them cross functional and having them work together and getting them to talk directly to customers, maybe they all come from different businesses, or maybe developers aren't used to talking to customers, you're taking away that muscle, the exercise. That builds that muscle of vet every idea, test all the ideas, the best ideas win. You're like, no, no, no, don't, don't, don't build that muscle. Go back, go back to the basement, kid. I'll tell you what to build. Yeah. That's a terrible thing that you're doing. It really is. It really is. You want your team to come up with all the alternatives and keep every one of them alive as much as possible. Right. Until they find a reason to kill one of them. Or more iteratively that that's probably the best way to do it, because if you do it that way, you're more likely to be data driven. You kill an idea that you're keeping alive because the data says it's not viable anymore. And also I feel In that environment, the complexity is kept at a minimum level. So, you're building an MVP, even if it's again, you were talking about oh, it could be PowerPoint and the user doesn't know. Like, I don't think there's a difference between, honestly, I think PowerPoint probably takes more time, but PowerPoint and Figma, like the easiest Figma mock ups, Figma is pretty easy to mock up and you might not even need to mock up Figma. You might be able to use low, low fi wireframes to prove like a flow through an application. For example, we did this every time we built a mobile app, we would start with low fi wireframes to vet out. Yep, absolutely. And those low fi wireframes can. iteratively become mid fi right before they get you know, so I like those kinds of tools where you can do this sort of thing quickly. I guess back in the day we used to call it rapid prototype design or something. But then tools like Figma, specifically that one I know about all of that work that you do isn't thrown away. It doesn't go to waste. Cause it lets you change that into code, right? And so you still get a running start, but you get a start with something that you've tested, that you've proven out with the field, right? You can have focus groups come in and look at that. They can poke buttons and they do certain things. It's not a product. It is a, it is a prototype at that stage, but it's still reacting to the customer as a product would, you're just testing that those scenarios out. I mean, it's a product. Once you put it in front of a customer, uh, like I keep pushing back on your terminology, like you're, you, you, you want to bend what, what product is. I see. That's where you're kind of anchoring in conversations. It's a product in that it facilitated, it was a product that facilitated our learning about the business viability of this feature or this, no doubt. Listen, no doubt from a, from the organization standpoint, it's a product that did something good for you. Right. But from the customer standpoint, it is not a product because not in production. It's a prototype at that point, they can come to the table. They can play with it, but they're not using it when they start using it, like really using it in production, even if it's limited scope at that point, it becomes a pilot, right? That's a pilot it's in production. And now you're way past MVP at this stage, but. Just for definition, when it's a pilot, it's actually in production that they can use to do their business. It isn't just in the kind of lab, if you will. Yeah. See, I don't, I don't agree with the def like I don't agree with crowbarring. The, I mean, I I'm on both sides of this. Actually. I'm saying, I don't agree with your definition of product in this instance, because the product. Again, could be the Dropbox video, like it could be really anything, but also I understand your, your definition of product being, I actually have to be able to, it needs to be an actual usable, functional, like a customer could buy it, product, customer can pay for it, customer can pay for a product, I understand, but the version of product that I'm talking about, the Eric Reese version of product is all, all I need is, Something to validate the business hypothesis, the viability for the business. That's it. That's, that's, that's it. That's the only product I need right now. And if that is not maintainable in production, that's okay. Because I'm only using it to say this is enough. And then we can build something else. Or we can move into our prototype. We can move into, we can move past the MVP into the actual Alpha product that we're delivering. I guess if you're really being a stickler and say that that is an MVP, the P in MVP tells you it's a product, right? Mm-Hmm.. Yeah. It's not a product that anyone's gonna fork over any money for. Yeah. But you're still learning. So is it valuable? Well, yeah, absolutely. That's, that's not true either because the, the Dropbox MVP led to a. Sign up you know, a beta sign up and I don't think there was a money exchange in the beta sign up, but, but basically there was no money exchanged. There was no, there was no money exchanged, but there was a promise to exchange money in the future when the program came online. And, and that was counted again. So it's really mind share. It's a Silicon Valley love story. So it's, it's, it's again, it's a, it's not real money. Like it's, it's all fake money on the internet. I get it. Yeah. Yeah. but the point still stands there is, is, the promise of value was in that instance for Dropbox was taken as an equal for value as far as the investors were concerned. Again, maybe it's normal, normal companies can't do that. That's why, that's why like the, my, my biggest problem here about the MVP of like, well, we got to have all these features, it's gotta be in production. It's gotta be scalable. It's gotta be running in Kubernetes and it's gotta be elastic on the back end where oh, you just scale automatically and all this stuff built in. Where are you getting all this time and resources? Where are you getting all this free money to build all these features to add to your MVP? That that's where a lot of companies go belly up because they do all of that, like you were saying, right? Because they feel like if we do all this, we'll be hyper competitive in the market. And before you know it. They're just another there's just another gravestone. So I, I think we're just kind of going around a little bit about the, the definition of what a product is. I'm going by the definition in my mind that a product is something that is something that the customer will part money for, but in the case of Dropbox. That wasn't the case initially, right? So certainly the website got them enough money to, to go on. And with customers, the promise that what's coming later they can sign up for. That's really buying Mindshare at that point. And if you're buying Mindshare, does that, is that valuable? Absolutely. Absolutely valuable, right? Is that a product? You could argue. Either way, you know. That's, that's, I'm firmly in the camp of If the MVP proves that the assumption is correct It proves the business viability of the assumption. Then you can consider it a product and you may say, well, there's more to build now, or it's, it's not, it can't, that, that feature can't stand alone. We need to add more feet like a hundred percent agree with that. But that, but again, that moves you to a different conversation. The conversation of what, what does the alpha release look like? What is a release? Basically, what does a release plan look like? Our actual release plan the summary of kind of where we're heading here is I feel that Eric Ries should not have used the term product in his Minimum Viable Product because even, even if you look at the Marty Cagan four Risks, the business viability is one of his risks. This is the whole purpose of MVP is to satisfy That the business viability has been taken care of because of technical viability and the usability and all that. That's other people's jobs, right? You have dedicated person on your team to deal with those. But the product owner or the product manager should be dealing with business viability of the ideas coming in. And in order to do that, like they can't be, I mean, I guess maybe some people have teams that just build functional, completely working features to test if something's. Viable, but that concept seems the opposite of where you want to go to me, it would seem you wouldn't, you would not want to, you would want to fake the data, fake the forms, fake everything to make it look like it works, go get your target audience, have them look at it, and then give you something like, oh, that, that's exactly what we need to get that aha moment, and then you take it to your development team to start building actual things. And you do that with the least amount of effort and time that that's really the goal. So I think the whole thing hinges around. You know, testing the feasibility and making sure that customers will. A like it and pay for it, right? I mean, you don't have to build the whole thing out or even partially build it out. You just have to do enough to gauge that interest level. That's really what it's all about. I think this is gauging the interest level and having the right kind of audience be willing to say, yes, we like this. Right. And then you can move ahead with that. A lot of this conversation is conceptual and a lot of people probably will take it as conceptual because I understand like the, when you validate the idea and flow seamlessly into building the product, it happens quick and it when, when you, when you hit product market fit. You'll know it, you'll be super busy. Money will be rolling in. You won't care about any of this, any of this. Conceptuality, is that a real word? Conceptuality? Yeah, it is. I think it is. It's conceptuality. There's inception. Yeah. Conceptuality. Nevermind. It's Conceptuality. It's, that sounds like a good movie. It's not. It's, it's a, it's a concept inside of a concept. Inside of another concept. The point in my brain is I don't want to conflate MVP with everything that comes after MVP because I want, I want the testing. Of business viability to be done over here with this, this specific mindset. And then when you need to move to say, well, well, let me do the story map. And now that we've validated all these assumptions in our story map, let me actually start building these things. Starting with the first thing that we checked for business viability. Let me start building that while I test these other things. And now you know that the path is clear to start building your beta release or your alpha release or whatever your release planning. so release planning and, and the whole, the whole. Discipline and skill set of what it takes to do your feature mapping and do your story mapping and do your release planning yeah, yeah, that is a different skill set than the testing that I'm talking about, and I feel a lot of these four points that we started with a lot of these, Oh no, MVP can be whatever you want. I feel they. Are taking both sides of that and smashing it together and be like, well, you can't have one without the other. Yeah Yeah, I, I, so first of all, I want to say this, the scenario you just outlined where you do your testing and then you move seamless into a product, it's a pipe dream almost, because you're probably going to have many, many different avenues you go down and discard these various hypotheses that you test because it just didn't work out. At least they were data driven. That, that's really my point about this, right? So I agree with that. And I, I think , MVP, MXP, MZP, whatever you want to call it. Learn from the slow, the smallest increment you can put in front of potential audiences and iterate from there on to learn from. Yeah, that might be it. Actually, I think that's it. I think this was actually a good arguing agile because some of this stuff we agreed on some of the stuff, some of the stuff we never really met in the middle on that's okay because it's arguing agile and If you're a product manager, scrum master, whoever you are listening to, the developer, whoever you're listening to this whatever your experiences are with MVP hopefully we've captured that in one of our discussions here and you have something to take away. Back to your work to maybe, maybe push back on to say, Hey, maybe we should be doing a testing business viability separate from the alpha beta GA cycle where we're, we're here. You know where to find us. If we've missed anything, please let us know in the comments below. And while you're there, don't forget to subscribe and like that's true.