Startup to Last

This week, we talk about how "viable" an MVP actually needs to be before you can stop building, and start selling.

Show Notes

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 about the entrepreneurial journey and the way I go about it. I look at it as three important stages. One is, the idea of validation and getting to a place where it's worth investing into actually delivering on the idea in the form of a product. I don't think enough people spend enough time on idea validation through customer interviews, and really just asking the right questions of the potential market.

Tyler: This isn't saying, "Will my product solve the... Will people buy this?" This is saying, "Is it worth taking the risk of doing the next step, which is building something?"

Rick: Yes, and typically through... If you ask the right questions around an idea you have, you can get to some pretty clear answers on what criteria you need to deliver in order for them to buy. Oftentimes you're going to realize that that's much bigger than... that's going to take a lot of time to deliver the ultimate product that these people need. That's the product/market fit product. Through the ideation, you get to the third step, which is you have a vision for this thing that if you could build would give you product/market fit and allow you to scale a cash producing business. In between that, there's this, "Okay, I have some validation around my idea, and I have a vision for a product. How do I..." There's two spectrums. I could release literally a webpage that's vaporware and do everything behind the scenes, or I could build it all and release... build the whole product vision that I see and release it after a year. If you look at spectrums in terms of getting from, "Hey, I have an idea," all the way to, "I have a real business," product/market fit is how I would describe that. How you approach product development becomes, do you take a minimally, minimally, minimally viable approach or do you go, "I'm going to deliver the whole product from the beginning."

Tyler: I actually think between those two, to me it's pretty clear what the answer to that is, which is, how much do you still need to validate it? Now, I'm, I think, probably not as big of a fan of those customers in interviews as you are. I don't think they're a bad idea, but I think you might trust them more than I do. But if you're like, "I 100% know there's a market for this, I can sell it, all I have to do is build it." Then I'd say, "Yeah, go build the real thing from the start." But if you're like, "The idea is validated but I haven't actually proven anyone will buy it or anything like that," then you need this middle step to say, "I'm still validating. I can't validate any more by asking questions. I need to actually get people to give me money for a product."

Rick: I would love to hear your definition of an MVP. It sounds like what you're saying is, it's more of a conceptual tool for learning than any actual product.

Tyler: Well, I've heard people describe it as, that instead of calling it a minimum viable product, it should be called a minimum sellable product, which is to say... Viable goes to, does the product do what it's supposed to do, or something like that? Sellable means, will someone pay you money for it? Which, they probably correlate but they're not exactly the same thing.


MVP vs MSP (Minimally Sellable Product)

Rick: Totally. I love that. That actually helps a lot because I can get really far with idea validation. I see minimally viable as a tool to further validate the idea, and then you take this leap to actually making money, which is the MSP, minimum sellable product. Then you try to get that minimal sellable product to a place where you've proven that there's a market for it and a profitable business model around it. That's interesting. That might actually solve my problem. I think I'm getting caught up on the ambiguity of what minimally viable means.

Tyler: Yeah, if someone will pay you money for it, now, I mean there's a whole separate question then, do they churn and all that? But someone will pay you money for it, that's a type of validation you can't get just from talking to people.

Rick: Totally. I think that's really interesting. I think I am not there yet with any... I think it's very difficult unless you just know the market so well. I think for, maybe the health insurance business, because I have so much time in the market, I could get away, potentially, with skipping MVP going straight to MSP, but I think it's an unnecessary risk.

Tyler: One other thing if I can add onto this that, I think that you can use the way funding rounds work as a model for how to define these terms also. Which is to say, think of a company that nontechnical founders, everything has to come. Investors give you money before you can really do anything. The first phase is, you come up with an idea and a pitch that's good enough to convince a seed or an angel round investor, they give you money not to build the company but to validate the idea. Then your Series A is, the idea is valid, the product's validated, it's all about scale. To me, MVP is the point where you go from proving something to scaling something.

Rick: Yeah, I mean, I like the idea, but my experience with raising capital is that everyone, depending on the investor you talk to, they have different investment criteria. Be careful-

Tyler: I don't raise money, so I'm not saying that this has to correlate with that. I'm just saying, I think you can look at the pure model.

Rick: Your point is made in that, there are different stages of a company and the capital requirements and the capital usage at each stage is very different. In this case, I have a huge constraint in that I'm not going to raise money before I get the product/market fit, if at all. The capital I have is really the cash that I produce and the time that I invest.

