06
08.28.2020   /   duration: 22 min
The Experience Lab
The Minimum Viable Episode about MVPs

The Minimum Viable Episode about MVPs

Rob and Jay are back to kick off the second half of our first season with a short chat about the virtues of creating MVPs, or Minimum Viable Products in your organization. With some important lessons from their years of experience rapidly building and releasing MVPs to the market, this is a great episode for anyone needing a pick-me-up or help getting their ideas to market faster.



Hosted By

Rob Hall
senior director of product
Jay Cosgrove
senior product manager


Episode Transcript

Rob Hall: This is the experience lab, the official podcast of digital scientists from Atlanta, Georgia. We’re an experience lab that explores and builds digital products. My name is Rob Hall, and I’m the Senior Director of Product at DS.

 

Jay Cosgrove: And I’m Jay Cosgrove, Senior Product Manager. 

 

Rob Hall: Thanks for listening.

 

Well, Jay, it’s Friday. 

 

Jay Cosgrove: Thank God.

 

Rob Hall: Any big plans for the weekend?

 

Jay Cosgrove: Nope. I’m going to a splash pad because I’m a parent now. 

 

Rob Hall: Ooh. Wow.

 

Jay Cosgrove: Yeah, should be really exciting. 

 

Rob Hall: My splashpad days are over.

 

Jay Cosgrove: Yep. I’m just entering mine.

 

Rob Hall: Yeah, congratulations. It’s a nice place to be. 

 

Jay Cosgrove: Cool. You know, not too much water, but enough.

 

Rob Hall: Yeah, I’m at the place where the kids are asking if they can take the boat out for a spin.

 

Jay Cosgrove: Yikes!

 

Rob Hall: It’s a different level of splash.

 

So today we’re gonna talk about MVPs. Jay, would you be so kind to explain what MVP? What does that acronym mean? 

 

Jay Cosgrove: It stands for Minimum Viable Product. 

 

Rob Hall: Yep. Minimum Viable Product? What is that? Do I need one?

 

Jay Cosgrove: The answer to that, like every other answer we give, is, “it depends”. And I think an MVP is just a really good way to test the market and test the product idea. We will often see them for new startups, that’s probably the most common way that you’re going to experience them unless you’re inside of the bigger org and maybe there’s a new feature set that is distinct enough that you might actually call it a separate MVP.

 

Rob Hall: Yeah, it absolutely depends on who you are and what your needs are. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: So very often here at Digital Scientists, we build a lot of MVPs. And we’ve created many of them over the years some for large organizations, some for new startups – anything from small mobile apps to API’s that run in the background that a consumer never sees. The definition of an MVP, I think is somewhat variable based on who you are, what your runway is, what is your budget, what is considered risky to you. 

 

Jay Cosgrove: Right. 

 

Rob Hall: And what is it that you’re trying to test? What are you trying to learn? 

 

Jay Cosgrove: Yep. 

 

Rob Hall: It’s less about concept validation and more about really learning from real customers with a real product. Yeah, so we do design sprints here, right?

 

Jay Cosgrove: Yep. 

 

Rob Hall: And we talk a lot about design sprints as being a very fast and cost effective means to get a concept in front of real users. I think an MVP differs because at least from our perspective, we’re actually building a real product and putting it in front of real people. And so it’s about figuring out what is the concept? What is the product? What’s the opportunity, and some customers come to us and they’ve already figured that out. They already have the opportunity. They’re very clear on what the opportunity is. They just need help bringing it to market. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: So for us, it’s taking that challenge and running with it is quickly in and expediently as we can.

 

Jay Cosgrove: Yeah, I think the common thread through no matter if you’re, you know, a big corporate product or software, or if you’re a small startup. The common thread is that you want to reduce risk. And so instead of investing a ton of money in a v1, and we’ll get into, you know, a difference between a v1 and an MVP here in a little bit, you would reduce that risk, that financial risks, that time risk, by just building the minimum set of features to actually have a viable product that can be tested and learned off of. And that’s going to look different depending on who you are, and depending on how many customers you have, and the level of professionalism or uptime that your customers are going to expect even in an MVP experience. 

 

Rob Hall: Yeah, I completely agree. I think for some customers, an MVP has been really rapid prototyping. If you listen to our last episode about machine learning, Jerry talked about this exercise that we walked through a number of years ago with handwriting recognition. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: That in and of itself was an example of an MVP for that customer. Now, that didn’t go to market, right? So you could make an argument that that was more of a proof of concept. It was definitely an R&D exercise, but from that particular customers definition, it was an MVP, internal to them. 

 

Jay Cosgrove: Yeah. 

 

Rob Hall: Now, I think the more common understanding is we’re trying to figure out how quickly can we get something to market and learn from it? 

 

Jay Cosgrove: Right.

 

