The Enterprise MVP

A common term you may hear in the software industry is „MVP”. It’s supposed to be the minimum viable product - the smallest possible unit of software that does something useful. Setting aside the situations where the MVP fails to prove its viability, a common failure mode is the MVP not being minimal. I’d like to discuss several ways the “M” can get left out of the equation.

Note this is based on my experiences, having been on several teams that were, ostensibly, building MVPs. Your experiences may have been much different, and I’d love to hear about them - feel free to contact me.

Conflating discovery with project scope

A well-executed discovery phase is crucial to building what the customer wants - forgive the truism. The business analysts, architects, and (at certain companies) random developers who got swept up in the process will try to learn as much as possible about what the customer wants to build long-term. It is vital to manage the customer’s expectations at this point - taking care to explain that while we’re trying to understand as much as possible, it’s not getting built overnight. Sometimes, this communication is poorly executed, misunderstood, or ignored by the customer, who then expects the entire product to be built in an MVP timeframe and on an MVP budget. From there, I’ve seen it go down one of two ways.

The breadth-first MVP

This type of MVP has “everything” - and those quotes are load-bearing. It will have a multitude of screens. A plethora of forms. It will even come with a sleek design. The only problem is - it doesn’t do much yet.

If the analysts and the managers are smart, they’ll identify one or two core business loops for the customer, and these will get an implementation that somewhat resembles the final state. Everything else is there for appearances - critical business logic missing at best, haphazardly implemented at worst. The company’s logic tends to be - show them something, lock them in, and then we’ll move on to building the rest of the thing. I cannot fault the logic - I can, however, fault the execution.

When I said “implementation that somewhat resembles the final state”, I was generous. Sure, it does something - we’ve got a demo with the customer, it better. But it’s not polished. The corner cases are not handled. Crucially - it will need more work before being given to the customer and solving a business case for them. It doesn’t matter that it looks impressive, because - arguably - it doesn’t work. Not yet, in any case. The customer was shown what could be, though, and they committed to building the project with the company. Contracts are signed, money changes hands - and the devs keep trucking.

Not the worst outcome for the company, to be sure. But could the customer have been served better by the company?

The year-long MVP

That’s the other failure mode stemming from poor customer communication. It has an even funnier sibling, the multi-year MVP.

The customer expects “everything”, and thus we set to work on… everything. We plan out the entire shebang. It comes out to a twelve-month-plus monster of a backlog. This is escalated to the nearest thing we have to management, who decide to make the best of the hand we’ve been dealt. The customer is sold on the entire backlog. This is often packaged in a veneer of “agile development” - yes it’ll take this long, but we’re going to involve the customer in the process, have regular demos with them, take feedback, and iterate.

Congratulations. This project is no longer an MVP - in reality, it’s a… well, it’s a project, isn’t it? We’ve skipped the entire MVP phase and went straight into building the darn thing. The contracts are signed, the devs are assigned, and money changes hands with terrifying regularity.

Hilariously, the team will continue to be told they’re working on an MVP. For a year or more. This might appear as though it’s innocuous - however, in my opinion, it instills the wrong mentality in the team involved. While it’s sometimes okay to cut select corners on an MVP, it is not okay to cut those same corners on a regular project. But since we’re building an MVP - as everybody including the customer keeps reminding us - it should be okay to cut said corners here, right?

As outcomes go, this variant of “MVP” is not the worst thing that can happen, provided the team wises up to it and builds the project right.

The playground MVP

What do you give a restless, jaded senior developer who’s in poor spirits and is grumbling about quitting? A team of junior developers and a green-field project.

If any members of a certain project at a certain company I used to work for read this and think “Hey, that sounds familiar” - yes, this was us. You’ve been brilliant, and I wish I had run that project right. I’m sorry.

Sentimental interludes aside, giving someone bored out of their mind full control over a project that has nothing save a vague spec is not a great idea. The project then becomes a staging area for all the cool things the technical lead read about, but could never try out for themselves. It’s going to be an SPA. We’re using GraphQL. We might even be trying event-sourcing for the first time in this company. It becomes a shining beacon of newness, a fantastic résumé padder, and a horrid boondoggle to work on.

This case is… pretty hopeless. No amount of customer communication can save it. It’s more of an organizational problem - bored people should not be given free rein over what they perceive to be a box of toys. There are ways to solve this - putting in two co-leaders, at least in the early stages, is one. Or leveraging the support network of other senior developers to lay proper groundwork for the project. Or, if we think it’ll work, give the tech lead a stern talking-to before any ground is broken on the project. Otherwise, the customer pays for a few months of a senior having the time of their lives, a gaggle of juniors being utterly miserable, and not much usable product.

The enterprise MVP

