Minimum Viable Products for Enterprises
The purpose of a minimum viable product (MVP), as defined by Eric Ries in lean startup, is to learn about customers with limited effort and money. In the blog post the problem with a lean startup: the minimum viable product, online marketer Paul Kortman shares his experiences developing a minimum viable product. He starts by shortly explaining what lean startup is:
The basics of the lean startup philosophy are to get user feedback, do user testing, and discover if people are willing to use (and pay for) the product you are creating both before and throughout the creation process.
Lean startup has the intention of making organization more efficient, by finding out quickly if there is a need for a product that they wants to develop. But organizations sometimes find it difficult to define a minimum viable product:
We all understand what Product means, and Minimum makes sense: what is the bare essentials that you can get away with?
Paul describes the questions they had while trying to develop a minimum viable product:
At what point does our product become viable?
- When we reach critical mass?
- When we have no other features to build? (ha that’ll never happen, I’m a visionary don’t you know)
- When we bring in revenue?
- When we make profit?
In the Forbes article the times are changin': the evolution of enterprise software, the director of enterprise strategy at Yammer, Brian Murray, describes what is changing in the development of enterprise software with lean startup, and why these changes are necessary:
A rampant inefficiency in traditional enterprise technology development is the attempt to build the perfect product before it’s released to customers. (…) Development teams are now focusing on building MVPs whenever possible. (…) allows service providers to efficiently test their hypotheses and ultimately create a product that slowly and continuously evolves into what it should be, not what people think it should be.
In the blog post minimum viable product vs minimum delightful product, Adam Berrey gives his view on how a enterprise minimum viable product looks:
(…) an enterprise business system will usually win on underlying technological innovation, features, and sales/marketing. If you can get just enough features to start selling, then you have something viable. You’re off and running.
Jesus Rodriguez explains in his blog post the enterprise minimum viable product: focus on viable Instead of minimum how enterprise software development is different from from consumer product development when it comes to minimum viable products. For the consumer market the user of the software is also the buyer. This is rarely the case in the enterprise world, which challenges getting product feedback:
(…) the people trying the MVP are rarely the ones making the ultimate purchase decision. (…) enterprise software startups need to be able to carefully evaluate the feedback received from an MVP, filtering the noise from the features that will make the product more relevant to potential customers
Another challenge for the concept of minimum viable products for enterprise software is how organizations base buying decisions on functionality. Jesus Rodriguez describes this as an “overfeature culture”:
For decades, enterprise software has evolved in the middle of a culture that value the number of features over the simplicity and usefulness of a product. By presenting an MVP version of your product to enterprises, you might run onto a wall of prejudices that tend to associate the number of features in a product with its robustness and enterprise readiness.
The blog post lessons from agile – the minimum viable product by Sam Palani describes why they used the minimum viable product for a complex enterprise initiative:
Yes we were bringing in tons of data and writing really complex ETLs and interfaces to extract and manipulate the data, but the actual business functionality was getting released in future releases and further planned out sprints.In an ideal world we still would have been able to succeed with our current planned approach, however in the real world we could sense the risk of our stakeholder’s patience running out.
He explains how he sees a minimum viable product, and how you can use that to develop and deliver a minimum desirable product:
A minimum desirable product goes beyond viability to include more scope and features from the requirement or scope document. Ideally you should plan a agile release or sprints with a MVP progressively moving to the MDP state in the next iterations that would deliver maximum business benefit and customer delight.
Sam describes a 5 step process to identify and define an enterprise minimum viable product. The steps are identifying stakeholders, scoping, dependency between features, prototyping, and aligning the minimum viable product with the business needs. Step 3 is about the product features:
Limit the number of interdependent features that you include in your MVP. Focus on the viable, but keep the minimum in mind. Having too many interdependent feature will limit your ability to do so.
4 Steps to the Epiphany
When you are designing your tests for B2B or internal enterprise software, do you have Value Propositions for:
- Decision Maker
- Economic Buyer
Do customer interviews and research to understand all of these players. Create personas and empathy maps to flesh out the nuances and use them for your Business Model Canvas. Do you see how they relate? Do you see how they could influence your business model design or product? Do you see how you could design experiments to validate your riskiest assumptions about each?
Customer Development saying is "Get Out of the Building" but some of you just need to "Get Out of Your Cubicle". Go immerse yourself in the problem and the people before rushing to build. Customer Development isn't exclusive to B2C outside of your building.
If the metrics don't make sense then don't use them. What metrics are you trying to influence then? AARRR (Acquisition Activation Retention Referral Revenue) may not apply but there should be some metric for some reason you are trying to move the needle on.
Design experiments to measure that.
As soon as you think about this as a project with a fixed release date and fixed amount of features you've lost the spirit of what all of this is about.
In that case you might as well replace "MVP" with "Requirements" and be done with it because you've only changed the language, not the behavior.
Re: 4 Steps to the Epiphany
Do you have any additional advices specific for Enterprise Minimum Viable Products? Like examples of Enterprise MVPs, enterprises that you know that use lean start-up, successful practices to define and measure Enterprise MVPs?
MVP is wisdom packaged as an acronym
That service is: to challenge and confront everyone to focus on how to get the highest possible learning yield from each and every unit of effort invested in product development. On how to get 10x, 20X, 100X improvement in the learning-to-effort ratio.
Team learning is not random and is nearly always a fully intentional act at the group level. Those groups unwilling or unable to accept and apply MVP to product development are at a serious disadvantage in the new, new product development game.
Re: MVP is wisdom packaged as an acronym
Eric Ries MVP = Smallest possible experiment to test a hypothesis.
Marty Cagan MVP = Smallest possible product that is usable, valuable and feasible.
Re: 4 Steps to the Epiphany
Mid size b2c seems to be most receptive to Lean Startup at the moment. They are bigger than a startup, but not yet weighed down by project mentality. Since they are b2c it is easy to think of new consumer focused solutions and then rapidly iterative through them. You may have to play nice with legal, marketing and accounting but it isn't such a stretch to spin up a fake solution under a different domain & brand yet refer to your org in the terms of service.
Large b2b are probably struggling the most right now trying to see how or if this applies. We still have this myth that customer development isn't needed as our users are "mandated to use our product".
Let's face it, even in large companies mandates can be side stepped. You still need to solve real problems and while it isn't b2c with a fake door, you can create a business model canvas, empathy maps and design experiments for your b2b or internal project.