There was a tweet a couple months ago that helped me pull together a few different things I’ve been thinking about when it comes to recent software projects in the news. It said:
I think when people hear “minimal” in MVP they interpret that to mean “shit” rather than “narrow in scope”. They gloss over “viable” almost entirely, leading to a belief that MVP is short hand for “a shitty version of the product”.
The tweet is from Andy Budd, who seems to be focused on UX and design, and the implication is that the concept of “minimal viable product” is being misinterpreted. That may be true, but in practice it seems like organizations that produce software operate with both conceptions of MVP.
A recent example of a launch that embraces MVP in the “narrow in scope, viable product” is the release of an IRS website to file your taxes, called “Direct File.” If it works, it solves the problem of private companies charging you for the privilege of filing your federal taxes online (you could always fill out paper tax forms for free, minus postage, but who is going to do that?). Direct File launched this winter and closed on April 15th (it doesn’t allow extensions), and it was only available in twelve states. To be fair, these twelve states include very populous states like California, New York, Florida, and Texas so a good chunk of the US population was eligible. But that eligibility narrows, because it can only handle W2 and interest income and it has restrictions on the types of deductions you can take, like completely excluding itemizing deductions. In the end, it looks the pilot was a modest success. The IRS met the goal of 100,000 filing, and there were no horror stories about miscalculations or a non-functioning website. We will see if this pilot is able to expand after the 2024 presidential election, but for now the IRS was able to deliver a functioning service that was limited scope. In fact, on the Direct File website right now, it says that “We’re starting small to get it right.” That is the ethos of embracing an MVP in the positive, “narrow in scope”, sense.
You can contrast this software with another federal government website that launched at the beginning of this year: the redesigned FAFSA (free application for federal student aid). To meet its mandate of launching in December, the department of education announced that it would be in a period “soft launching” at the end of December and early January. Their conception of this seemed similar to the IRS’s; they would make the site available to a limited number of users, take it down when necessary, and make adjustments. In practice, the website worked for almost no one when it launched, it did not calculate aid correctly, and students could end up in situations where they could not submit or correct their application and there was nothing they can do for weeks or months. The department of ed insists that things will get better, and they very likely will, but they launched a product that was almost completely broken and then iterated on it. Their MVP was something that was not actually viable. In the higher education space, we see similar issues with software companies that develop products specifically for higher ed. They will launch something, it will have defects that make it nearly unusable, and then they will spend the next few years hopefully getting it to a point where it is an adequate piece of software.
In every case, agile software development is the guiding approach. The difference is what people consider to be an appropriate starting point. My hope is that we see more software that is minimal, limited in scope, but has the most important feature - viability. Some people can actually use the product and find value in it, and over time the features and functionality of the product will grow until it reaches the goal of being a good piece of software for the target audience. This contrasts with initial releases that are truly non-viable for almost anyone, and the product eventually (hopefully) evolves into something that works. In addition to annoying customers, this approach also raises the likelihood that the software makers will stop investing in the product, because no one using it. The end result is a failed product.
There are more lessons to consider about product launches, but that is for another post.