Welcome to software development where acronyms are as common as code! Two terms have gained immense popularity in our industry over recent years: MVP and MVE. These concepts embody the essence of product development and software engineering but are often misunderstood approaches.
Regardless of whether you’re a startup or an established company, understanding MVP and MVE is crucial for success in today’s competitive market. Let’s explore how you can develop the best of both worlds and create an unbeatable product that stands out from the rest.
First, what is an MVP and what is an MVE?
- MVP (Minimum Viable Product): focuses on the practical functions of a product and offers the minimum number of features necessary to solve the problem.
- MVE (Minimum Viable Experience): focuses on the experience that comes with the product.
The Minimum Viable Product (MVP)
Imagine you have a new product; you want to go straight to development, but first, there are some questions you need to answer:
- What are the requirements?
- What is the market looking for?
- How much should it cost?
- What does it need to do?
- What problem are you trying to solve?
You are going to deal with all of this during the discovery and design phases, but the idea is that at the end you will have a product – you will have reached MVP status! You launch it, you’re supporting it, users are using it, and it’s generating revenue. Ultimately, this is when you KNOW how well a product has been designed, and if it’s fulfilling its objectives.
Don’t Let the Glitter of Launch Distract You — Also Keep Your Eye on the Horizon
When designing and building anything, you want to shine the light as far down the path as possible so you know where you need to be upward of 18 months out. As long as you can see that far ahead, you can plan where you want to be with your MVP in the first 90 days, moving toward the long-term solution.
There is no excuse for building quick and dirty, it’s a sure path to failure both in the short and long term. When doing discovery, you need to ask yourself where your business needs to be quarter by quarter, getting as much visibility as possible up to 18 months out.
It’s like driving a car — keep your eye on the horizon, not just right in front of you. You aren’t going to get to the finish line in one step — build incrementally toward your desired result; and this is what the MVP is meant to do.
The Traditional MVP Development Approach vs. the Hybrid Modularis MVP Engineering Approach
When do you need an MVP? Look at incorporating an MVP when you want to:
- Light up net new revenue (NNR)
- Deliver innovation
- Pioneer the market
But again, cast your gaze wider. Developing reactively, without understanding where you need to go and how you want to engineer getting there, is the fastest way to light money on fire.
At Modularis, the first thing we do is meet with our clients to figure out their technology roadmap.
We ask our clients where they want and NEED to be in the next 12 to 18 months. We ask what minimum viable product capabilities are needed. And we help our clients define the technical milestones they need to reach every quarter in order to get to the final vision.
Basically, we illuminate the road ahead so you can calibrate the amount of investment you want to pour into your MVP.
Keeping Your Eye on the Short- and Long-Range Prize
The traditional method of doing an MVP is shortsighted — the presumption that you will have to throw away code is wasteful and absolutely unnecessary. Software products have to be engineered and not developed.
A software engineer understands they are building a durable product, not throwaway code. Long-term clarity, provided by a roadmap, will maximize the reusability of the MVP they help to create.
Creating a Minimum Viable Product vs. a Minimum Viable Experience
This flows into the MVE, the experience; the impact, what drives your growth.
The minimum viable experience is about adding intelligence and thoughtfulness through the entire process from inception through execution. A minimum viable product that delivers an exceptional experience is going to create a user experience where people say “huh, that product is really well thought out.”
This means you’ve made the appropriate investment in designing the experience.
With an MVE, you’re not just thinking about the technical development merits of the MVP, but also considering the software design, engineering, deployment, and support. An MVP is trying to solve a technical problem, but an MVE considers the financial model, support, customer – everyone’s perspective is built into the design.
Take financial models, for example; it’s not uncommon to end up with a hybrid payment system because nobody thought to include a payment solution up front.
How will you collect the money? How will it funnel to your bank account? These are questions that are often missed with an MVP because everyone is focused on getting the code churned out quickly and into customers’ hands.
The MVP is the concrete deliverable, the MVE is the lens through which your target personas receive it. BOTH have value.
One of the biggest mistakes you can make with an MVP is to think of it as a larger prototype and just include developers in the mix — you need the software engineers to help design the product and the experience.
Software Engineering: Risk and Return
Software engineering is fundamentally about two things: RISK and RETURN. Regardless of your approach as an MVP or an MVE, you need to make the choice that minimizes risk and maximizes the return on the investment that you’re making in people, cash, and time for this effort.
The risk inherent in the MVP is high, but if you work with your engineering team, you can have it all — you can have a terrific MVE delivered alongside your MVP, which is rock solid and ready for future growth. And you can do it in 90 days. It just requires a few basic engineering principles:
- Put thought into it.
- Design before you build.
- Make sure what you build today is the foundation for what you need to build tomorrow.
- PlatformPlus® lets you build it right, build it fast, build it to last.
Final Thoughts
We’ve had this company for more than 20 years. I started coding when I was 10, so we’ll say I’m “seasoned.” What I can tell you is that the fundamentals haven’t changed. When it comes down to it, good engineering is good engineering and investing in that is going to maximize your returns every time.
It only takes 15 minutes to see a new way forward – schedule your CEO to CEO conversation today!