Building a Viable Product: Insights and Experiences

This episode ended up being a brainstorming exercise on how Rick can set high-confidence MVP requirements for his ventures at LegUp. We identified several approaches to scoping an initial MVP:

• The productized service approach. This is where you start with a service business and iterate your service into a product with automation tools and software. 
• The skateboard approach. This is where you start with a simple product that solves a very tiny piece of your big problem (e.g. the skateboard solves the big transportation in much simpler way than a car).
• The learning approach. This is where you scope MVPs to test specific, prioritized hypotheses about your business.

Takeaways include:

• MVPs are a tool designed to help validate ideas and learn.
  • It's up to each person to figure out how to apply it in a way that works for them.
  • Don’t lose sight of this and overcomplicate it.
• Consider a minimum viable product verses minimum sellable product.
  • Viable could mean learning in exchange for delivering value.
  • Sellable means receiving cash in exchange for delivering value.
• Don’t worry so much about having the perfect industry-accepted definition for what you're trying to do.
  • When you're new to entrepreneurship, you hear these terms, and sometimes you just need to talk to someone about what you're trying to accomplish and just validate it, and make sure that you just check your sanity on these things. 
• The situation drives everything.
  • There are also constraints that are brought by the situation, such as whether you fund yourself or raise capital, whether you have partners, what skill sets you have around the table, those kinds of things.
• Consider whether you're building a process problem solver or a productivity tool. 
  • The type of problem you are solving drives a lot of difference in how you approach building MVPs.
• First time founders should consider identifying problems that can be started as a service business and productized later. 
  • It's much, much easier to support yourself and generate some revenue with services, consulting, contracting, than it is with a product. Start with the easy money and then evolve towards that product.
• Don't be afraid to build a product that's, to the user, providing a lot of value. But behind the scenes it's cobbled together with spreadsheets. 
  • What matters is that you're delivering value.

Introduction

Tyler: Okay, let's dive into the topic here. We're going to talk about, basically, out of an MVP, a minimum viable product, how do you know when you're at a V, the viable part? Do you want to intro this a little bit?

Rick: Yeah, I thought about some context right before this, so I want to share this with you. I don't know exactly how this topic conversation's going to go. I'm perfectly fine with just having some confidence to move forward with what I'm thinking already, that would be a great outcome. But I feel a lack of confidence with my plan moving forward, and I'm hoping that, whether it changes or not, whenever we do takeaways, I'm moving forward after this. Additional context is that, I can't remember exactly what you said in a previous episode, but one contributing factor to this is, I'm new to coding. Outside of computer science classes, I've actually never built by myself a product and released it to the world. I've always had a partner or coworkers working with me on that. This is new to me. Here's what you said, I think I just remembered it. You said that, compared with where we were when we worked together at Zane Benefits back 2007, 2008, 2009, it's 2019 going into 2020 now, and you said that the minimally viable product threshold for an internet-based software business has increased significantly over the last 10 years. I guess that's one thing that is holding me back is, how do I know when I've met that threshold is a question. But, what I'd like to do is add some more context. Does that make sense?

Tyler: Yeah. I mean, I think anyone who ever starts a business has this question of, "How good does it have to be?" Like everyone says, you want to go out and validate and test stuff, so you make something, you go sell it. But what if it's so crappy? It would have worked if it was better, but it doesn't work at its current version. How do you know when it's actually ready to go sell it? Right?

Rick: Yup. Yup. Exactly. I'm starting to scope a few no-code minimally viable products to work on for the rest of the year. Just to give you some specifics around the industries, they're all software businesses, internet-based. One is in the financial services space, specifically I would say health insurance, one is GroupCurrent's member management software, so a community management platform. Arguably we already have an MVP there, we're just interesting to talk about. Then the third is... One problem I have, this is a personal problem, when you taught me, you said, "Teach yourself how to code." You said, "Find a personal problem to solve and learn to code around that." I'm actually probably going to do that coding-wise versus no-code. But I read a lot of books and I listen to a lot of podcasts. I consume a lot of content, and I want to talk to Sable about those things, Sable's my wife. I can't oftentimes get her to... she doesn't have time to read the books that I read, nor does she really want to. I want to build a Sable notes app, which allows me to basically summarize the takeaways and the topics and give enough context to her from these books and these podcasts I'm listening to so that we can talk about it.

Tyler: But that's a personal project to learn to code. That's not an MVP type of thing, right?

Rick: Well, I guess in this case if Sable uses it, that would be the measure of success. But, I could apply the principles to this, but the threshold is much lower. Anyway, those are some of the things I'm thinking about. One thing I need to do that's actually probably unique to no-code in this space is, I need to identify the right stack of tools. Stack meaning, what different tools do I need to stack on top of each other to make this work with no-code, make the product work. In order to identify the right stack I need to be pretty clear about the minimum viability requirements because with no-code there are some pretty specific use cases for each stack. Getting the right stack setup, you may have to change all the tools if you get the minimally viable requirements wrong.

Tyler: Yeah. Do you want to... I mean we could have this conversation like, "Yes, you're going to build it with no-code, but maybe that's a separate thing. How do you take what we say, or do you want to say, let's frame this around the constraints of what no-code tools give you.

What is an MVP and where does it fit?

Rick: I'd rather fly above no-code because I think that that's just a way to get it done. At the end of the day, I need a framework to give myself confidence that I can move to the next step in the entrepreneurial journey. What I would like to start with is, I'd like to tell you how I'm thinking about it, and my definition of MVP, and then I have no doubt that you're going to have a different philosophy than me. Here's how I think abou...