Rob Hall: You can’t penetrate a market without having a real product.

 

Jay Cosgrove: Yeah, that’s right. And I think this might be a good time to kind of define a few terms that are used for learning. So you mentioned the design sprint. And one of the things that a design sprint produces at the end is a prototype, like a functional prototype. And that can look different. But most of the time, it’s, you know, it’s JPEGs that are wired together with Invision or some other app, Adobe XD or something like that, that produces or simulates a live experience that you can test with users and learn off of, right? So, a functional prototype might be a little bit larger. It could be somewhat in code, you know, we’ve done those before too. But ultimately, it’s kind of a dummy front end – that’s how I consider it. Then the other one that you just mentioned here is having a proof of concept. And what that is like going into build enough to prove if the idea works or not. And sometimes that line, just like you mentioned, between a proof of concept and an MVP is kind of blurred, depending on what it is. You know, I would consider that a proof of concept is more for an internal basis, like “Can we make this work?”, like “Will it just function?”. Whereas an MVP is generally going out in front of real users. And probably more of a wide scale then you would have for a functional prototype where you’re testing, you know, somewhere from five to 70 users. You know, an MVP would actually be kind of the first version that maybe someone is using in some sort of alpha state. Then probably the last one would be a v1, which would be your first real production iteration of the product.

 

Rob Hall: So we talked about minimizing risk a lot. What do we mean by that? Really, and truly, in the, in the context of creating an MVP,

 

Jay Cosgrove: I think you just don’t know what you don’t know. And so you’re gonna have some great minds, right? 

 

Rob Hall: There’s unknown unknowns.

 

Jay Cosgrove: There’s unknown unknowns, and you’re gonna have some great minds at the whiteboard and behind your sketch files and sitting coding. But at the end of the day, you don’t really know how the user in the market is going to react. And so minimizing risk is just building enough to get the signal from the market that it’s going to work or it’s not going to work. So it’s the minimum set of features that’s going to go out there. And if you build any more then you’re adding more risk, time and ultimately money, that you’re throwing potentially out the window if the market doesn’t respond how you assume it’s going to respond.

 

Rob Hall: Yeah, that’s absolutely right. It’s, you know, risk, I think, in terms of investment is highly variable. Based on the size of the organization and your appetite for taking that risk. So for a startup $100,000 might be an incredible amount of risk. 

 

Jay Cosgrove: Yes.

 

Rob Hall: That might be your, your whole, you know, seed round of investors. But for others 100 grand might be a drop in the bucket. 

 

Jay Cosgrove: Yeah. 

 

Rob Hall: In terms of what they’re willing to invest to try new ideas.

 

Jay Cosgrove: They’ll drop that on a test of a functional prototype.

 

Rob Hall: Yeah, exactly. We joke about things like that being a rounding error in some organizations, even though you know, hundred thousand dollars is a lot of money. But so I think in terms of minimizing risk, the idea is speed. Yeah, it’s about speed to market. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: And making sure that the product you’re bringing to market is very narrow. Yep. And not so narrow that it’s not viable as a product that’s, you know, inherent to the definition of what an MVP is. It ought to be a viable product. 

 

Jay Cosgrove: Sure. 

 

Rob Hall: That is, at least fully featured enough to be usable. Yeah, yeah, exactly. It’s got to have life. But the goal is to be able to have a really good feedback loop to measure, not just engagement, but to say, “does this product merit more investment?”

 

Jay Cosgrove: Exactly. Does it complete the job to be done? 

 

Rob Hall: Oh!

 

Jay Cosgrove: That should be a future episode. But I think that’s really important is when you’re going into scope and MVP, which is a very hard process to do with excited stakeholders, or it can be at times, because they generally want to cram as much in there as they can. So as a PM, you really, really, really have to dig deep to define the specific job that needs to be done. And make sure that MVP just completes that job. You know, and maybe it’s more than one. It could be two, depending, two or three. But any more than two or three jobs to be done, if they’re if they’re written well, to me is a red flag for an MVP.

 

Rob Hall: Yeah, I agree. That brings me to my next point, good, sir. What are potential pitfalls and risks of an MVP? What can go wrong when you’re trying to build one? We have some experience with this.

 

Jay Cosgrove: Yes, we do.

 

Okay, so I’m gonna back up just a second at DS. We actually do quite a bit of MVP work. It’s fun. It’s a lot of fun. You’re going to move very quickly, and it’s a great thing to kind of rally the team behind. Usually our team gets very excited about it, and you’ll see a lot of camaraderie come around. However, where they go wrong in my experience is with what I just mentioned: stakeholders from the client, most often, that are looking to just put too many features into the MVP. 

 

Rob Hall: Yes.

 

