Getting to the “Right Minimum” in a Minimum Viable Product
It’s been a busy three weeks since Steve’s last meeting with Mary. Her advice about first using demos for defining (before building) an MVP finally clicked even though he had heard her say that many times before, it hadn’t registered the way it did during their last meeting.
The brain is funny that way.
Since the meeting, Steve has managed to stay disciplined about fighting his natural urge to start building out his solution. He has instead racked up another two dozen customer interviews testing his offer.
It’s been an invaluable process.
The part that surprised him the most was how quickly his potential customers forgot (or didn’t care) that they were looking at a mockup versus a fully functional product. The trick, he realized, was taking the time to develop a high-fidelity mockup versus using just a simple wireframe for the demo. While a high-fidelity mockup is more work than a wireframe, it was still a lot faster than building a working product. More importantly, it got his customers to engage him in deep feedback.
And because changing a mockup is much easier than an actual product, he had gone through numerous iterations quickly and eventually got his customers to want his MVP.
But also because a mockup is much easier to change than an actual product, he now had a new problem: scope creep.
Getting to the right minimum
“The good news is that I have a dozen customers ready to pay for the latest iteration of the MVP I demoed them….”
Mary interrupts: “How did you test their willingness to pay?”
Steve smiles: “Don’t worry, these aren’t just verbal commitments. I got them all to sign-up for a paid pilot, as you suggested. They all provided their credit card info which I’ll charge once they start using the MVP 4–6 weeks from now….”
Steve pauses, then sighs: “…the only problem is that this latest iteration I demoed them will take more like 4–6 months to deliver.”
“ I see,” Mary responds.
“I couldn’t help it…Customers started asking about a few additional features. They all started as fairly small requests. So I agreed to add them to the demo. It wasn’t until I started planning out the implementation did I realize the true scope of the changes.”
Race to deliver value
Mary starts by reassuring Steve that this is very typical.
“It’s natural to incorporate new customer feature requests during the demo process in order to better understand your customer’s needs and get them to buy. But once you repeatedly get them to accept your demo, your next job is negotiating a scope reduction in order to get something in their hands faster. The first challenge in building a business model is getting customers to buy into your promised value. The next is racing to deliver that value.”
Steve responds: “I guess you’re supposed to feel embarrassed by your MVP, so maybe I should just deliver them something to start with and then iterate from there?”
Don’t be embarrassed by your MVP
“I understand where the ‘If you’re not embarrassed by your MVP, you’ve probably built too much’ sentiment comes from and why it’s important, especially for makers, but I don’t subscribe to that approach. Remember that throwing a crappy MVP over the fence doesn’t turn customers into testers. It just makes them leave and search for something better.”
Steve laughs. “Yes, I was there not that long ago. It was painful. So how do you parse out the right minimum in your MVP.”
“It should come out of the demo process, which is part discovery, part validation, and part prioritization. The art of the demo process is ending up with the smallest demo that still gets customers to buy.”
Mary sees Steve’s eyebrows lift, so she elaborates further.
“Many of my demos start out small. They then mushroom into something bigger as I incorporate new customer feedback. I intentionally stay open to new ideas at this stage and even go out of my way to solicit feedback and additional feature ideas because I’m still in discovery mode. But once my demo starts clicking, I then revisit my demo. I start by searching for key ‘money-slide moments’. These are the ones where you can visibly notice a shift in your customer’s body posture when you present them. That’s usually where your UVP (Unique Value Proposition) lives. Your MVP is all about delivering on your UVP. I start with that as the core and build up from there — adding only what’s needed to deliver a functional product. There are often many features that can wait until later or have to wait until later because they depend on other features. I then present my refined and smaller demo both to new and old prospects…If I can still get them to buy, I have my MVP definition.”
Mary lets that sink in and then share a cooking metaphor:
“Think of the MVP definition as a French reduction sauce. The chef starts out with a pot full of ingredients, which over the course of several hours, are boiled down to extract the core essence of each ingredient — ending up with a much smaller amount of a rich, intense, and flavorful sauce. When the chef spoons that sauce on your plate, they aren’t embarrassed, but rather treat it like liquid gold.”
Mary checks to see if Steve gets the metaphor…Then continues…
“It’s the same process for getting to a Release 1.0 MVP. To get to the minimum feature set your customers will buy, you have to throw a bunch of feature requests into the pot and then distill them down to an MVP. If you follow the process rigorously over several weeks, you end up with an offer of a product that your customers cannot refuse (a mafia offer). Like the chef, you should present your offer confidently, not as an embarrassment.”
“That makes total sense…But even after all this, couldn’t you still end up with a complex sauce…umm, a complex MVP that still takes a lot of time to build?” Steve asks.
Embrace a time-box constraint
“Yes. That’s why time-boxing the MVP build phase is key. Without a time-box, we makers quickly fall into scope creep during requirements gathering, and flow state during the building phase — where we lose track of time and weeks quickly turn into months….”
“Yeah, been there too….” Steve admits. “So what’s a reasonable time box for delivering an MVP?”
“The fastest MVPs I’ve seen have been built over a weekend. It’s more important, however, to constrain the upper limit. I like to use two months as my upper limit — especially with software products.”
“Why two months?” Steve asks.
“Any longer and you risk losing the prospect’s interest, and you often have to start the solution interviews all over again… Your prospects may no longer be in the same role, have left the company, have found another solution, or simply don’t remember your product.”
“And you said two months for software products…Does a different time box apply to other kinds of products?”
“Sure. You couldn’t build a phone or a car, for instance, that quickly. It took Apple and Tesla much longer to launch their MVPs.”
“Wait.” Steve interrupts. “Are you calling the iPhone and the Tesla Roadster an MVP?”
MVP is an internal label
“Yes, I am. Sure, Apple and Tesla would never label them as MVPs publicly. Neither does the chef, and nor should you. But they all fit the classic Release 1.0 MVP definition: The smallest possible solution that makes customers switch. Both the iPhone and the Roadster had missing features at launch. But what they delivered realized a new and compelling UVP that mattered — that caused a switch. Both companies continued to evolve these products further (and are still doing so) through fast and continuous innovation. That’s how products get built in the new world.”
Steve nods.
Speed is relative
“But back to my original point….” Mary continues: “Speed is relative. You only need to go faster than your closest competition to win. Even though Tesla wasn’t iterating as fast as Facebook (which runs thousands of experiments a day), they were moving at light speed compared to other car companies. If you can outlearn your closest competition, you win.”
“That’s cool…But coming back to software products….I still don’t think all software MVPs can be created in under two months. Enterprise products are complex. One must build features like user management and security to be taken seriously. Even if I manage to reduce feature scope, to deliver to enterprise customers, I have to go through a lengthy IT security assessment, then a procurement process. There are two months right there.”
“Sure, not all software MVPs can be created in under two months, but you won’t know until you truly embrace this constraint. Constraints are a forcing function and have a way of propelling us to think differently. Yes, not all software MVPs can be created in under two months, but you still need to release an MVP in under two months. So what do you do?”
Steve has a blank look on his face and shrugs his shoulders.
Mary smiles: “This brings us to another critical mindset often missed with MVPs.”
Give yourself permission to scale
“Product folks are often obsessed with scalability. We worry about serving our one-thousandth customer before we even have our first customer. This is the premature optimization trap. We also build enterprise software at my company. Our first MVP had none of the things you brought up. Why build extensive user roles when you’re running a pilot with an early adopter group who are more interested in realizing the unique value you bring than wondering whether you can implement user roles or Single Sign-On? Did you know that when the iPhone came out, it didn’t have cut-n-paste? Or Tesla’s second-generation Model S didn’t have memory seats at launch? People still bought these products because of the UVP of what was there. They knew these other features would be added subsequently through software updates.”
Mary waits for a response from Steve, but he doesn’t answer. So she continues…
“As to process stuff…Our early adopters were our internal champions and walked us through a fast-track piloting and sales process that bypassed rigorous IT scrutiny and a lengthy procurement process. We eventually went through all that, but in parallel, during the pilot process.”
Steve finally speaks up: “But what about analytics, customer support, and dev ops? All that infrastructure stuff takes time to set up?”
“When serving just ten customers, you don’t need fancy analytics. You can pick up the phone and talk to your customers, or better yet, visit them on-site.”
“Just ten customers? But shouldn’t I be thinking beyond ten customers?” Steve asks.
“Right there, that’s the premature optimization trap. If you can’t make your first ten customers happy, what makes you think you can make 100 or 1,000 customers happy?”
Before Steve can answer, Mary goes on…
“You can keep yourself busy trying to plan for scale, but you can’t foresee your business model bottlenecks ahead of time. So far, you’ve been at this for over a year now. And your constraints haven’t been technical risks but customer and market risks. Until you get your first ten referenceable customers, that’s probably not going to change.”
Steve is motionless. He gets that way when he’s deep in thought.
The 10X product launch strategy
“The antidote to the premature optimization trap is embracing a systematic 10X launch strategy. Don’t worry about getting to 1,000 customers. First, get to 1, then set yourself up for 10, 100, 1,000, and so on.”
“That’s the shape of a hockey-stick curve. Isn’t that limited to hyper-growth startups?” Steve asks.
“Yes, it is a hockey-stick trajectory, and no, it isn’t limited to hypergrowth startups. All early businesses grow this way. Think of it like this. All businesses, even Facebook and Amazon, started with just one customer. They then doubled to 2, then 4, then 8… which is close enough to one 10X. Most businesses will acquire 100 customers and some 1,000 customers or more. Right there, you have three 10X jumps.”
Steve jumps in: “So the only difference between Facebook and my company is that they 10x more times?”
“Bingo. Facebook 10X’ed nine times in 8 years. That’s how they got to a billion users.”
Play out the hockey-stick
Mary goes on…
“But while all businesses grow non-linearly like a hockey stick, the premature optimization trap is trying to brute-force the right-hand side of the hockey-stick curve. This is where you see startups do silly things like implement growth hacking techniques before product/market fit or lose needless sleep over scaling risks when they aren’t at that point. A more sane approach is to play the hockey stick versus letting the hockey-stick play you. ”
“What do you mean?”
“Well, instead of trying to predict future bottlenecks in your business, which is difficult and subject to your Innovator Bias, instead embrace a deliberate 10X staged rollout strategy. Don’t build for 100 or 1,000 customers prematurely, but just your first 10. Get to repeatability first. Then level up. Not to another 10, but aim for a step jump to 100 customers. How you make these jumps is the propelling question that forces you to deeply study your current condition and optimize for the right constraints at the right time.”
A light bulb moment goes off for Steve.
“This is a lot like the Theory of Constraints?” Steve interjects.
“It’s exactly the Theory of Constraints — but applied to business models.” Mary smiles.
Steve gets excited: “So all I need to do is focus on delivering value to my first ten customers. That will certainly reduce complexity.”
Then his excitement fades away.
“But I still don’t think I can deliver my core UVP in 2 months even with the leanest MVP I can think of….”
Mary interjects: “The Release 1.0 MVP is certainly the most common, and often only MVP type, that people consider. But there are two additional types of non-traditional MVPs that allow you to go even faster.”
“Non-traditional MVPs?”
Customers care about outcomes, not your solution.
“Remember that customers don’t care about your solution but about achieving outcomes. Sometimes knowing too much about your solution can hurt the sale. For instance, many people like to eat sausage, but once they know how it is made, they don’t want it anymore.”
Steve laughs.
“Once you give yourself permission to scale and embrace a 10X rollout, it opens the door for two other types of MVPs: the Wizard of Oz MVP and the Concierge MVP.”
“Wizard of Oz? Like the movie?”
“Yes, like the movie. Remember the guy behind the curtains? This is the “fake it until you’re ready to make it” MVP, where you cobble together existing solutions to deliver something to customers faster while still focusing on your core UVP.”
“Do you have an example?”
“The Tesla Roadster we just talked about is classic Wizard of Oz. Tesla realized that to deliver their UVP promise of an all-affordable electric car, they needed to build a better battery. If you are building a better battery, why build an entire car? Designing and building a brand-new car is hard, but it wasn’t the riskiest part of Tesla’s UVP. So Tesla opted to license an existing car, the Lotus Elise, as the shell for their battery. They didn’t need a big factory, need automobile designers, etc. That’s how they got to market with a road-ready vehicle in under three years — which is light speed compared to other car companies.”
“Fascinating…” Steve adds.
“But that’s not all. Have you ever wondered why Tesla licensed a $100K+ sports car for their MVP? This is the opposite of an all-affordable electric car.”
“Does this have something to do with a 10X rollout?” Steve sheepishly asks.
“You were always a fast learner.” Mary smiles.
“Yes, by increasing the price of the MVP, Tesla controlled demand. They were playing the hockey stick curve and gave themselves permission to scale. This was all part of Elon Musk’s secret master plan that he blogged about back in 2006 — starting with a low-volume car, then moving to a mid-volume Model S, and finally, the mainstream Model III. It was a 10X rollout.”
“I see,” Steve jumps in: “And by raising the price, they would also have attracted a specific type of early adopter which probably sped up their learning in the early days.”
“That’s exactly true. Can you imagine what would have happened if they had announced a $30K electric car in 2006?”
Steve quips: “Elon Musk would have had to work an extra 120 hours on top of the 120 he already works.”
Mary bursts out laughing.
“A variant to the Wizard of Oz MVP is the Concierge MVP, where you become the product until you’re ready to fire and replace yourself with your actual product.”
“Like using services or becoming a consultant?” Steve asks.
“Exactly. It also shows that customers are more interested in achieving an outcome than how it is achieved. Suppose you can promise an outcome, like a key market analysis report. In that case, you could offer this as a service to your first ten customers and get started by manually putting this report together. Since it’s a manual process, you’ll hit a scale constraint quickly. But remember, you’re intentionally giving yourself permission to scale. Behind the scenes, you start investing effort toward automating the most time-consuming parts of your value delivery process. And progressively level up to serving 10, then a 100 customers…until one day you completely fire and replace yourself as “the product” with your actual product.”
Steve jumps up from his seat and starts packing his notebook and things.
“What happened?” Mary asks. “Late for a meeting?”
“No. I just realized what I could use for an MVP. I can get this thing out in a week. I need to get to work.”
Steve hugs Mary, says a hurried goodbye, and takes off.
Mary laughs and shakes her head.
.
.
Looking to transform your mindset from artist to innovator?
Check out our latest resources at the LEANSTACK Academy.
.
.
