The Pattern

There is a pattern in product development:

An opportunity is flagged and validated, research is completed to build understanding, a breadth of solutions are considered, solutions are narrowed down and the best are chosen, team builds out the selected options, selected options are tested with users, team hits the “GO” button on estimation and development, but here’s what follows;

Scenario A)
Once estimation is complete, the team goes ,”Wow, this is way more expensive than we thought. Let’s cut x, y, and z out. It’s just an MVP anyway. We can always come back to it. Next phase we’ll tackle it.” etc.

Scenario B) — does not necessarily preclude Scenario A
Once estimation is complete, the team goes, “Wow, this is way more expensive than we thought, but sure.” Then, inevitably, various missed screens, states and calls arise. Despite the fact that they were missed in the first place, some of these things turn out to be truly necessary. Unfortunately though, it’s the eleventh hour and the same backstop emerges, ”Let’s cut x, y, and z out. It’s just an MVP anyway. We can always come back to it. Next phase we’ll tackle it.” etc.

Best case, it leaves a team with no choice but to provide a half-baked experience that doesn’t have all of the necessary ingredients. Worst case, the product or feature gets shelved altogether. It can be demoralizing for that to happen with something that a team has spent so much time developing, workshopping, collaborating, compromising, socializing and aligning others' on. The result is frustration on the user-side, and technical and design debt on the product-team-side. Do we ever get back to tackle those shortcomings? Sure, sometimes. But in my experience it can be years before that happens.

The good news is that (I think) it is avoidable.

The fix

The fix is comprised of two parts: First is defining what the MVP is and what the MVP isn’t. I’ve found that the term has become shorthand for releasing a broken product or service that still meets our launch goals. It doesn’t have to be that way though.

Part 1 — Define the standard of your MVP

In software there is a concept called CRUD that I like to go back to. It stands for Create, Read, Update, Delete and it refers to data that gets stored and interacted with inside of a database. In the software example, let’s take something like writing a document. If we apply CRUD framework to that example, the ‘C’ (Create) means that you can open up a new document. The ‘R’ (Read) means that when you leave and come back later, that you're able to open the document to view it again. The ‘U’ (Update) means that after you’ve stopped writing the document, that you can edit the contents of what’s there upon return. And ‘D’ (Delete) means that you are able to delete that document.

If I can make a new document, view that new document and I can delete that document, but I cannot edit the document, well then i’ve failed to meet my minimum standard for an MVP as defined within the CRUD framework. Assuming cost is the main blocker here, my immediate focus might become figuring out a way to add some kind of minimal editing functionality in order to fill that U-shaped gap. If it requires scaling back (not removing*) other features in that CRUD checklist, then so be it. That's the game.

The CRUD Alternative

We can look at it from another angle in physical products. Let's take a look at the common bicycle. CRUD doesn’t exactly apply in that case, but I’ve created a hypothetical alternative called “PSRS” that compliments the metaphor. PSRS (again, not a real thing) stands for Propel, Steer, Replace, Stop. CRUD is often the standard for when I’m developing or designing software. In the bike metaphor, let’s take PSRS as the standard for our hypothetical bicycle products.

If I can pedal, steer, replace parts, but cannot stop, that's an immediate signal to stop and mark that gap as a high priority fix. In the bicycle example, the minimum standard of what constitutes being a bike is that it pedals and propels, it's something that you can steer and stop if needed, and it's something that has replaceable parts. That’s it. That's the minimum you need for a bicycle MVP. If costs become an issue in the middle of development then the default cannot be to simply strip the bike of it's critical parts (as defined by PSRS). Instead, we need to be more focused on finding cheaper alternatives for said parts. Instead, maybe we only use reclaimed frames. Maybe we use smaller wheels or narrow handle bars since it’s less material to purchase. Maybe we take a haircut on tire quality and size. Developing an entire bike where any part can be replaced without the need for tools would be fantastic, but also expensive. Implementing the tech in a safe way would cost way more than utilizing good old fashioned nuts and bolts and so, in a cash-strapped scenario, the latter would maybe be a better option. Either direction solves for PSRS, but only one fits within the budget.

The important thing to realize is that the proposed solutions, fancy or not, are anchored in PSRS (our hypothetical CRUD): Even with cheaper parts the bike MVP still propels forward. It still steers. It still has replaceable parts, and it still stops. That is a proper MVP, something that is useful and complete. The job to be done, the user story, the use case of getting from point-A to point-B, consider it satisfied 99% of the time.

What Not to Do

Consider a situation where, in the name of cost cutting, we got rid of the pedals, the wheels, the handle bars, or the brakes. Removing any one of those would immediately break the PSRS standard and therefore be invalid for production, even as an MVP. Take the brakes for example. If you got rid of the brakes, you could still get to point-B, sure. It just becomes much more dangerous and risky. The cyclist at this point has very little control and predictability and, as humans, we generally want maximum control and predictability. It’s the least that we expect when choosing products to purchase these days. Same with the handle bars. Without them, you could get to your destination, but at what cost? At what likelihood?

My thought is that building a useful and complete MVP is not about removing parts, it’s about finding cheaper alternatives. The parts are necessary, but the quality of those things? Maybe less so. That is the standard that I think we need to meet. This is the value of drawing your MVP-shaped line in the sand. The value of defining what the minimum standard of your minimum viable product is. Deciding on product direction is hard, but when you set standards and guidelines it becomes much simpler and our chances of success go up.

Part 2 — Start with the end in mind

Read, “Be intentional”.

If you know that the same trimming, de-scoping discussion occurs at the end of every design cycle then why not address it from the jump. Ask the question right from the beginning,

“If we had to do produce this solution in the most minimal way, that meets existing standards, what might it look like?”

It’s as simple as starting with a conversation, but it requires the leg work of actually producing tangible options to go with the same breadth of options that your team might normally had produced otherwise. It’s going above and beyond by visualizing simpler, still viable, options — Pairing a cheaper option with each full scale approach that we might consider going with in the end. The benefit of proactively including this line of thought is that, in the event where we’re back-pedalling in the eleventh hour again, you have viable alternatives that have already been visualized, socialized and aligned on with key stakeholders on the team.

If we go back to the bike example once more, it’s front loading the alternative options to save that aforementioned eleventh hour scramble. Imagine that we’ve flagged an issue to address in our next commuter bike update where the existing tires are unusually prone to flats. The usual story might include some initial options like replacing the flat-prone bike tires with run-flats or tubeless tires. But In the spirit of starting with the end in mind, some alternative, cheaper options that still satisfy the minimum PSRS standard might include pairing a spare tire or a single free repair with every bike sale, or increasing the size or quality of the same tire type. It really can be as simple as that, but the key is to raise the options early on. You are still cutting costs, but you are also maintaining that minimum standard for the MVP. You’re still meeting your PSRS requirements.

In the document editor example, if you aren’t able to implement document editing for whatever reason, maybe as a cheaper alternative you add in file duplication to enable users to quickly duplicate document contents into a new file in an effort to emulate editing. At least in that scenario you’ve provided a path for users to satisfy the editing use case, albeit indirectly. In a round-about way you’ve still met the minimum standard that is CRUD for software. In my experience, it’s more likely that the option gets taken up in hindsight if it was raised and socialized in the same period as the original solutioning.

Thank you for reading.

Nat Green