Jay Cosgrove: And one of two things is going to happen is you’re not going to meet your deadline of when you want to go out, which is going to push out costs and ultimately add more risk, increased scope, right? Or you’re going to add so many features, that the features aren’t deep enough. The individual features are an inch deep, a mile wide kind of thing. And none of them are going to do anything great. And you’re going to get really poor results from that.

 

Rob Hall: There’s another side to risk on that point. 

 

Jay Cosgrove: Yeah.

 

Rob Hall: It’s not just about financial risk, but there’s also an aspect of technical risk and 

 

Jay Cosgrove: Oh, for sure.

 

Rob Hall: Right, so it’s not uncommon that in the rush to get something to market development team might take a lot of shortcuts. 

 

Jay Cosgrove: Yes. 

 

Rob Hall: They may not think through the toolset or the framework or just even their approach to structuring the code as thoroughly as they might otherwise. And so, it’s not uncommon to find yourself in this place where “Yeah, we got this thing to market. We got it done very quickly. But it’s a mess.”

 

Jay Cosgrove: Yeah. 

 

Rob Hall: And so to continue scaling it over time actually becomes a very difficult exercise. 

 

Jay Cosgrove: Yeah. 

 

Rob Hall: And the dev team has to build in time to go back and refactor a bunch of mistakes or messy decisions or scrap it entirely and refactor it, which no one wants to do. And honestly is, I would argue, is counter to the whole idea of an MVP, is you’re trying to plant a seed in the market that can grow. 

 

Jay Cosgrove: Sure. 

 

Rob Hall: And so I think that’s why that scope discipline is so important, so that your design and development team can do really great work in a highly constrained amount of time. But then it’s done thoughtfully and carefully in such a way that if additional investment is given, it can continue to grow and flourish without having to be stuck in, “Well. we’ve built a throwaway. Cool, it worked out, but now we need to invest even more money to redo all these mistakes that we made along the way.”

 

Jay Cosgrove: And I think that’s something that you just have to set up front. Because, honestly, for me, I’m okay with that, that understanding, “Hey, in three months, I want something in market and you know, I only have X amount of budget.” Then you just have to set that expectation up front of like, “okay, we’ll get it to market, but once it’s to market, we have to go back and refactor and add a lot of stuff in.” And that’s actually been another risk that we’ve had is someone not understanding that. And so you have those two sides, right, like speed and features that you’re going to get in. Or quality and features but not speed. You know, you can only have two of those three is like quality, speed and price. They’re all gonna pull against each other.

 

Rob Hall: Yeah, that’s that old salesmen adage. You can have it good, faster cheap, you get to pick two.

 

Jay Cosgrove: Exactly. And it’s very true here. And so, I don’t know that I’ve done a great job in my full career, certainly in the last few I’ve, you know, been better at spotting this, but just communicating that upfront. Like, “Okay, if you want to go really really fast, really fast, we can do it, we’re happy to do it. But you’re gonna have to stop once this is proved and spend a lot of money rebuilding the features we already built to make them more of a foundation for what you’re, you know, you’re v1 to 1.5 is gonna look like.”

 

Rob Hall: So here’s the big advantage of building an MVP and doing it in a very crisp disciplined manner. Much like what we do here at DS, is getting to market and not just to get something to market, but to beat your competitors to market. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: And to me that is the whole point: rapid delivery, and then rapid iteration. And I think that’s the important thing that a lot of people don’t realize when they think they’re ready to make an investment in software. Just getting it to market is the beginning of the journey, not the end. 

 

Jay Cosgrove: Oh, yeah. 

 

Rob Hall: And so there’s a big preparation that that product owners really need to consider is: it’s not just the initial investment. It’s the continued investment past that initial release. 

 

Jay Cosgrove: Yeah.

 

Rob Hall: We’ve worked with a number of great clients in the past, some of which they get to that first release, and they stop. 

 

Jay Cosgrove: Yeah. 

 

Rob Hall: And we want to see it keep going. We want to help them measure. We want to help them learn. We want to help them continue to build, build upon that foundation that we helped them start.

 

Jay Cosgrove: I just think when you get to that point you have to prepare your stakeholders early on, whether that’s clients or internal, that there’s almost always going to be the need for time to refactor. And after a very quick MVP is going to be painful to some of them. Because they’re going to say, “Hey, in three months, you built this whole thing. Why is it taking three months to just clean up code.” But the thing is, is if you want your application to scale, you got to do it well.

 

Rob Hall: But here’s another point, too, if you take too much time to get that initial release to market, and once it gets to market, you’ve learned that there’s some aspect to the application that you need to pivot on and pivot rapidly.

 

Jay Cosgrove: Sure.

 

Rob Hall: Due to customer feedback, market forces, whatever, it may be too late to do that. 

 

Jay Cosgrove: It’s true. 

 

Rob Hall: And so the sooner you get to market, the tighter you get, then the faster the feedback loop that gives your team a faster ability to respond and react and get out in front. 

 

