Download Otter for your meeting notes

PODCAST: Does MVP work? | Otter.ai

PODCAST: Does MVP work?

Rob Hirschfeld40min

Rob Hirschfeld

00:06

Hello, I'm Rob Hirschfeld CEO and co founder of RackN in your host for the cloud 2030 podcast. Today's episode is about minimal viable product, which I explained in the podcast and is an important element to building good resilient products and spending the right time doing the right things. But it's not a cure all. And it might not even be right for what you're trying to accomplish. In this podcast, we really go through when it works, when it doesn't work, and what the goals are for how to build how to use minimal viable product. I think you will get a lot out of this, it will make you think about what should go into making product decisions. Enjoy the podcast. Back in the day, I was I was a big Eric Reese minimal viable product. And here, right, this goes back what early agile days, 12 years maybe with this idea that building, you know, building out full products didn't make sense that you would you would need you know, you should do a minimal viable product as the market. And just for completeness, right part of what Eric Reese was suggesting was, you know, back end, you know, do Mechanical Turk work, don't build any of the support infrastructure don't build, right, don't worry about billing, don't worry, you know, anything you can do, you're just testing the market to see if there's no market cash potential for it. And the idea would be that you would, if the firt, that was the first thing to validate. And if there was demand, then it was okay to Mechanical Turk. You know, have humans do the work. And you could you could automate and fill in in the in the back end. And a whole bunch of examples, I have some notes from friends who did things like that. Mostly consumer type products where you would fill in, you'd automate as you went. And I would, in my experience, building technology stacks, data center automation and things like that, we would try to do minimal viable products from what we built. And it was a disaster. Because an automated systems filling in with mechanical Turks is you're literally undermining it's taken me years to really appreciate appreciate this is that you don't get to have patches where the systems don't work, or require manual intervention, or have to get filled in that, in a lot of the technology scenarios that we deal with. Those actually, those those gaps actually are very problematic. And so and when I saw that there's a, there's an open source component dimension to this. But does that does that this sort of this MVP is not working for certain major categories of technologies, like you don't build an MVP car, have, you know, really sort of changed my thinking on how that that whole process works. And what is acceptable is an MVP, and what people can understand as an MVP, and much more skeptical today than I was for, but I'd love for somebody to come back and say no, no, no, it's MVP has helped me do this, or they, they do help you build products. That makes sense.

Speaker 1

03:57

Since I'm serious MVP is an overloaded term. And that's the problem. So so i'm doing i'm doing a doing workshops right now, with clients. And we define an MVP, and I'm using big giant air quotes. Because it's the minimum product that they're willing to. To buy is really what it comes down to. Because we're consultants, we build software for them. And this is the point at which they can sell the process to their managers.

Rob Hirschfeld

04:40

It's the value finding viability is important. Yeah.

Speaker 1

04:45

It's not the point at which which the software that we're building is valuable to the organization. It's the point at which they can jet managers to believe that it is valuable to the organization. And that's different. And and each organization defines in different ways a lot of our MVPs that we end up calling an MVP is, has a lot of nice to haves, and to be honest. So you're using the right term MVP for what you're talking about. And I'm with you on that. I never get to use it that way.

Rob Hirschfeld

05:33

Does it? Does it help you define the product? Or does it help you eliminate feature sets that aren't I mean, that, to me, the value here is let's not build a feature set that we don't need yet. Let's not worry about billing writer or credit card trip, like like we're doing a whole bunch of work to create small, small billable units. And we have no idea how to automate the credit card transactions. Yeah. Oh, yeah.

Speaker 1

05:59

No, that's great. Okay. Yeah. Okay. What, what, what we, what, what we and by we, I mean, the whole organization I worked for, right? We're using MVP as really the first milestone. That's that's really all it is. It's not even. It's there's nothing minimal about it. It's, it's about, you know, using the term to sell the service,

Rob Hirschfeld

06:32