Tyler: Yeah. But so, the threshold you want to hit is, when am I ready to... if I were to go talk to an investor right now, it's not about experimentation and proving something, it's about scale. As soon as you're ready to scale that's when you have your product/market fit MVP.

Rick: Yes. Yeah. I hesitate to call it MVP because I think it's... If you have an MVP that hits product/market fit, that you can scale into a big market, that's probably not a minimum viable product. That's probably something that's... Unless you got really lucky with this simple thing that just changed the world. I don't know.

Tyler: Well, by scale I mean, grow the sales and marketing, but also hire a team of developers and scale the product too.

Rick: Okay, so you think-

Tyler: It's like, we're done experimenting. It's almost like you can look at, how do pharmaceuticals drugs work? You're in this period where you're like, "I don't know if this does anything or whatever." Now we think it works and it's time to do clinical testing and actually ramp this up.


What does the V (Viable) in MVP mean?

Rick: I'm totally realizing why I'm frustrated with this. MVP is such a butchered word. I totally agree, if you replace MVP in that conversation with minimal sellable product, I can get with you about investing into growth. But if you have an MVP that isn't sellable... To be an MVP, does it have to be sellable? It doesn't sound like your definition thinks so.

Tyler: I mean, I think that's what people mean. What this really comes down to is what does viable mean? I think the implication of the original term, MVP, is that something is not viable if you can't sell it. Calling it sellable is just a little more precise I guess.

Rick: The way I've read about MVPs and the way that I've formatted my own thoughts around them is, there's a huge spectrum. An MVP could be designed to provide value for free for someone in exchange for information. The currency here, I think, that's very clear about MSP is that there is an exchange of cash. MVP could be an exchange of information, it's a learning exercise.

Tyler: Right. For the sake of this though, let's just use them synonymously because MVP is the term people are familiar with. But what we mean is minimum sellable product for the rest of this conversation, right?

Rick: No.

Tyler: No? Okay.

Rick: No, no. I don't think so-

Tyler: We should just be talking about minimum sellable?

Rick: I guess if you have an MVP overarching piece... Getting the minimally sellable is what I would probably... if I didn't have this conversation, that's where I would go first. I wouldn't release until I got to minimally sellable. I think that's where I'm a little bit... that's what I want to validate with you is, my approach is more on the perfectionism side. I'll go do the customer interviews, I've already done a lot of those. I've got a lot of validation. I'm moving towards holding shipping back and getting to what I've envisioned as a minimally sellable product.

Tyler: I'm going to push back on that.

Rick: I knew you would. This is why I want to talk about. The question is, should I just... If that's not the right approach, what's the... I generally don't like throwing out something that provides no value. There's a spectrum there that I get uncomfortable with, but I need to be challenged on this, so go ahead.

Tyler: Here's why I have concerns about the... My instinct is to do what you're doing as well. I think a lot of people feel that way naturally. But the problem is, there's a big gap between validating.... From customer interviews, what you can tell is, I understand the problem. I understand there's a market for it... But what you can't prove is, this product that I built solves it in a way that people will buy. The reason, I think, you need to get something out there, it's not for any reason other than to continue learning, how do you connect the dots between the idea validation versus the product validation? Because I don't think-

Rick: Let me interrupt you, because I think you just nailed it. It's not the product validation, it's the customer exchange of money conversation. You have an idea of something that will deliver value, but there's a leap between, this will deliver value and solve a problem and an actual payment being received. It sounds like what we're saying is, it's much better, even if it doesn't feel comfortable, to experiment your way towards the payment versus shoot a rocket.

Tyler: Customers are so irrational in a lot of ways where a lot of what they want, they don't know they want. With Less Annoying CRM, there's all these weird things that just delights people. Being able to color code something. It provides no real functional value, but every time we add, "Oh, you can now color code your tasks." "Ah, amazing. Your tasks are so much better now." You'll find weird crap like that that you would never uncover from an interview. But once they start using your product, you'll be like, "Oh, okay, there's tiny little wins here that I can get."


Learnings from Less Annoying CRM’s MVP

Rick: I'd love to hear your own personal story with Less Annoying CRM as it relates to getting from... When did you decide to release an MVP? What were its features? And then how long did it take you to actually collect money?