Jay Cosgrove: Sure. Yeah, and you’re just gonna have to make that decision when it comes. I mean, it’s very, very hard to tell. I just know that we’ve had experience with successful MVPs where they haven’t invested the time to ever go back and clean up, refactor, make it scalable. And then two years down the road, any small change is a nightmare. 

 

Rob Hall: Oh, yeah. 

 

Jay Cosgrove: And to the point where when they call us back to help us fix something a year later, we cringe a little bit when we see their email come in, because we know that the time was not spent or budget was not allocated to actually clean it up. 

 

Rob Hall: Sure. And that speaks again to the the need for scope discipline

 

Jay Cosgrove: Exactly.

 

Rob Hall: In any MVP, and honestly, for us and in our process, the tighter the scope, the higher the quality. 

 

Jay Cosgrove: Absolutely. 

 

Rob Hall: So that’s the lesson kids. 

 

Jay Cosgrove: Absolutely.

 

Rob Hall: So we do MVPs here at Digital Scientists. How do we structure them here, Jay?

 

Jay Cosgrove: It’s a great question. So we have actually a fairly like rigid MVP process. And that’s what keeps us quick and delivering kind of in the time boxes that we’ve laid out for the client, but also keeps the client scope down. Because we say this is the process. This is the period of time that you’ve got. And anything that falls outside of that just has to be pushed to a future iteration. One of the tools we use to kind of help keep the scope down is our process. So in general, it follows pretty much any other kind of typical waterfall-agile Scrumfall, whatever you want to call it, process where you start with a little bit of research, usually two to four weeks, depending on the time that the client has or where they are in their research process. I would probably say another two to four weeks in design. And then you’re usually right around two months in development to actually build out the features and then you’re ready to test 

 

Rob Hall: Yeah we used to say, “Your idea from concept to market in 90 days.”

 

Jay Cosgrove: It’s crazy. 

 

Rob Hall: It is.

 

Jay Cosgrove: We did it though. 

 

Rob Hall: We did do it. And it is possible. But again, but again, it is all about scope discipline. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: Yeah, so they’re certainly the instances where we’ve built an MVP, and it didn’t make it to market in 90 days. 

 

Jay Cosgrove: Sure.

 

Rob Hall: It was due to scope creep. And I’m definitely not gonna admit on this podcast that we’ve failed to do that. 

 

Jay Cosgrove: No, but I will say we delivered on way more than I expected we ever would.

 

Rob Hall: Oh, without a doubt, and even, you know, with clients that give us a longer runway, we still try to break things typically into 90 day chunks.

 

Jay Cosgrove: Yeah.

 

Because it’s a good release cadence. 

 

Rob Hall: And again, it’s healthy for the scope of any MVP, really, is like, “Get it out in 90 days.” Or maybe a little bit more, so you know, say it’s four months instead of three months. But anything after that is like too much in my opinion. 

 

Jay Cosgrove: Totally.

 

Rob Hall: I worked with a client once upon a time some years ago. They had a pretty sophisticated search engine on their site. And it was built using antiquated code. I think it was built in ColdFusion fusion.

 

Jay Cosgrove: Yeah, like just mentioning that word dates you?

 

Rob Hall: Yeah, exactly. The fact that I know it ColdFusion is bad. So they had this, this search engine and they needed to refactor it. It was again, very old, it was cumbersome, it was slow, it was very hard for their team to work on. Instead of taking this approach that they were going to create a clean foundation, ship it, and then continue to iterate to rapidly get back up to feature parity with what they had. They said, “No! We have to ship with total feature parity” with this antiquated system that they were replacing. Well, 18 months into development, they still didn’t have anything in market. And they ended up, I think they spent something like $5 million in development. They ended up canceling the entire project. 

 

Jay Cosgrove: My goodness.

 

Rob Hall: Losing that entire investment, I think they ended up laying off most the team. And they went back to the drawing board. 

 

Jay Cosgrove: Yep. 

 

Rob Hall: Now, we could get into this whole conversation, “Of well, they utilize waterfall versus an agile approach” or whatever. But you hear the same stories with undisciplined, agile teams that have the same struggle. 

 

Jay Cosgrove: Yeah, definitely.

 

Rob Hall: So at the end of the day, are you shipping product? Getting it in front of the customer? And rapidly iterating? That’s everything.

 

Jay Cosgrove: Yeah, I’ve heard so many horror stories of the exact scenario you just laid out of, “We have to be at feature parity. We’re working on this thing in parallel.” 18 months later the project gets canned. It’s insane. 

 

Rob Hall: Yeah, yeah, totally.

 

If you have an idea that you want to get to market as quickly as possible. And you’d like to lean on our expertise to help do it. Give us a call. We’d love to help.