I was initially unsure whether this failure mode should be rolled in with the playground MVP. However, having spoken to multiple peers, I think it’s a different beast altogether.

The enterprise MVP is built with the best intentions. It’s not intended to pad any résumés - it might, but almost by accident. It can start - though doesn’t always - with the customer spinning tales about massive scale. Hundreds, nay, thousands of requests per second. Millions, at peak. Literal billions of their customers kicking down the doors in search of their latest and greatest at all hours of the night. We nod sagely in the discovery meetings - quietly terrified. What have we gotten ourselves into?

With the projected RPS figure looming large in our minds, we set to work designing this thing. All our regular approaches won’t work here. This one needs to be different. Better. More resilient. For this one… we need to go enterprise.

We plan a sprawling, distributed system. High-availability everything. Cloud-native since day one, perhaps even multi-cloud. Event-sourcing, eventual consistency, monotonic clocks, and optimistic locks - we’ve heard those words before, and we know what some of them mean. We’re researching if Terraform will even scale to this many nodes. In this dark tea-time of our should, we might even utter the k-word¹. Quietly to ourselves at first. But… why shouldn’t we use it? This is the scale it was built for.

We toil for days, producing a literal white paper on the infrastructure. We’ll need to spend several months on building out the infra alone, after all - this is our magnum opus and it will outlive us. The least we could do is document it for posterity. We crunch the numbers and come up with estimates for the cost to operate this monstrosity. Proud and bushy-tailed, we deliver the entire package to the customer.

They shriek and immediately pull out of the contract.² This is both more money than they were hoping to spend with our company, and way more than they can spend to operate the product. We briefly ponder what could’ve been, before scattering the white paper to the wind.

What should an MVP be, then?

If at times I appear emotional in the paragraphs above, that’s because I was a part of all those projects at some point. To a degree, this topic is personal to me. From discussions with my peers in the industry, it’s become clear that I’m not the only one, either. How then do we make a successful MVP?

Build a vertical slice

If the customer is going outside their organization to get something built, they probably don’t want a small thing. However, only so much can be built quickly and without committing significant resources - which in my mind what an MVP should look like. We can then borrow a concept from our friends over in game development and build a vertical slice of the ultimate product.

A vertical slice of a game is a little polished “bit” of the final product, to be shown off in trailers and at industry events. It serves to show off what could be - to sell the public (or sometimes investors/shareholders) the greatness that will be the final product. It’s supposed to sell a dream. I’d argue MVPs serve much the same purpose: to sell the customer on what can one day be.

This concept may appear similar to the breadth-first MVP described above. It is, but instead of creating a simulacra for a sprawling system, we build these one or two core loops and put all our resources towards it.

It needs to look and feel great - MVPs are as much a visual medium as video games are. It needs those corner cases addressed. It needs to be usable - much like a video game vertical slice should ideally be playable - today. From there, if the customer is sold, we can go into the agile loop of feedback and iteration, while addressing further business needs with a similar level of polish.

Don’t cosplay Google

Customers’ dreams of scale fail to materialize, in my experience, eight times out of ten. By the time we’re serving multiple hundreds of requests per second, we can expect there to be enough money left over to extend the team and scale the product. If there isn’t… something went wrong.

Critically, don’t start with Kubernetes this, and distributed that. YAGNI. Start with a good old monolith - like buying IBM, nobody ever got fired for that. Do you know how to scale that Kubernetes deployment? I don’t either. But we both know how to scale a monolith - yep, run it on a larger server. Run two of them if you absolutely must.

Indeed, skip the fancy SPA if you can swing it - while there are apps that benefit from being built as one, in my experience few business applications do. There’s a velocity cost to building distributed apps, and there’s a velocity cost to building SPAs, and in the MVP stage velocity is king.

Keep the building blocks simple, build a great, cheap thing, and iterate from there.

No lone wolves

I don’t believe in design by committee, but designing in an echo chamber - regardless of whether that echo chamber is a roomful of people who don’t know better, or your rubber ducky - is terrible. Put two people on it for an afternoon, it’ll be much better. Regular check-ins with somebody technical can help to suss out wild ideas that don’t pass the sniff test. It’s not a huge time commitment for either party, and stupid ideas tend to sound stupid when spoken out loud.

This is a point I feel strongly about. I can recall - with painful clarity - many decisions that came back to bite me in the rear. I know that if I ran them past any other senior dev, they’d tell me it’s a bad idea. To summarize:

Conclusion

MVPs are a great tool to explore possibilities and bring value to the customer quickly and cheaply (for both parties involved). To serve that purpose, they need to be done right. I hope the ideas and guardrails presented here resonate with you, and you’ll find them useful the next time a project is barrelling toward one of those kinds of doom.

If you do, I’d love to hear from you - go to the main page to contact me.