Tyler: Okay, so I'll go through this, but keep in mind this was 2009 to 2010. I didn't know any of these terms. The Lean Startup hadn't come out yet. This was just gut instinct. But we launched pretty quickly, I think maybe two to three months of actual coding work went into it. Basically what we had was a... What we make now is a CRM, but at the time it was just a list of contacts and the ability to write notes about those contacts and then give each contact a status. Basically a drop down list saying, "What's the status?" That's pretty much what we launched with. You asked about collecting money. We didn't build billing even. For the first three months or so, we had to keep making up excuses for why we weren't billing people. Someone would report a bug and we'd be like, "Thanks so much. We're going to give you two free months for reporting that bug," so that they wouldn't know we didn't have a billing system. But the point being, we weren't even ready to really validate it right away. But yeah, I think we collected money... We 'launched' January 1st, 2010, and we collected money maybe in March for the first time with a very, very crappy product.

Rick: How did you know it was enough to bill for?

Tyler: We didn't. How did we get customers? We just bought AdWords, ads, and random strangers came and signed up. I wasn't using social capital or anything like that. There's this inexhaustible list of people on the internet that you can get to your site with pay-per-click ads. Now it's, okay, maybe for two months, or three months, or six months, none of these people pay. All I lose is a little bit of money. It doesn't really hurt anything else.

Rick: It sounds like you had a pretty sellable product out of the gate. Do you think that you overengineered it to start with, or would you do the same thing again?

Tyler: Well, I had an advantage, which is that I had built something similar at Zane Benefits before that, and people used it and liked it. In retrospect, I should have done more research and user testing and all that. But because I had that from my former job, I was like, "I know what this needs to be. I just got to go build it."

Rick: Why do you say in retrospect you should have done more? You've had success.

Tyler: We ended up making a lot of changes. Where the product ended up being is pretty different from where it was then. It was minimally sellable at the time, but we had a lot of... I guess I'll say this, I was building a CRM. I'm not a salesperson, I've never done sales. No one at the company right now to this day is a salesperson. We have very little internal intuition about what people will like and not like. I should've done customer research because I didn't know my customer very well.

Rick: Got it. I guess, what would that have led to if you had? Would you have launched sooner? Would you have developed better features?

Tyler: I think what I would've done is we would have prioritized features differently. One of the features we launched with is called Pipelines now. It wasn't at the time. It's that status thing that I was talking about which, it's not super complicated to build, especially in the form it was then, but it was a meaningful part of the code base. I would have identified a lot of people. Even to this day, many of our customers don't use that feature. It's our core feature, but 10, 20, or 30% of our customers want something even simpler than that. But what everybody wants is reminders, tasks. I probably just would have figured out, there's a type of person who uses a crappy minimal product. This is the crossing the chasm thing. There's a type of person who's going to use that and really understanding that person and what else they want versus what the mass market wants I think would be valuable.

Rick: Would you build those things, or would you avoid building those things?

Tyler: I don't know if I would have at the time, but if I could go back right now I would have. I would have built pipelines later and I would have replaced it with something that's more core to contact management.

Rick: Interesting.

Tyler: Because the reality is, anyone who needs pipelines, it's like a sales process, you need a level of sophistication. They had 20 other objections that were going to keep them from using Less Annoying CRM. But the person who could use it without pipelines, they only had one or two objections.

Rick: No, this is good. Okay. Let's talk about this. Can we build a framework out of your experience? Because I think this is getting into identifying how you know that you have something that's minimally sellable. I have some hypotheses around... Similarly, in the health insurance example, I know this market. I have a similar advantage to you in the CRM space. Now, I have a lot more customer interviews to do to validate my idea before I would do much of any product development on this, but I guess, how do I know, regardless of the product, feel free to use this as an example, when I found my contact management core piece?

Tyler: Are you able to say anything about what the product might be?

Rick: I'm 100% transparent. If you can copy me and beat me. Good luck. Good for you.

Tyler: I mean can you just give a brief summary, because maybe I can give specific examples then?

Rick: Yeah, so high level, I... Gosh, this is getting into... I can't talk about certain things because of my relationship with my former employer. I'm not able to enter the business that I was in.

Tyler: Okay. Well, if you can't talk about it, that's fine.

Rick: Yeah, I just realized I probably need to be careful and I'd rather be conservative. Yeah.


