The Art and Science of MVE
One of the most dramatic and interesting differences between digital products and physical ones is the capacity for digital products to change. When you sell an Air Conditioner, once the customer has it, you can’t really change how it works. You can fix it, and replace its components with identical new ones, but you can’t change how it looks or make it more efficient. If there are critical, systemic problems with a physical product, you have find it before you get too far down the road. Digital products possess a remarkable ability to be fixed, changed, updated, and even completely rebuilt — and all after the customer has already received it. This makes it possible to build large new features, or even completely change the product in its entirety, in smaller, incremental phases. Today we’ll talk about why we should do this, and how.
What is an MVE?
MVE stands for Minimum Viable Experience (this is also sometimes referred to as an MVP — Minimum Viable Product, but because this acronym collides with another one that we’ve talked about before, we’ll go with MVE). An MVE is the simplest amount of change that can be undertaken to fulfill the most fundamental goal of whatever your building. Every product, feature, fix and change can be broken down into smaller, iterative steps, that can each be built in sequence. The MVE is the first iteration in the sequence that fulfills the core function of the change, and can be released to customers. In general, an MVE should be small in scope, low complexity, but most importantly, an MVE is still releasable to the customer. An MVE is a whole product or feature, completed to releasable standards with high fidelity, but low complexity
Why MVE?
Building an MVE, even if you never actually release it, provides some very concrete advantages for just about every department involved in building a digital product. Reducing the scope means it’s faster to build. It also means it’s easier to build, and easier to test. That means it gets you to market faster, with higher quality, and most importantly, the final product is built incrementally.
Those increments can then also be built and tested quickly and incrementally, each building on the progress of the last, and enables verifying at each step that the one that came before it still functions as expected. This is also better for distributed software development teams. In order to meet schedules and deadlines without building an MVE, organizations are often forced to take shortcuts. When different parts of the development pipeline are forced to work in parallel, rather than in sequence, things can get very messy and become difficult to manage. In general, the development pipeline has 6 major parts that produce the highest quality results when worked on in sequence:
- Product Requirements
- Design
- Software Architecture
- Development
- QA
- Release
If we try to develop ALL the product requirements, and All the designs, and so on, all the way down the line, then the system encounters bottlenecks while each downstream stakeholder waits for it’s dependencies to be fulfilled. Or worse, we try to do all those things all at the same time, and now you’re building stuff before you know exactly what it’s supposed to do and look like.
However, If we take everything we want to build, and boil it down to its core function, then each step becomes faster, and takes less time. And while front end devs are building the MVE UI, designers can be working on making the next version better for the user. The other problem with trying to build the final product in one iteration is that we often don’t find all the technical problems until we’re actually building things. No matter how good your technical planning is, once you’re writing tickets and documentation or even lines of code, you’re going to find thing you didn’t expect, and didn’t account for in the architectural solution. This problem is made drastically worse in the architecture and design are forced to work in parallel. Then the engineers designing the system have to guess at everything it might have to do. Better to uncover those gaps and problems in the first iteration, then when you’re trying to build to final product the first time around.
How MVE?
An MVE is not an easy thing to define. There’s no hard and fast way to decide what constitutes both minimum and viable, but if you follow some common sense rules, you’ll get there faster.
For New Features: Build Functionality or Design, but not both at the same time.
First things first, as they say. Software should never sacrifice form for function, or vice versa. Digital front end products should always be a balance between great software and great design. However, when you’re changing things, try to separate functionality changes and design changes. When you change everything, it becomes hard to test anything. So, I find that, whenever possible, it’s better to develop functionality changes first, then change the design. Let’s imagine, for example, that the backend APIs that power our product are changing or growing to support new features. A good organization of work would have you implement those changes to power existing screens and features first (hopefully they are backwards compatible, especially if you’re making mobile apps…), before building anything new. That way, a tester could compare an existing version with the first iteration version and simply note any change at all that they find. With no design changes, nothing should be different. This is called an Apples to Apples Comparison. If you change both the functionality and the design at the same time, then an Apples to Apples comparison becomes impossible. Put another way: Never change both design and functionality at the same time if you can avoid it.
Separate Requirements and Designs into critical and non-critical
When it comes to implementing new features, or even building new products from scratch, not every design element is critical to the experience. (This is in stark contrast to what some designers will tell you). Design is important to designers, as it should be, but as engineers, our job is to achieve compromise around what can be built, and when. It’s the responsibility of the Product and Design departments to decide what gets built, and though engineers can have opinions on that subject, the engineers’ job is only to decide how it gets built. Most of the time, the “how”, also includes “when.” If everything can’t be built by the deadline, everyone has to work together to compromise on what can. This means that every department has to make sacrifices in order to move forward. In every feature that gets built, there’s always a basic function, and its adjacent functionality and design. Learn to identify a feature’s core purpose, isolate that, and build it first. Everything else can wait.
Who MVE?
I never said that creating a collaborative, iterative development pipeline was going to be easy. In a perfect world, everyone in the development pipeline would be thinking about the product as a series of iterations that are each low in scope and complexity, but together can make up bold and dramatic change sets over time. But the truth is that most product and design departments just don’t think that way. In my experience, the creative side of the org will very often prioritize a so-called “complete” experience, and abhors the release of anything less than the entirety of that experience. The business side of the org, however, wants dates, timelines, deadlines and schedules. And those two ideas — scheduled deadlines and the inflexibility of a complete experience — are fundamentally at odds. So who identifies core purpose? Who designs iterations and composes the MVE?
Well, friends, sorry to be the bearer of bad news, but it’s probably going to be you. Engineers often have to serve as a voice of reason and compromise that allows businesses to get things done on time, and get product features to market. There are three main parts of the delivery equation: Scope, Time and Capacity. At some point, the ability or inability to deliver everything on time just becomes a question of arithmetic. If the numbers don’t add up, something has to change.
So, how can we achieve compromise? That’s a not-so simple matter of basic diplomacy. No one wants to be told that they can’t have what they want, especially when making that request is their job. So when dealing with business, product owners and design, always reiterate that of all the changes requested, everything that’s technically feasible will be built. Translation: everyone will get what they want. It’s just a question of when.
Every organization can benefit from an iterative process, but it takes time to transition from the complete-experience mindset to the MVE mindset. And it takes time to get everyone on board. But all it takes is one successful, on-time MVE delivery to change people’s minds. Once you get one MVE out the door, the next one becomes much easier. If you have supportive leadership, open minded product partners and flexible designers, your process will be better, and eventually, your product will be better too.