MVP: Minimum Viable Product vs. Maximum Value Product

Editor's Notes

• #10: note that this is across paid and free apps, and includes short lived temporal event apps. But, note: a 62% uninstall rate after just the first month, running down to 96% uninstall rate after 12 months. I’d even say that this is worse than presented, as users who paid for apps have a tendency to keep them on their springboard, even if they don’t use them - when they delete them, it’s like deleting the money you paid for it. On the whole, we’re definitely getting something wrong.
• #11: That means that no matter what the revenue numbers say, the majority of apps are doing pretty horribly
• #13: products simply don’t scratch the itch they aimed to or do it pretty poorly.
• #14: a growing trend.
• #15: a company he co-founded which is still active and profitable today. He came to this theory after a couple of his previous startups failed, and has made a name for himself promoting the concept of the Lean Startup through his book of the same name, speaking engagements, and working with entrepreneurs to help them get off the ground and grow.
• #16: Basically, the MVP methodology asks us to reach out to the market sooner than ever before. Whether it’s through a private beta, a landing page, or an AdWords text ad, MVP tries to get actionable feedback from the market as soon as possible, as cheaply as possible, in order to validate a companies assumptions.
• #19: As a methodology, it is positioned as sitting in the middle of two opposing extremes:
• #20: “ Build the blue sky product”, and “Release early, release often”, which is more of an open source or engineers method
• #21: aims to find a balance between the two which limits your financial exposure, while opening up avenues to get real world feedback.
• #22: MVP is unique in the way that it combines market testing right into the earliest prototyping and validation stages of your product. It’s intended to let the market tell you at each iteration, what they like and don’t like, qualitatively and quantitatively via in-product analytics tools like Flurry, Google Analytics, and Localytics, as well as solicited and unsolicited direct user feedback.
• #23: It suggests that you create something that can measure interest in the problem you are trying to solve and the way in which you are attempting to solve it, before you have in fact solved it. It’s a learning process, in theory, with the primary goal of gathering as much data, metrics, and analysis possible to figure out what works and what doesn’t.
• #24: It’s important to note however, that a purist view of MVP is not intended to cater to the whims of your customers, but rather to essentially run experiments on them and derive your own conclusions.
• #25: it suggests that
• #27: Among the many benefits touted for MVP as a methodology include:
• #29: MVP sounds great in theory, and it must have worked for IMVU. But, I argue that it rarely provides any more value than any other methodology, and that it can in fact cause more harm than good.
• #30: In fact, I take issue with the minimum viable product methodology in a number of ways:
• #31: I am of the opinion that going to market too soon in order to validate your ideas and solutions is a lazy and disrespectful way to avoid facing the hard problems head on, working through them to uncover the right solution, and building a great product for your future customers.
• #32: If you do your homework, really “GET” the problems your trying to solve, really “GET” what your target audience wants and needs at the deepest level, and are willing to put in the effort to really figure out what it is that NEEDS to be solved, then you are far better equipped to solve those problems than average people who click on smoke-tests or sign up for private betas.
• #33: If you do your homework, really “GET” the problems your trying to solve, really “GET” what your target audience wants and needs at the deepest level, and are willing to put in the effort to really figure out what it is that NEEDS to be solved, then you are far better equipped to solve those problems than average people who click on smoke-tests or sign up for private betas.
• #34: A Google Beta works because it’s a Google Beta. You’re not Google, unless of course you are, and in that case - carry on. Why should they have faith in you, why should they pony up money or their time to essentially do your homework for you?
• #35: On one extreme, there’s the people that want to hate you from the get go, no matter who you are or what your product does, and are looking for every opportunity to shit on your idea. On the other, there’s those that want to love you and will tell you how much they appreciate where your products going, but, won’t bother you with the minor details because their smitten, or just happy to be listened to.
• #36: In the middle, there’s those that genuinely care about the problem you’re solving, your product and really want to help you help them. But this middle group is often the smallest, obscuring your valuable data from early external testing with overly polarized data.
• #37: Furthermore, actionable feedback doesn’t come from beta testers who want to feel like they’re in the loop, it comes from users who care about your product, who believe in the solution you are offering, who see that you’ve put in the time to build something that caters to their needs. Valuable feedback is inseparable from care for the product. Making product decisions based on the input from random users that aren’t invested in the success of your product is potentially dangerous. I’ve been a beta tester for products that I really wanted to work, really wanted to succeed, but, inevitably, I get bored, busy, or simply can’t be bothered to keep up with the updates, and rarely have I provided any useful feedback. And this is what I do.
• #38: Users, even testers need to WANT your product, DESIRE your product, find it hard to imagine how they got by without it before it existed… this can’t be done with a bare bones product cobbled together to test your ideas.
• #39: This is a horrible misunderstanding of the human connection customers have with the software they use. If you don’t respect UX in your products from the beginning all the way through launch, you are not respecting your audience, and cutting out a huge portion of your potential customer base.
• #40: From a future-looking perspective for your company, even more so if it’s a startup, in creating something minimally viable, something that doesn’t feel whole, and openly testing it in the market, you are establishing a brand association with an incomplete, unfinished and unpolished product. You might as well slap “Labs” at the end of your company name and call it a day.
• #41: Finally, and this is a big one for me, in order to actually get people to use your mvp, click on your AdWord, or follow through to your landing page, and get them in sufficient numbers to actually get any valuable feedback after eliminating the outliers and fanatics, you have to announce that you’re working on something so early in the process that it alerts your competitors, would be competitors and kids in basements to what you are trying to build. Start your photocopiers. It’s hard to validate an idea on this scale, as you have to find the balance between giving the market enough to get interested in clicking or signing up for the private beta, but not so much that your competition can jump on the idea.And let’s be honest, the market has never really lead innovation very far in the past.
• #42: I’m not knocking, or devaluing research and testing. It's a crucial part of successful and respectful product design, but it has it's place.   And it's place is not in the hands of your paying customers.
• #43: As much as I have my issues with MVP as a methodology when it’s executed as it was intended, the misinterpretation, confusion and all out abuse of the concept is where it really breaks down, and drives me crazy.
• #44: Firstly, there’s the emphasis problem. Where companies misinterpret the mvp methodology as MINIMUM viable product vs. the minimum VIABLE product. The “minimum mentality” can easily to take over in every detail of your product development strategy, often at the expense of quality, value and experience. This is ridiculous to me, because the way you create loyalty and customer longevity is through those exact factors.
• #45: Many startups that look at MVP, see a fast, easy way to validate their ideas as cheaply as possible. Problem is, unless you find that your ideas fail REALLY early on in the process, it is certainly not faster - it’s quite the opposite. Building in all this testing, analysis and learning into each iteration can dramatically extend the development process - if you are actually learning from your inputs.
• #46: Similarly, using the mvp methodology isn’t cheaper, again, unless you fail early and abandon your idea. In the long run, if you’re doing it right, you still have to do all the same work you always do to create a new product, including strategy, UX, design, and development but with the additional and potentially exponential costs of doing it in continuous iterative Build Measure Learn loops.
• #47: MVP is a validation and market testing strategy. It is not a go-to-market strategy. If you go to market with your MVP - you’ll get eaten alive. Problem is, many companies are using MVP as an excuse to do just that. Whether its intended from the get go to cut as many corners as possible, and put out a minimum product and ask users to accept it while they prep their “full” version, or if it’s used to excuse "Get it out in the market first and we'll fix it later", when shit hits the fan in the 11th hour and you’re going to miss your launch date, you’re knowingly releasing a broken or hampered product to the market, and hoping no one will notice. I cannot count how many times that I’ve heard this from clients, but I can count, on a single hand, how many times they actually did fix it.
• #48: Whether in it’s pure form, or in it’s misinterpreted form, MVP is a methodology that is creating, directly and indirectly, an environment where it’s ok to fail:
• #49: It creates a mentality that you should EXPECT to fail, and that if you DO fail, it’s not really your fault.
• #50: I mean, I get it: we’ve all been burned on a startup or a project that went way south. It hurts when something you’ve poured yourself into fails. But this does not give you license to not try to succeed with every ounce of your being, every step of the way.To me, MVP feels like a methodology created to shield the founders, the company and the staff from the pain and disgrace of falling on your face. The whole thing is formed around external validation, which actively removes accountability for why you made the choices you made, promotes putting less than great products in front of customers, which are rarely well received to begin with, and puts emphasis on failing early, which sidelines perseverance and faith - two of the most important elements of actually making something great. Sounds like a methodology to arm founders with the perfect excuses after a company fails, not one to ensure the company doesn’t.
• #51: The bar has been raised. The market has matured. The customer has matured. What is expected from new products is tremendous, and if you truly want to succeed, if you truly want to deliver a lasting solution to your customers, minimum viable product simply will not get you there.
• #52: Doing what’s minimal isn’t enough, doing what’s viable isn’t enough. Hell, good isn’t good enough - if you want to build a business around a product or an app you need to aim for awesome.If what you create fails to strike an emotional connection, fails to build trust in each interaction, fails to wow - you’ve failed to impress your user right out of the gate. By exposing users to your products before they’re ready, before they scratch that itch, before they’re able to compete toe to toe with everything else out there, you’re running the risk of those users never coming back, or even worse losing them to a startup that saw your MVP and decided they could do it better, with more resources and more money than you have.
• #53: Trying to create the perfect Blue-Sky product doesn’t make sense for anyone, ever.
• #54: Not even the original iPhone was a Blue Sky product, it didn’t have search, or even copy & paste - the first Macintosh had copy & paste. In the 80’s. But, as a product the iPhone was still awesome, even without copy & paste.
• #55: Browser, iPod and phone, in one device. The reason it worked, the reason it resonated with consumers, and the reason they accepted the lack of search and copy & paste, was that the features the product DID have were meticulously designed, thought out, and developed as a holistic experience that respected the consumer.
• #56: You know that copy & paste was always planned for the iPhone, and at some point it was probably planned to be in version one. They chose to release the device without the feature not because it wasn’t important to the product, they chose to omit the feature because it wasn’t “just right”.
• #59: Knowing when and where to make these hard amputations is even more troublesome. You need to know exactly what problems your product needs to be solving, and how it should be solving them. These are your critical pillars, and what your product absolutely requires to be useful, functional, desirable and respectful.
• #61: When the smartest people in the room, regardless of how hard they try, cannot dig any deeper, and cannot argue the point any further.
• #62: The rest, well, they give you a roadmap for future product enhancements. For example, SwingScore.
• #71: When you focus your efforts on the things that truly resonate with your users, you can more effectively and efficiently make use of your time and resources to build a holistic product supported by those critical pillars. And because you’re not wasting your time iterating based on uninformed external inputs, or trying to build a laundry list of features to see what sticks you can do so with a level of attention to detail, quality, thoughtfulness and respect which will make your users more likely to find your product valuable and compelling, become your early adopters, your grassroots evangelists, and long-term, loyal customers. Even in the face of “missing desirable features”.
• #74: When it all comes down to it, it’s all about the details, the niceties, the design, the user experience, the optimizations, the performance. These are the things that create desirability, these are the things that create loyalty, these are the things that tell your customer you respect them. These are also the things that are generally the first to get sidelined in an MVP, because they are intangible, hard to quantify, and even harder to measure.
• #75: - to paraphrase Steve Jobs - the sane would give up in the face of what you have to go through, what you have to sacrifice to create awesome products. That’s why most companies simply don’t do it. It’s not a matter of “can’t”, anyone can. You simply have to be willing to.
• #80: critical pillars inverse triangle