Taking a productized service approach

Tyler: Okay, don't worry about it. What I was going to get at is, I think there's a big difference between a product where people are buying the experience of the software, they're going to be using the software. Like Slack is this way, you're in it all day, email, calendar. To some extent CRM is this way. Very, very different from, there's some business process that has friction right now and I'm going to remove that friction, because at that point the only thing that matters is, does it accomplish the business process? The experience of the software itself is almost irrelevant at that point. Do you think you're in that latter category where it's about solving a process, it's not about the actual experience using the software?

Rick: I think for a minimally sellable product, it is much more about solving the problem than the experience. I think.

Tyler: That's what knowing you, knowing where your skill sets are and your interests, my guess is that's the type of business you should be in, so I hope that's true. I think an MVP for that... Yeah sorry.

Rick: I would just caveat with, I think that my version of that 10 years ago is very different than my version of that... It has to meet minimum design standards. I think the standard on experience is much higher than what I would like it to be.

Tyler: Yeah, absolutely. I'm not suggesting anyone should punt on design or user experience, I think every product should focus on that. But what I mean, I guess is, where's the value really coming from? That's almost marketing at that point. It's not the core value offering. You know what I mean?

Rick: Yup.

Tyler: I think the way you approach an MVP for that type of business is a little different because, are you familiar with how Groupon got started?

Rick: I'm not.

Tyler: I might be butchering it, because every success story ends up getting reinvented to fit a narrative. But my understanding of it is that Andrew Mason, or whoever the founder, was not technical, couldn't build it himself, and basically just made a mailing list like MailChimp or something and just manually had an Excel spreadsheet and kept track of, did this deal flip or not. Then would email people... There was no product at all. It was literally an email sign up list.

Rick: There was a product, there was no software.

Tyler: There was no software, right. If what you're doing is... Sorry, let me give another example of this before I connect the dots here. You're familiar with the concept of productized services?

Rick: No.

Tyler: The idea is that you start a service business, this is a good way-

Rick: Oh, this is-

Tyler: ... for someone with no money.

Rick: Yes, this is GroupCurrent. GroupCurrent is a-

Tyler: Yeah, yeah, yeah.

Rick: Just to use the example that hits home, we are providing outsourced professional services management for nonprofit or member-based groups. We are using that service to fund and develop a product around community management.

Tyler: To make that more generic, productized services, you start a consulting or contracting business where you're just selling your time for money, there's no product at all. Then eventually you see patterns where you're like, "Okay, I'm doing the same thing over and over and over again. Can I build a product to make that a little easier?" Then you're selling half and half. You're like, "They're hiring me as a consultant but half of the value I'm bringing is this custom software I have." Then eventually you pivot fully to product where it's, "You just go sign up for the software and don't even hire me as a consultant."

Rick: We started at a 100% service and we are about 25% and 75% now. 75% service, still 25% product, and we need to build our own product now because we've cobbled together a bunch of stuff in order to shift further.

Tyler: Right. That's another great way to think of minimum viable products. If you can do that, maybe you don't even need a product. If someone's hiring you for your service to solve the problem, that's a form of validation right there. I guess what I'm getting at is, if solving a process for a company is important, and the fact that it's software that they log into every day is less important, I'd say go solve it without building anything first.

Rick: We've already done that at GroupCurrent. Using GroupCurrent's example, I'm realizing that the minimally sellable product in this case that we need to get to is basically building a custom version of the cobbled together tools that we have right now that does at least what we're doing now.

Tyler: Let me push back on GroupCurrent though. You have one customer with GroupCurrent.

Rick: Yes.

Tyler: You haven't really demonstrated a pattern yet. You could say, "Let's go build the product." But a different approach would be to say, "Let's get four clients like that and demonstrate that they all want the same thing, which really validates that the product is legit-"

Rick: That's a good point. That's a really good point.

Tyler: But okay, so that's one approach. I don't know if that would apply to the health insurance thing, but if there's a way to servicize it, that might be worth doing.

Rick: That's a good idea. What else? What other ideas you got?

Tyler: Okay. That was about as far ahead as I thought. Sorry, just to stay anchored to what we're supposed to be talking about here. What we're saying is, what's a rubric for figuring out what's viable? Let me just recap what I just said. If you have multiple service clients who all want the same thing and that thing could be solved with a product, that's a good, go ahead, you've really validated. What do you do in a case where you can't do that?