does it does it let you like, defend a feature set from having to be developed? Like, like, that's that, to me, it there's value here where you can be like, hey, yeah, I know, this would be a nice to have, like, you know, but we we don't. I mean, I can give you examples from our life, which is,

Speaker 1

06:56

it lets us remove complexities, right things that we dump things that we don't know how to solve, yet, we push out of MVP, because they're there, they're not bound. So that means we can't put them to a milestone. Right? What we do is we we put text bytes in, during the MVP process, right? As part of it's part of moving to our first milestone, we put text bytes in to solve those questions to answer those questions. So it's useful for us, but we're not using the true definition of an MVP. So

Rob Hirschfeld

07:42

do you see people who build build out an MVP, knowing they need a feature set? Like, create the menu items even? But then if, if, if, you know, to see if users click on those menu items, but then they're like, where it's, you know, we don't didn't build this yet.

Speaker 2

08:11

Okay, so in, in our case, I followed similar kind of methodology to what you described, Rob. Okay. But I think the key words here are viability. And what that means, by definition to whoever it is that you're talking to, because an alpha user, or a beta user, is not the same as an investor. For bear, you have to keep that in mind. And we also built it on the basis that knowing that it was an agile development plan, and we were going to keep iterating and keep iterating that we should go from the outset to build in the minimal functionality for that feature set that may be nice to have, just so that it was there as part of the original design and development. And we could either pretty, add add more or whatever, but the building blocks were there,

Speaker 1

09:10

or you have to iterate over them. And we're finding the answer.

Speaker 2

09:15

Yeah, well, we did 25 iterations in three months. But the first

Rob Hirschfeld

09:21

one, what did what did an iteration look like? Yeah.

Speaker 2

09:25

For build for front end back end, all of the back office systems that the product was talking to, because although it was designed as a payment processing capability, very secured on a mobile device, it it put calls into back office systems like a MEMS e RP PLM supply chain, even down to a very granular level of putting a poster get from into a spread So we had to build all of that we were building it cross cross platform. So when we built the stack, and when we built the MVP, we built it for three audiences, what first was investment. And we actually use CAD and simulation to do a lot of that work for that purpose, because we knew that they weren't going to look at the code, not at least at the outset, and then we would only release it as as necessary. The second was for alpha, to get people on board as quickly as possible. But our alpha testers were not individuals, they were corporations. And thirdly, for the beta for the wider use of their consumer, how it was actually going to work. And we did some funky stuff in there. But they sometimes

Rob Hirschfeld

10:57

because you didn't actually know what the process was, and still, until people started using it. So

Unknown Speaker

11:04

we knew what the process should be. Could be,

Rob Hirschfeld

11:07

and but not everybody, but people needed to work the process in order for them to comprehend it.

Speaker 2

11:17

Right? Well, our process was actually described in a video that we made to show, okay, here's how you go to a store and pay for something with a credit card or a debit card, right? Because we use interact all over the place here. That's our bank to bank, you know, immediately withdraws from your bank account. That was one. And we filmed somebody using it with the phone and what the interaction was like. And this was not rehearsed, it was just, I'd like to pay with my phone as they walked into Burger King, because that was one of our first clients, and said, here's how I want to do it. And although all of this stuff, what was what really interested people and came out about it was that the inefficiencies of the operation of that franchise was what was more telling than somebody trying to use their phone to pay. And so we we had purposeful ideas in mind when we did this and and shot the video, I did the MVP and everything else, we just kept showing where the value was from the corporate perspective, because we were talking to their inventory control, we were talking to delivery times logistics eirp everything from their side, as well as the consumer experience. But that was just

Rich Miller

12:44

us. Quick question. Are we mixing a minimum viable product with a beta or early access? Is it in fact a product? In the scenario you just described? Joanne?

Speaker 2

13:04

Um, I would say it actually was a product because it was fully functional.

Rich Miller

13:09

