Recently I had a nice little conversation with a fellow Product Consultant Julian Wild about MVPs – Minimum Viable Products. He asked me what I think about MMPs – Minimum Marketable Products. From there, we got into Minimum Usable, Testable and Sellable Products, and agreed that MxPs are handier in practice than MVPs and MMPs. And that you can apply the concept of MxPs actually to any adopter group whenever you want to tackle the next growth phase.
Here’s my detailed answer:
The idea of the MVP was to build something small enough to deliver the core value of your product that will make a customer’s life better. However, “small” is pretty subjective when you have to decide between qualitative pieces of a product.
Now the term Minimum Marketable Product wants to define the set of features that helps to market the product. Sounds more business faced. Let’s get some “boom” around the product. Let’s make money.
Well… “Marketable” is again something very subjective and depends heavily on the maturity of the product. What do you want to do when you market a minimum version of the product? Do you want to test the concept itself? Then the value proposition without a working product can be already your MMP. Do you want to test the solution? Then your MVP could be your MMP. Do you want to see if people would pay for it or not? Then your MMP needs to include payment. Do you see where I’m getting? If your goal is to find the minimum feature-set to release, the MMP can mean anything and nothing. The same happened to the MVP.
So what is a better approach in practice?
Henrik Kniberg introduced the terms of Minimum Testable, Usable and Lovable Products.
I find the “Lovable” product is still very subjective. What is “lovable”? Lovable means something else for different people even within the same customer segment. What is the goal of being “lovable”?
However, I like the “Testable” and “Usable” product concepts a lot. They are very handy, especially in combination with the idea of Minimum Sellable Products. Why? Because they give you goals that you can work towards.
How MxPs can help you build new products
Yeah, the graphic looks quite similar in its foundation like the one from Henrik Kniberg. So what’s the difference? Let me explain.
Minimum Testable Product – MTP
The goal of the MTP is to, first of all, have – tada – something testable. What do you want to test when you’re about to build a new product? The idea. The concept. The value proposition. Well, the market itself. The innovators and early adopters. You want to know if you’re on to something, if you should really spend time on this problem that you assume to be valuable for the market you’ve selected.
Can customers actually do something with it? Nope. Will you keep it? Probably not. But it’s a tool to get feedback and iterate. On the value proposition. On your targeting. On the branding. Or to kill the project. Without spending time on product development.
Minimum Usable Product – MUP
The goal of the MUP is to have – you’ve guesses it – something usable. You’ve probably heard it often enough: “Do things that don’t scale”. With your MUP you’ll start to validate your solution. It’s something that your customer can already use but it’s probably going to be “ugly” – in the sense of won’t be the best experience. For your customers as well as for you and your team. Processes will be manual, services will take some time to deliver, the product will have many hiccups. Yes, it’s a prototype of your core offering. It’s those techniques like Wizard of Oz, Concierge, Clickable Prototypes with observers, emails, forms and phone numbers instead of payment integration, etc.
You’ll learn a lot about your customer’s priorities, about their expectations on the product, on a good flow, on good service, about your company’s limitations, and what you need to change to serve their needs.
Will you continue using the code that you’ve built here? If you really go full prototype, then you don’t have written code. Or only a little bit. Or really in prototype mode. In that case, you should throw it away and start from scratch when you build the real solution. For your own sanity, believe me.
If you’ve already built something or iterated towards something that is working, you should double-check how good the code quality and stable the system is to evaluate if you should keep it or throw it away.
Minimum Sellable Product – MSP
Here’s the difference to Henrik Kniberg’s suggestion. While I find “lovable” still too fluffy, “sellable” is a more tangible goal. So, now your goal is to sell your solution.
Wait. Why now? Why not earlier?
That’s a great question. Honestly, there’s no reason why not earlier. You can ask for preorders, payment upfront, or whatever before you even build your product. A sale is the best validation of a product or business idea. But then you’ve still only validated the idea itself and that you’re working a problem worth solving. You’ve then still not validated the solution, and not built it.
So, let’s come back to where we were. Now your goal is to sell your solution. You’ve built an “ugly” product and/or service offering before, and you’ve learned what your early market would probably like to see, hear, use. Latest now is the time to find out what the minimum feature- and service-set is to make your early market buy your offering. What are the basics of your MSP? Find that out and build it. You can (and depending on what you’ve built so far probably should) start with a still not full-fledged solution. It doesn’t have to be too pretty, and it shouldn’t be what you would call “feature complete” (guess what: I don’t believe in any product ever becoming “feature complete”). Hey, if the crappy and mainly manual process is not a blocker for selling your solution, then you don’t even need to replace that to have an MSP. It’s really the bare minimum of what you need in your solution to start selling it to more than a handful of early innovators. However, you should have 1 delighter (google “KANO Model”) in your MSP feature set.
I will admit, I didn’t have a strong opinion on whether you should have a delighter in your MSP or not until my conversation with Julian. But think about it, your delighter is your Unique Selling Proposition which differentiates you from your competitors. This gives your customers a reason why they should buy your product, not the competing ones. Therefore, it makes sense to add a delighter to your MSP to make some “boom” when you launch!
Sell your real offering
You see, the MSP gives you the freedom to find out what will actually make your prospects buy your solution. And once you’ve found that out and have your MSP, you can iterate towards the full-fledged shiny version of your offering while you’re already selling your product, providing its core value to your customers, and make their lives better.
Win-win.