Focus on learning as the win

Rick: I would say, in this particular case we do have multiple clients just to close the loop on that, and I do feel comfortable moving forward, but I'm not talking to those potential clients enough to find out what the common feature set is amongst all those-

Tyler: Yeah, because GroupCurrent ones features A, B, C, D, E, F, G, but maybe like-

Rick: The client-

Tyler: ... four of those are common, but there's some other uncommon ones.

Rick: Yeah, sorry to interrupt you. Yes.

Tyler: No problem.

Rick: If productizing the service isn't an option, then I would say what do you do? It sounds like we already talked about it, which is what's your contact management core, like everyone needs this thing is.

Tyler: Yeah. I think if you follow startup advice too literally, people want you to de-risked everything. If you interview enough customers and do this and that, you never have to take a risk. But the reality is there's some risk here. At some point you have to say, "I'm going to spend some amount of time building something just out of faith that I'm going to make this work." Let's keep in mind that that's necessary sometimes.

Rick: Yeah. I think that one way you can get around the emotional side of that is to just justify it with learning is the win, and seeing, "Hey, the goal of this is actually not to make money. The goal of this is to learn how to make money. Eventually if I do this enough times and I learn enough, I'm going to learn how to make money." I'm pretty good about looking at it that way.


Should your business model hypotheses constrain your MVP?

Rick: I just realized, one thing that holds me back too is, I think maybe a lot of companies have a lot of product ideas and so, this is an entrepreneurial thing, they start working the lean startup process, they focus on MVP, but they don't give enough consideration to how they're going to actually build a business model that works, that scales. What are your thoughts on how you constrain the MVP process, the early product development processes and investments, into validating actually business model stuff? Where does that come in?

Tyler: I mean I'm probably not the world's best business model person. I'm very, build a good product and just charge enough that I won't go broke. But one approach I could imagine taking here would be, you're in a nice position here where you have a lot of contacts. You can interview and people who trust you and know you've done this before so you're not wasting their time. One thing you could do is just pick one, or five, or 10 people and say, "This is my first customer. What do I have to build for this person?" In my CRM case, I'm not going to say anyone's name because I don't know if they would want me to. But I can remember my first five or 10 customers. I didn't know them in advance the way maybe you do. But if I could have found one of them, I would have just said, "Hey person. If I build contacts and notes, will you just use it? Forget paying me for a bit. Would you put your data in there?" I could imagine doing that with a handful of people and using that to see, what's the minimum where... People think paying is a big threshold, but just even if you give it away for free, it's still hard to give stuff away for free.

Rick: And get people to actually use it.

Tyler: Yeah. Right.

Rick: Yeah, maybe step one is usage from the people who love you or at least care a little bit about you.

Tyler: Well, the people who are a perfect fit for what you're doing. It could be strangers I think, but if you find someone who's on the far left side of crossing the chasm, the early adopter willing to take a risk on you and basically just say, "What's the minimum thing I can give you that you'll just put data in and login however often?"
 
Rick: Yeah, that's really actually interesting. I'm realizing, coming back to the business model comment I made, I think the business model concept is a constraint on what type of feature set... Similar to how you realized that Pipeline is not the right feature to get enough users to make your model work at 10 bucks a month. I'm pretty sure you knew that you needed to get lots of users at a low price, and that was a validation you needed for your business model. I have a similar thing where I'm going after the lower end of the market, small business in a lot of cases. You got to be able to validate that you can sign people up. This is pretty immediate value. You can get someone onboarded and provide value immediately. You can explain what you're trying to accomplish pretty transactionally. Then ideally, you can deliver a valuable enough experience to where it leads to, has grown your business, which is word of mouth. If you can't do those things with a very small business product or even a consumer product, it's going to be really hard to scale, correct?

Tyler: Yeah. Yeah, absolutely. You just made me think of something else. When you're thinking about the business model, absolutely price point. If you're on the low end, it needs to be self-service eventually or something close to that. 


Positioning matters too

Tyler: Another side of this is, are you creating your own new market or are you competing with an established player, because that probably really changes. Are you framing what you're making as an alternative to something or as a brand new thing. Totally different approaches to what the MVP needs to be, I think.

Rick: Totally. It makes total sense. Let's dive into that-

Tyler: Do you think you're going into one or the other?