Okay. To answer well, to at least respond to Rob's question about where it works. And in Is there a place for it? When you're dealing with automation, which of course you are, um, what I've found many times the is the MVP is in fact, a product. It is minimal in that it because of, quite frankly, I won't say lack of trust, but just no knowledge of its behavior or the degree to which it's complete. The minimum viable product and automation situation is something that is a non invasive and B is not provide is not given permission to make changes without, you know, kind of human assistance or human human intervention. And what that says is when you're dealing with an MVP in the management, and automation and configuration, most of it is going to the monitoring, measuring metrics side of it and recommendation side button, not closing the loop. And that is closer to what an MVP is when dealing with these kinds of configuration orchestration? Yeah, automation. And that's a very useful way of talking about what an MVP is for a product that is destined ultimately, to be a form of automation and make under automated control. changes to a configuration or to whatever they do universe of discourses.

Speaker 2

15:41

Yeah, I totally agree with you. I mean, from from our perspective, and, and my partner in crime in that company, who is a very talented technician. We actually got permission from the franchisee, and the franchisor in that one location, to be able to take some, how, how would I describe this to you almost, almost build a virtual back and a replica of what they had. And that's the reason that we were able to do it. I mean, we jumped through a lot of hoops for them, and it was all on a single, like, server in that location that mimics exactly what it would do in real life. So we virtualized the environments, etc, etc. But to your point bridge, I 100%. Agree. We just wanted a

Rob Hirschfeld

16:44

prototype or an MVP? And maybe maybe I'm maybe there's not a material difference?

Unknown Speaker

16:49

Well, that's a good question.

Rich Miller

16:54

I'm gonna make the case that it is a product, it is, it can be put into production. Yep. Whether it's going to be on its own word to, you know, stop. is progress in terms of adding functionality? Would it be a successful product? Would it be long term commercially viable? Probably not. The whole point here is it's, it's an it's an entry level, or it's a it's a first phase, or it's a, it's an initial product can be brought into production can be given service levels and, and go through commercialization and licensing and, and and use. It is minimal, because it's probably not complete enough to be a commercial success.

Rob Hirschfeld

18:00

And to me, what you're describing is a great use case for an MVP. And let me I'll take it even one step further, right, Joanne was talking about a pay per phone app at a restaurant, right? an MVP in that case, could be as simple as somebody walks in to a restaurant with pay per phone, and you have sign that that simulates the read, like they have to go through all the operations to pay, they need it, you never actually charge them anything and there's no back end that somebody watched them do it and then brings them their order, there's all you're doing, is finding the human and seeing if the human interaction works, or it's a positive experience. Yeah, nothing else matter. But

Rich Miller

18:43

is that a product? Is that a product? Or is it a prototype? No.

Speaker 2

18:49

Okay, so so let me address Rob's point, we actually did have a payment gateway that we built, and through a third party that was, you know, PCI compliant, and all of the rigmarole that goes with that because building one of those yourself is an extremely extensive undertaking. And the reason that we we actually set up the accounts and did put the charges in and we paid the charges, etc, was to show the process because we had to to to any CFO, or even investors that were asking about it, to see where we were getting our revenue from. And we wanted that as a proof point. So we actually did set that up in in whether you want to call it a minimum viable product or a prototype, which I consider after minimum viable product. Um, I would say it was more product than MVP, because it actually did work. It did process transactions, and people did pick up orders. So in that Since there was a prototype of what would come, the only part that was, I think, totally MVP was the simulation of the back office systems that it would connect to, because they were virtualized environments and no code. No entries were actually made into those back office systems. They were all simulated as what would happen if, and here's where, you know, a trigger for an inventory. depletion would trigger a call to a warehouse system to have logistics provider or three PL bring more buttons, for example,

Rob Hirschfeld

20:39

