When you think about app development for enterprise, what strikes you as an area which is inefficient? x
Traditionally, the goal of enterprise was always to develop the perfect piece of software from start to finish before releasing to customers. This means that finished products were often based on what people thought they should be, rather than following a process which allows the product to evolve over time based on what the end user wants.
This is where “MVP” or “minimum viable product” comes in. Usually associated with startup culture, MVP is a term that came to prominence with Eric Ries’ book, The Lean Startup. In essence, adopting an MVP model means that businesses focus on testing hypotheses, gathering feedback and slowly evolving their app over time to create the product that people really want.
How might this model work for enterprise? Let’s take a look:
The Purpose of MVPs
Going back to that traditional development process an enterprise might go through; typically, by the time needs are identified, requirements are gathered from various stakeholders, specs are created, coding, testing and launching is complete, the entire process might have taken a couple of years or more.
The landscape is changing though, as pointed out by Brian Murray. That long period of development to the “perfect” tool doesn’t necessarily deliver the results for the end user that are required. Not only that, a lot of time and money is poured into the end product, so most companies would prefer to be able to release a product earlier, understand if they’re hitting the right needs and start to realise a return on their investment.
The development industry is competitive and if your process is caught up in lethargy, you can be almost certain that there is another company hot on your heels, possibly in a position to overtake you with quicker development and get to market first.
This is why more and more enterprises are turning away from development methods that require mapping out the entire product from start to finish and are looking toward leaner methods. Agile development allows them to develop in “sprints” and release their product in stages.
Your “minimum viable product” means that you’ve put out a product with sufficient features to satisfy early adopters. It gives you a chance to release something earlier, gather feedback and make any improvements as you go.
Photo credit: Fauxlaroid via Visualhunt.com / CC BY-ND
Minimum viable or minimum loveable?
One of the main criticisms of a lean or “MVP” approach is that many of the resulting products simply aren’t pretty. Generally speaking, we’d like users to fall in love with our products to the point where they don’t want to do without them — some MVP versions simply aren’t delivering on that.
As Laurence McCahill points out; “Too many take Minimum too literally and skimp on the design as well as the scope.”
In enterprise development, it’s often the case that you’ve got a tougher audience to please. You’re trying to sell a product as an essential tool to companies and have their teams enthusiastically adopt it.
This is where the “minimum loveable product” comes in. While following “lean” development ideas still, McCahill states that the minimum loveable product is; “The version of a new product that brings back the maximum amount of love from your early tribe members with the least effort.”
Put another way by Jesus Rodriguez; “focus on viable instead of minimum.”
Getting the Right Feedback
One of the critical issues with traditional enterprise development is that throughout all of the consultations with stakeholders and painstaking mapping of features they “think” should be there, product managers are often not hitting the mark when it comes to the final product.
“When it comes to predicting which features will drive a product in the right direction, humans are wrong most of the time. In fact, studies have found that even the best product manager’s intuition is wrong more often than not.” (Brian Murray)
A challenge of getting the right feedback for enterprise apps is that the end user is hardly ever the buyer. In the consumer market, MVP is made simpler because the buyer is your end user, so how can enterprise filter the “noise” and get good feedback?
Launch internally first
Many enterprise are large enough that it is possible to launch an MVP to your team or a segment of your team internally first. This is particularly useful for data gathering if your product is actually relevant to the team members who are using it.
The idea of MVPs is that you’re using them to gather data, hopefully so that you can vastly improve your product as you go until you have some resemblance of a final version. A concern for enterprises is that, while a typical startup can move quickly, launch, fail, then re-launch under a different name, enterprises have their established good name on the line so it’s not so easy to quickly pivot.
Michael Bamberger talks about the “MVE” or “minimum viable experiment”; “For enterprises, lean means running experiments quickly and pursuing the products and features that consistently perform well in testing.”
The idea is to limit the exposure of the enterprise to any kind of negative publicity. By running as an “experiment” rather than “product release”, you can also better get away with not including cumbersome feedback rounds from various stakeholders. Your goal is usable data which can lead to a great end product.
Launch to small segments of existing customers
Another way to gather good data while limiting your exposure would be to launch to a small segment of your current customers whom you have identified as being the likely target market for your product.
Much like how a startup will have “beta” users, an enterprise can do the same, perhaps starting with an established customer who you have developed a good relationship with. While you probably won’t be charging these users in return for their honest feedback, you might want to look at other validation measures such as net promoter score. After all, you still want to turn out a product people will pay for.
A Smoother Change
Sometimes when product managers within an enterprise want to move more towards an MVP model, they face challenges from the establishment who have been used to an “over-feature” culture, as Jesus Rodriguez puts it. Their view is that the more features, the more robust the product is for enterprise release.
Should product managers meet with resistance, an argument for leaner development measures is the overall smoother change for customers. How? Instead of upgrading your product every couple of years with a large number of extra features and possibly a steep learning curve for customers, you roll out features incrementally, allowing the customer to better adjust to changes as they go along. This can have the added bonus of easing any loading on your customer support due to customers needing extra help for major changes.
Will MVP Work for Your Enterprise?
The minimum viable product idea as defined by Eric Ries provides both opportunities and challenges for enterprises.
On the one hand, you need to be able to move faster and develop products which truly meet the needs of your customers, without being encumbered by a lethargic process.
On the other hand, enterprise product managers are often met with resistance over lean methods, particularly due to the sheer number of stakeholders and concern over the reputation of the enterprise.
However you choose to develop your products, a leaner methodology with development in increments can help to spread your costs, smooth the customer experience and ensure you are able to move quickly to present the features customers really want.
Koombea helps enterprises develop great apps following a lean methodology. Talk to us today about how we can help you.