Rick: I think in this particular case I have a choice. I could brand it as a new way, old way but I don't know if that's necessary yet. I think that's something I need to figure out because I think that there is a way to explain this as a next step iteration.

Tyler: Yeah. Some companies have had success moving from one to the other. Uber is a great example of this where, when they launched it was like, "You know how cabs suck? What if there was a cab that didn't suck?" Then eventually they're like, "Well the cab market is tiny. We have to change how transportation works." But they were able to first... the MVP was way before they started saying, "We're going to change transportation."

Rick: Yeah. That was absolutely right. They started with, basically, cab on demand. I mean it wasn't even anything different. Yeah, I think that's probably the right way to start from an MVP. I think coming out of the gate with a new way thing is really hard-

Tyler: Yeah, if you're not raising money especially.

Rick: Yeah. Especially that constraint. Yeah, I probably need to constrain myself to something that at least starts as a, "This is a five to 10X better version of a similar thing.


What is the skateboard version of your product vision?

Tyler: Yeah. Okay. Let me come at this from another angle to add on to that. The podcast, Art of Product, which is one of my favorite podcasts. One of the hosts is named Derrick Reimer, something like that. He's starting a business and the way he's going about this MVP thing is, he has this big picture idea for what he wants. He wants to be the toolkit for all statically generated websites to run on. But he started with, instead of saying, "I'm going to make..." There's a picture of this that describes an MVP. Is an MVP of a car a tire? No, The MVP of a car is a skateboard.
Source: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable (Image link)
Rick: I love this, yeah.

Tyler: It's a different product that is solving just one... Anyway, so Derrick's version of this is, he just made a tool for web forms on static sites. This is one tiny, tiny part of it, but it's complete instead of all of the parts that are incomplete, right?

Rick: Yeah. I mean, I think this is where I'm going with... I'm getting to the point where I'm getting validated with how I'm approaching it and I'm feeling much better. I don't want to go into details about the specifics, but one thing that I was really... Here's a couple of takeaways so far that I have. Do you have more to add?

Tyler: Well, what I was going to do next is apply this to GroupCurrent, because we can talk about that.

Rick: I actually think I can... Let's move to takeaways because you've solved the problem that I wanted to do and hopefully my takeaway is, you can supplement with your own and maybe come full circle. I think for the health insurance concept that I'm thinking about that I can't really talk about, which... sorry, I'm just in an uncomfortable situation there. I'm on the right track. I'm thinking about the right way. I feel good about it. With GroupCurrent, I think I was thinking about the wrong way. I was thinking about it as a build the perfect product for our current use case, and I was moving too quickly to a feature set that hasn't been tested against other market items, and the skateboard analogy is perfect for that. It's like, I need to identify the skateboard that is for Pando, but also there's some Venn diagram of what these other customers that are on our waitlist want, and we need to figure out what those are. I actually probably know what they are already, but it's much less than what I was originally going to build.

Tyler: Yeah. Specifically when I think of GroupCurrent, so I don't know a lot about the managed membership software world, but there's a lot of different pieces. There's, you need to be able to build the members, you need to have some email list, you need to have some kind of registration, whatever, all these different pieces. What it sounds like to me is, the MVP is, just build billing or build one piece that you think is particularly weak right now.

Rick: I already have billing built.

Tyler: Well, you've done it in Stripe. You don't have a product people can sign up for and use.

Rick: Yes. I would say... Oh, that's a good point. I didn't understand what you said. You need all these components and the ability to build a sign up form, member sign up, member billing, that's actually not too hard from a where we are now standpoint. The key differentiating feature that everyone wants, but no one can get, is actually having interaction, being able to set up a community that is my own community closed, but allows natural introduction within that community between members. That is the thing that's missing on the market, and that's what PandoLabs desperately needs. I'm realizing that that should be the focus. What's the minimum I need to build in order to deliver on that and keep all this other stuff separate?

Tyler: Yeah. Let me give an analogy to Less Annoying CRM here. Now, we're 10 years in and we haven't even done any of what I'm about to say, but the original vision was not that we want to be a CRM product. The original vision is, I want to be the only piece of software, a small business needs to operate. I want to be CRM, I want to be invoicing, bookkeeping, accounting. I want to be internal chat, email, phone, website, hosting, e-commerce. What we said was, "Well, let's build a simple contact list first because a lot of this other stuff builds off of that, and then one day we can move into that other thing and that other thing" It sounds like that's exactly what you're talking about here.