but which were not exactly where MVPs are supposed to be. Right? Yeah, that's, that's me. That's exactly the line. It's like, yeah, don't wire in any back or back end systems, until you know that the front end system is going to need to scale because it can be really expensive to wire in the backend systems.

Speaker 2

21:00

I know. That's why we virtualized it, you know, we got permission for them to say, to tell us which back office systems they were using. What was franchisee? What was franchised, or these were going to be all corporately owned, until they figured out how to pass the cost to the franchisee directly. And our revenue streams were coming from multiple places within the same organization. And, you know, the whole thing was call it an extended proof of concept that resulted in a full blown prototype that could be used, but probably would not have scaled.

Rob Hirschfeld

21:41

I, this This, to me is exactly. This is the benefit of the MVP thinking. But I found it, it's hard for people to get their heads around sometimes, because what you're literally saying is like, I don't know, it would cost us you know, we'd have taken years to earn back the money on what it would take to wire in all these systems. And it's, it might be worth it. But not until we understand the customer interaction product first,

Speaker 2

22:11

right. And just to be clear, this was before the, quote unquote, protected or encrypted parts of phones. So we had huge issues with building all that encryption and cryptography and how it was going to be used and the keys and the timeouts. And literally, this thing was very sweet from the security point of view, simply because the fact that you could make a transaction at the drop of a hat, but it would timeout on the credentials until the next time you used it and be absolutely rendered impossible to use. You had to be purposeful about making a transaction. And this was a it was quite a long time to design. It took me two years to design it. That was my little side hustle. But once we started doing the actual coding, and the codification of it, guy was really adept at doing that. Unfortunately, the the, the situation was one where we were made offers so early on in the process that it never actually came to work, it was taken out as a defensive play by the acquire. What I like to

Rob Hirschfeld

23:30

do the most profitable way to build a tech technology, though, yeah,

Speaker 2

23:35

yeah. Would I do it again? Absolutely. Because there's a lot of flaws in the system. But again, the thing that emerged out of it more than anything else was the absolute inefficiencies of fast food or quick service restaurants, and even fast casual once. And that made a dent in the industry from a disruptive point of view. And today, I'm seeing a lot of that work, coming back in robotics, you know, the robots that are delivering your order and taking your order and whatever. But it's in test. And this is my other question. What do you consider in the MVP nomenclature versus prototype? The test? How complete is the test? Or does it need to be in the MVP?

Rob Hirschfeld

24:25

The the thing that the thing that I think is important from an MVP perspective is really it's an assumptions question. Testing thing. Because there there are a lot of places in building out these these processes where something you've assumed would be easy. doesn't doesn't work out to be easy, or it doesn't have dependencies that you might not have expected to have in the process. Right? And maybe maybe my MVP failures are actually, you know, uncovering lessons or lessons learned from from these perspectives, isn't it but that I mean, when as you build up that prototype, part of what you're trying to do is you're trying to find the most risky, or unknown area of that development and do that first. Whereas in a lot of cases, people build products, they build a whole bunch of easy support technology and things like that. And then and then they get to the actual thing that's going to drive the market or not pretty late, after they built a whole bunch of inflexible infrastructure around it.

Speaker 2

25:43

Yeah, and that's what we were trying to avoid. I mean, in our case, the biggest stumbling block that we found in testing had nothing to do with the technology.

Rob Hirschfeld

25:53

You know,

Speaker 2

25:54

it No, quite literally, the biggest fan of any fast food franchise in the world, is people driving up to the window to pick up their food, and spending too much time fumbling around for either their credit card, or phone, money, anything of that nature, it adds so much fun to the process that costs them millions.

Speaker 1

26:21

And it's always a surprise for those people that do that.

Rob Hirschfeld

26:29

They're with you. For money

Speaker 1

26:31

limits, it's it's not just fast food, it's it's all lines where you have to pay, I really love this, people get up to the line to get their credit card out, once they get there.

Rob Hirschfeld

26:41

