Maximizing the Value of Minimum Viable Product
When enterprise software projects fail, it is usually not from a lack of skilled developers, detailed requirements or meticulous controls. They fail when development efforts are not focused on achieving clearly defined solutions to tangible business challenges. They fail when the internal stakeholders they purport to benefit feel no connection to or ownership of the outcome. They fail when a solution takes so long to deliver that the business challenges it was conceived to address have been eclipsed by more pressing concerns.
In the face of these challenges, many organizations are maximizing their potential for project success by embracing the concept of minimum viable product or MVP.
To illustrate the benefits of adopting a minimum viable product delivery approach, consider for a moment a real-world analogy. Anyone who has eaten at a fast food restaurant more than once has become intimately familiar with the following simple process:
You place your individual order when you reach the front of the line
Work begins on your order as soon as it is received
Your order is delivered to you as soon as it is ready
Even during the busiest lunch rush, your order is treated as a standalone product, which must be completed and delivered as quickly as possible. To emphasize the point of this analogy, let’s consider an alternative approach to managing the “fast food” experience:
You enter the restaurant, noticing that the lobby is already half full of customers waiting to order food. There is no line (since prioritizing any one customer might offend the rest), so you mill around, waiting for ordering to begin.
Once the lobby has become so packed that no additional customers can enter, employees begin shouting out food items, looking to get a count of how many customers want to include them in their orders. This continues until an exhaustive survey of the entire menu has been completed. The confirmation process can now begin.
With all order requirements gathered, employees begin reviewing individual requirements with each customer. This is when expectations may need to be reset. “I realize you wanted onion rings, but everyone else wants fries. Given the level of current demand, you’ll need to settle for the fries. Or perhaps you can wait to see if onion rings take higher priority with the next order.”
Once requirements are confirmed (or revised) with all customers, the order can be processed. All cooking and packaging is done together, and the entire order is presented to the lobby full of customers at once. Shouldn’t take more than an hour or so.
This revised approach to meal preparation is preferable to the previous alternative, no? All stakeholder requirements were taken into consideration and, within practical reason, incorporated into the final design of the order. All of the deliverables arrived in one release, so no stakeholder felt less valued than the others. All of the designs confirmed prior to order processing are readily discernible in the delivered product. Admittedly, the fries are now cold and congealed. The melted ice has left the drinks watery and flat. Every burger is plain, since the level of effort for customization proved too complex, and pressure to meet the time expectations forced the decision to leave final product configuration to the end customers. But the order was delivered on time and on budget. Perhaps this is what success looks like, and this business will thrive. Perhaps not.
If the process improvement of the second scenario sounds ridiculous, then why does it sound so much like the last IT project your company completed? If the more familiar fast food workflow feels oversimplified, at least consider some key points it illustrates:
Each order optimally addresses a very narrow scope (in this case, the needs of one customer)
Orders are given a priority, and efforts are focused on delivering each order as quickly as possible
Delivery of one order does not depend on completion of another order
Multiple orders may be in process at any one time, depending on the bandwidth of the organization
Understanding why these principles work for delivering fast food is simple and intuitive. The key to understanding how these same principles help improve software development projects lies in understanding the value of all three aspects of a minimum, viable product.
Minimum
We have all heard the expression “less is more”, but why should that make any sense? No one ever went to a final job interview and approached the question of salary requirements with a “Less is more!” attitude. So why would you want a project to consist of the narrowest possible scope your team is capable of delivering successfully?
The answer is focus. Focus matters. Unless a project directs enough of its resources into solving one really big issue, it runs the risk of nibbling around the edges of many pain points without making much progress at addressing any of them. To gauge whether your project has sufficient focus, here is a quick test:
Give your project a name and a purpose statement (no more than one or two sentences)
Find someone who knows nothing about your project
Tell them the name and purpose statement for the project, and have them guess what you’re doing
If their best guess doesn’t encompass more than half of your project’s objectives, the scope of your project is insufficiently focused
Defining project focus this narrowly (minimally) requires organizational discipline that must be learned and reenforced. Analysts must identify the single most critical challenge the business currently faces. Architects must define a solution that addresses that challenge as narrowly as possible. Senior Leadership must commit sufficient resources to implementing that solution as quickly as possible. Managers must prevent those resources from being diverted to other, less critical business priorities, until after the solution has been successfully implemented.
Product
So the scope of our initiative has now been minimized, but what makes it a product?
Apple founder Steve Jobs is widely credited with popularizing the phrase “Real artists ship.” Stinging from a two-year delay in releasing the first incarnation of the Macintosh computer, and painfully aware of the rapidly growing market share of IBM-compatible Microsoft solutions, Jobs arrived at a conclusion that would drive much of the rest of his career: until you place something in your customers’ hands that helps them do something, get something, or learn something, you do not have a product. You have a hobby.
Techno-partisans have quarreled for decades about whether or not Steve Jobs was correct in his belief that Microsoft was failing to turn out products as elegant or innovative as the solutions that Apple was developing. Jobs was forced to accept, however, that Microsoft was winning the war for control of desktop computing. They were winning in large part because they were more available.
As Jobs learned, for any solution to add value to an organization, it needs to ship. Waiting months to address the company’s most critical issue because the proposed solution is engineered to address a smorgasbord of less important concerns is a recipe for turning a bad problem into a worse problem. Delivering a targeted solution to resolve even a small portion of the company’s most pressing business challenge generates benefits well beyond the incremental improvements scoped for delivery.
Business stakeholders engage sooner, learning which aspects of the solution work well and which might have benefited from an alternate approach–offering not only informed feedback for refining the current solution, but a better educated perspective on how to define requirements for subsequent solutions. Such in-flight refinement and improvement is simply not possible when all requirements and designs are finalized in the relative vacuum of pre-development imagineering.
Developers receive business feedback sooner, learning early and often how technology is woven into the fabric of this particular organization. Business technology exists to serve the needs of an organization that operates in an analog world. When the tail wags the dog, and project success is defined exclusively by whether or not delivered code aligns with a design document signed by a marketing manager fourteen months ago (whether or not the finished solution delivers the business improvement Marketing had hoped it would), then the work of development becomes less meaningful or motivating, and results suffer.
Viable
Viability is the element of MVP that reconciles the sometimes competing desires to create product value on the one hand, and to minimize effort, cost, and time on the other. In its simplest sense, a product is “viable” when it meets a customer’s need to do, get, or learn something, without relying on a feature or function not yet developed. The product as a whole stands on its own, delivering value even in the absence of features not yet developed. The challenge for the business analyst and architect in defining a minimally viable product is to identify the point at which a collection of features is viable, but removing anything from that collection would leave the entire solution no longer viable. This is a point of equilibrium that can be reached from either a top-down or bottom-up approach.
From the bottom up
The business analyst and architect evaluate proposed solution A. Either may challenge the proposal, saying, “That is not a product, because it’s not viable. In order for that to be viable it must have Feature B. Feature B is critical to having the solution work at all.” The question of viability may be either technical (the solution will break) or functional (the solution has no business value). In this case, feature B is added, and the solution is now viable. There may be other features that would be nice to have, but because the solution is now viable, they are not part of the MVP.
Might there be time and budget to add desirable, closely related features? Yes, and often companies choose to build toward a “more-than viable product” solution. However, this introduces two common risks. First, recall that one of the key benefits of rapid delivery is that lessons learned from one product implementation are used to improve the design and development of the next. That nice-to-have feature that we are choosing to add onto the MVP of today’s project might have benefited by the lessons we haven’t yet learned. The other risk associated with exceeding MVP is common experience of a more-than viable product rapidly evolving into a well, while we’re at it product, before sliding into a wait, who asked for that product?
From the top down
Working toward MVP from the top-down presents a similar process in reverse. Business stakeholders request a large-scale solution. If implemented as planned, the entire solution will constitute a viable product. On down side, there is nothing minimal about it. The proposal is to implement the entire solution in a single release, nothing will be delivered until everything is complete, and the effort may consume more than a year.
The Business Analyst and Architect work their way through every feature and function of the proposed solution, asking two simple questions:
Does this feature address the most critical issue concerning the business right now?
If we remove this feature, is the solution still viable (technically and functionally)?
Any feature that is neither critical as a business priority nor essential for viability is removed from scope. At this point, the project is made up entirely of features that are either directly relevant to the stated focus of the project or necessary for solution viability (or both).
Conclusion
Sometimes, less really is more. The benefits of establishing and practicing a disciplined minimum viable product approach to development are numerous:
Efforts are consistently directed at the most critical concerns confronting the company, and little or no investment is misdirected to non-critical issues.
Product delivery timelines are kept as brief as possible, fulfilling stakeholder expectations more predictably and building credibility, while ensuring that stakeholder ownership and adoption are maximized.
With rapid delivery timelines, the same critical issues that precipitate the start of a project remain problematic until the product is delivered, so the solution adds value when it is needed most.
Smaller projects demand smaller budgetary and staffing commitments. This, along with more rapidly realized returns on investment and a focus on issues of most critical current concern, tends to streamline project approval and startup.
With so much to recommend it, one wonders why the rapid development and delivery of minimum viable product solutions remains more the exception than the rule in so many organizations. The truth is that most companies operate under long-standing organizational structures and behaviors, which raise barriers to a lean development methodology. Rather than question the legitimacy of these obstacles, practitioners need to demonstrate an understanding of these organizational barriers to formulate a compelling argument for change. Even apart from institutional roadblocks, support for a rapid development methodology requires the availability of certain prerequisites. These are topics that merit greater attention, and both will be the subject of further exploration in a later post.