Rick: Totally, totally. Even right now I'm feeling this urge to go ahead and build the member management, and the sign up, and the billing, but I'm realizing that's working right now. It's not great, but it works. We have a solution for it. We need to prove that we can get people, our existing members, to talk to each other more and merge the online and offline experience of events within a closed community. If we can do that with PandoLabs, we know that there are other... We just talked about this, you have this problem that you're trying to use to incentivize referrals where you need to build a community and you want those communities to talk to each other. You may not charge for the community, but you want them to be able to interact with each other and get value.

Tyler: Yeah. There's Discourse right now, but there's not a lot else out there.

Rick: Yeah. Discourse doesn't have the option to bill. I don't think it does at least.

Tyler: Yeah, I don't either.


Takeaways

Rick: But anyway, one key takeaway is, the situation drives everything. In the case of my health insurance idea, totally different situation. It's not a business that I'm interested in doing a productized service on. There's something that I need to nail first with an MVP that probably doesn't make any money to validate that I can actually do what I think I can do. With GroupCurrent, it's much more of a, "Hey, we've got something here that we've cobbled together with what's out in the market, and there's this massive hole in the market that is preventing lots of communities from maximizing the value that they can provide. Let's go just focus on building that and cut all the other stuff out." That is so huge, so I guess it's... Situation is a big, big thing for me that drives it. There's also constraints that are brought by that situation such as, whether you fund yourself, whether you have partners, what skill set you have around the table, whether you're willing to raise capital, those kinds of things.

Tyler: Yup. If I can just add a couple other concepts we talked about. One is thinking of minimum viable product verse minimum sellable product. The fact that, whatever you want to call it, the MVP of a car is not a half finished car, it's a skateboard, and approaching that with everything. Then finally we talked about the concept of productized service, which is, start with a pure services business, especially for a first time founder, someone who has no idea how to break into it. 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.

Rick: Yeah, and 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.

Tyler: Yeah, absolutely. I actually think, if I were to build a new company right now, one thing I would strongly consider is the only interface is email. There's no web... I mean, maybe there's some website to sign up or something, but the idea being, "You want to do something? Send an email to this address," and six hours later an email comes back to you and the thing got done. That way, who knows what's going on behind the scenes? It's just pure service, but automated.

Rick: I love it. Yeah. I think it's exactly... That actually is what applies in the health insurance example. It won't work for the GroupCurrent example because it requires too much user-to-user exchange. But in the health insurance example, it's very much a user-to-me exchange. Provider exchange.

Tyler: Back to what we said earlier, the healthcare one is solving some kind of business process problem. The GroupCurrent is, this needs to be a tool that people actually want to use and log into and interact with.

Rick: Correct? Correct. I guess that's another takeaway is, whether you're building a business problem solver, a process problem solver, or an engagement productivity tool, that drives a lot of difference in how you approach these things.

Tyler: Absolutely.

Rick: Cool. This is helpful. At the end of day, I think I hit an epiphany pretty early on, so I feel much better. Thank you.

Tyler: Great. Glad to hear it. Yeah, I think we... There's a lot of different stuff mixing around here and it's up to each person to figure out how do you pull a few of these ideas out and apply it. But I think we... if I were starting a company right now and I knew this stuff, it would've gone a lot smoother than it did the first time around.

Rick: I would also say, I did a lot of research prior to this. I tried to solve this problem without talking to Tyler about it because it's embarrassing. I know nothing other than working in the early stages of a startup. That's what I've done my whole life. I don't know any other career except being a bellman and cleaning carpets and odd jobs, but it's something that people act like they... When you're new to this 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 and not worry so much about having the perfect industry-accepted definition for what you're trying to do.

Tyler: Yup. Cool. Well, sounds good. You want to close us off here?

Rick: Yeah, thanks for listening. You can join the conversation on this topic and review past topics by visiting startuptolast.com. If you have questions, contact us via the website or on Twitter, we'd love to hear your thoughts and ideas. That's startuptolast.com. See you next week.

Tyler: Bye.

What is Startup to Last?

Two founders talk about how to build software businesses that are meant to last. Each episode includes a deep dive into a different topic related to starting, growing, and sustaining a healthy business.