I'm not this goes, I'm about to go to Austin City Limits, right. And then they're incredible on the logistics on this, everybody has a wristband to get in and out of the dough and the wristband, you can tie to your credit card and use that to pay at the register. So you just tap your wristband through the register, and it pays, which could be as frictionless as you can possibly get. And it's still amazing to me to see how much people struggle, that process.

Speaker 2

27:17

I don't attribute it. But I mean, that's why I asked the question about testing, right, because it's, it's a human use case. Um, and we were the only way that we could figure out how to get around it from from who we were trying to sell to at the time before, you know, the acquisition was to give people a QR code. sticker and have a camera, pick it up, as they were approaching the the payment, part of the journey, getting there getting getting their product and paying for it, so that the camera would pick up the QR and immediately, you know, the rest would be technology of getting the payment from a credit card, whatever they had set up as their default. But we couldn't overcome somebody digging out change from under their seat. And we also couldn't influence the fact that drive thru drives in most fast food restaurants are set at a particular width to make it hard for you to go around those corners and whatever. But they couldn't add a second leg. Because 90% of the time, they don't own the land, they're renting it or leasing it. And they can't build an app, they only have a certain amount of square footage. So you couldn't say, look for change under your seed, pay with your credit card, pay with your phone or pay with something else and have four legs like an easy pastic thing. It wouldn't make a difference. It was interesting to

Rob Hirschfeld

29:00

these intrinsic limitations are inherent in the designs in the system. I go ahead, Larry, I'll tell you a story in a minute.

Speaker 1

29:08

I would just I was just going to come back. Joanne, you said that the prototype comes after the MVP. We do a lot of prototyping prior to the leap as well. I mean, the prototype, you know when when does that actually fit

Unknown Speaker

29:23

around? mean, how does that go into the product? Or where do we see that?

Speaker 2

29:34

In, in my view, a fully functional prototype is the MVP. And that may be wrong. It's just my perspective. Because having done this now twice, I look at it from the point of view of what worked with the minimal of the minimal and what was demanded thereafter. So rather than go through You know, 20 iterations to get from minimal minimum viable product to prototype to have some level of acceptance, whether it's investment or or users, excuse me, um, I find that the more you put in at the outset, if you can, the better off you're going to be. So I equate the two. But for me prototype doesn't mean, it's pretty to look at but doesn't work, it means fully functional.

Rob Hirschfeld

30:35

And that's what I appreciate with the MVPs was not building a whole bunch of fake screens. That they're ever going to get into my battle scars. Because right, we compete with, with products and industry that have built flash demos, and some, you know, some some graphical, you know, wizard thing that adds to what, as well, from a market perspective and executive sales perspective, the actual implementation of what's behind that is incredibly difficult. And that, that, to me, those people aren't building MVPs, they're building, although that's what they'll describe as an MVP. And MVP is like, yeah, I can get somebody to say I'm gonna buy you buy this from you. Whether or not they can build the product behind it. They haven't cared about. And that's, you know, then again, built, you know, if you built the product, the other direction, you're going to build a whole bunch of stuff that people don't need, which is sort of like our story, like we set out to build, you know, by BIOS raid patch, because it was breaking everybody we knew and, and the reality is, is that solving that problem, actually sets off a cascading series of like, well, I don't care about that until this, I don't care about that until this, I don't care about that until this. And by the time you've you figured out what they do care about where they can get to that problem, you've actually built something different, or you solve a different problem for them. Bad. I'm sorry, Joe.

Speaker 2

32:24

I know I was just, I totally agree with you. You can get caught in this this like, hamster on a wheel syndrome. We were very purposeful. And I think Larry probably goes down to may go down the same road, but I don't know. We we spent a good deal of time. And went to, I would say 100 different franchises whether they were quick service QSR, or fast casual or whatever. And we sat there watching and clock in how long uptrend How long did it take for somebody to walk in order, get the usual screw up issues that people have the errors from the cashier side, they they put the thing in wrong, they weren't listening, they were to doubt or any part of the process of actually making you a burger. And we timed it all. And we were very specific in what our intent was. So when we got to that hamster in the wheel kind of point, we looked at we looked at the the processes as our driver to what we would build in what would be a feature later, we didn't care how it looked like the GUI was or the UI was like less, you know, very, very black and white, no pictures, no images, no branding, no, nothing, we did not care. We only wanted to show this will speed up if you're if you're selling 600 meals in one hour between 12 and one. And that's your peak period over Tuesday, Thursday, and Saturday, that we can reduce your time and increase your flow from 600 meals to 1000. And we used as our proof point studies that were done with McDonald's, which sells 16 million a day in NEOs, average cost, consumer cost, time in time out churn, all of that sort of stuff. And that's how we do we chose to build the features and functions that we were going to go with first.

Speaker 1

34:33

And I have one minute before I go to a meeting, but I want to stay and talk because you're right. It's I think the key is that the thing that we do, I have a UX person that's doing dropped in vision they do. As Rob was saying they do the pretty and my job is to make sure that everything they do in the pretty is is actionable things that we can actually build and so we tend to go from both sides. But it's, it's in you both safer. Yeah, it's safer to come from the tech side up, I agree on the UI side down. If you go from the UI down with no tech behind, then you get to what Rob was saying, you get people selling things that can't be built. So I'm sorry.

Speaker 2

35:25

I completely agree. I mean, that's why I spent two years designing it, because I wanted to make sure that even with changing technology, you could have the technical resources to be able to build this thing out.

Rob Hirschfeld

35:39

Right? There's, I'm going to throw into the backlog, an open source version of this talk, too, because I actually think that there's an open source variant on and Sharpies and open source is I think, open source full helps and completely breaks what we just talked about. And it always will,

Rich Miller

36:09

yeah, agree. The other side of the other side of this is its applicability for call it you know,

Unknown Speaker

36:22

with

Rich Miller

36:24

web based or consumer based offerings versus the kind of infrastructure products that you are dealing with it with the rack and something that you know, I can put in place as a website has no has really very little, if any distribution issues, I can change it and modify it pretty much on the fly. And the next time an end user signs on they're going to see something different. The notion of an MVP that adds or provides enough value to keep a customer coming back. And allows the vendor to add value add functionality based on end user activity, you know, on the fly and kind of evolve it in a in a rapid fashion. I think that's a legitimate design and development method methodology, it is not appropriate for a lot of the other things that you've been talking about,

Rob Hirschfeld

37:51

are the idea that balls that we could have have datacenter automation that was anything short of, you know, product, product ready and fully featured was laughable. And yeah, in pursuing it was a mistake.

Rich Miller

38:07

Right? Exactly. Thank you, Rob. Appreciate it.

Rob Hirschfeld

38:11

This was fun.

Rich Miller

38:12

I got a lot of insights.

Rob Hirschfeld

38:14

Thank you. We'll come back to it next week is business value mapping.

Rich Miller

38:21

Oh, it'd be fun. That'll be really

Rob Hirschfeld

38:23

good. Have a good weekend, everybody

Unknown Speaker

38:25

you to take care of

Rob Hirschfeld

38:34

minimal viable product is a really key way of thinking about how we build products together. And clearly, we only got halfway through this topic, I think the bringing in open source will really open up the discussion and make us think about how communities can build products together, and what works and what doesn't work in those cases. I would love for you to be part of that next conversation. So join us at the 2030 cloud, and contribute what you've learned about building products and building great products, both what's worked and what your scar tissue is. We learn a lot from both. Please join us. I will see you at the 23rd clap. Thank you for listening to the cloud 2030 podcast. It is sponsored by RackN where we are really working to build a community of people who are using and thinking about infrastructure differently. Because that's what wreckin does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly or just keep enjoying the podcast and coming to the discussions and laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you

00:0000:00