Develop a first MVP ASAP!
The smallest possible product that is valuable, usable, and feasible.
An MVP is a production-quality item (i.e. a Viable Product) with a constrained feature set (Minimum). This distinguishes it from a prototype, which is typically not a salable product. The purpose of an MVP is to produce “validated learning” about how well the product aligns with user needs.
MVP’s are a key component of the first step in a Build-Measure-Learn cycle, and can help shape subsequent iterations of the product. An MVP performs a subset of the functions planned for the final system. This means features which are “useful but not essential” are not included in the MVP. The graphic below is often used to illustrate the MVP approach.
Why Use An MVP?
- Delivers capabilities to the users quickly
- Accelerates learning
- Enables iteration based on user behavior and feedback
- Restrain system complexity, avoid over-engineered solutions.
- Demonstrate and measure value accurately; rapidly iterate deliveries
- Involve non-traditional vendors
Attributes of an MVP
- Developed quickly
- Provides capability to user
MVP in Acquisition
Doing an MVP in an acquisition program looks a bit different than in the commercial world, and requires a few additional considerations.
For starters, in the commercial world, MVP’s are produced by developers, not requested by customers. These developers (typically small start-ups) can directly design, build, and field MVP’s, providing them to customers to test a hypothesis about a product’s value or a user’s behavior. The developer then uses that feedback to shape the product’s next version.
A government program office, in contrast, is essentially a customer, not a developer. Since program office personnel are typically not involved in writing code or bending metal, they may not be able to produce an MVP directly. Instead, they must request an MVP from a vendor. This requires them to collaborate with three different groups not typically mentioned in MVP development playbooks and guides:
Each of these groups has their own procedures, preferences, roles, and limitations.
From a contracting perspective, the Program Office must introduce contractual language requesting vendors provide MVP’s. One of the main challenges of this approach is that vendors and contracting officers are accustomed to formally defined product requirements early in the process. An MVP scenario has a higher level of design ambiguity in the early phase of the process.
An MVP approach turns the requirements validation activity from a paperwork-focused exercise into a product-focused exercise. It produces data from users interacting with products, and the data is immediately made available to vendors to develop subsequent product iterations. The focus is on experimental exploration and requirement discovery / validation through user interactions, rather than on pre-defined performance requirements. This results in a higher level of design fidelity to user needs and provides operational value sooner.
From a schedule perspective, the proposed development timeline must establish a cadence for iterative fielding with user engagements to gain more information about user behavior and needs. These engagements should lead to redesigned products. This is a distinctly different approach than the single-step-to-capability or IOC / FOC approach commonly found in defense acquisition programs.
When pursuing an MVP approach, the source selection must focus on assessing the vendor’s capability to quickly deliver an MVP and iterate through subsequent designs, rather than on a proposed solution’s final design. In other words, the bidders must demonstrate flexibility and responsiveness rather than proposing a locked-in design. Bidders can demonstrate this ability to adapt based on past experience with design and an organizational commitment to MVP practices (such as Lean Startup, etc).
For this strategy to be effective, the Program Office must arrange for users and vendors to spend time together in realistic conditions so users can provide direct feedback to vendors about the system’s functions and capabilities. When making these arrangements, the Program Office must shape user expectations about the product to be evaluated (i.e. it will be minimum and iterative) and establish solid arrangements for users to be available. It may be necessary to explain the MVP concept and the benefits it conveys to users. It is important to keep the time demands on users low, but it is also important to emphasize the long-term benefits.
Section 809 Panel on MVPs
The Section 809 Panel in their Volume III report (Part 1, page 94) recommended DoD:
Maximize Use of Prototyping, Experimentation, and Minimum Viable Products.
Execution portfolios should maximize use of prototyping, experimentation, demonstrations, and minimum viable products (MVPs) independent of specific programs as well as in the early stages of a given program’s acquisition lifecycle. Congress and DoD, over the last few years, established a series of initiatives, funds, organizations, and pathways to increase use of these practices. DoD has begun implementing middle-tier acquisition via rapid acquisition and rapid fielding pathways per Section 804 of the FY 2016 NDAA. These pathways can prototype innovative technologies, demonstrate them in an operational environment, and produce mature capabilities without having to go through JCIDS and DoDD 5000 acquisition processes. A prototype or MVP in the hands of operators and engineers would accelerate learning and design of solutions beyond a team conducting a CBA or AoA. Portfolios should use the multiple prototyping pathways to the maximum extent before establishing a formal program or follow-on increment to shape scope and requirements. Iterative prototypes and MVPs would improve opportunities to exploit leading technologies and the chances of delivering high-value capabilities to warfighters. Prototypes provide valuable inputs to mission engineering efforts by demonstrating how strengthening individual elements of a mission thread generate holistic impact.
Moving forward on an MVP strategy involves asking and answering a series of questions.
- What is the hypothesis for the program?
- How would the users respond if 75% of the requirements were removed?
- What would you remove from the design if you had to ship tomorrow?
- How do you know which features are most necessary?
- What is your process for learning this?
- If users could vote on the design, would they ask for it to be more complex or less?
- Who are you building the program for? (be as specific as possible)
- How quickly can users be available to interact with the initial MVP?
- What contractual language needs to be incorporated into the RFP?
- Within the current schedule, how soon can an MVP be provided to users?
- How comfortable is the contracting officer with introducing MVP language into the contract?
An Industry Day is an ideal opportunity to begin talking about MVP’s with vendors.
There may be reluctance to allow users and vendors direct contact, based on a fear that users comments could be taken as contractual guidance. Establishing a few ground rules up front and including Contracting Officers in the discussions can go a long way to address this concern.
Fortunately, there is a growing body of policy and precedent that supports this approach. The FAR 15.306(d)(4) provides helpful policy guidance that is relevant to MVP discussions. It states the government should:
“…suggest to offerors that… their proposals would be more competitive if the excesses were removed.”
This clause shows that federal acquisition regulations are compatible with minimalist designs and with government personnel providing direct feedback to bidders, encouraging them to simplify their proposals in order to be more competitive.
There may also be concern about users’ availability or putting excessive demands on users’ time. Clear expectations and limits should therefore be established up front.
It is important for all involved to recognize that an MVP may reveal erroneous assumptions or flaws in the initial plan, necessitating a “pivot” in the plan. This is a sign that the MVP approach is working. As Eric Ries explained in his Leaders Guide, “We start by accepting that we don’t know what’s going to work in the future.” Ries goes on to say “…we should be very glad to be proven wrong.”
Ultimately, the MVP approach is a risk reduction strategy, not a high-risk proposition. It quickly provides validated user feedback to developers and shortens the delay to fielding capabilities. The simpler systems and architectures are less fragile and more closely aligned with operational needs. This reduces both the likelihood and the consequence of failure.
5 Common Traits of a Successful MVP
1. Built for one person
The most successful MVPs have their audience narrowed down to one person. Can you be that specific in identifying who your target audience would be for the product? What is your buyer persona? Picture that one person in mind who your ideal customer is and design the MVP to solve that one person’s needs. The moment you build for many different audiences, you’re defeating the purpose of a minimum viable product. If you haven’t nailed your niche, your target audience, you’ll end up spending tons or money in marketing and not getting any returns and relevant feedback about your product.
2. Listen to many people
While building your MVP keeping in mind that one person, it doesn’t mean you get feedback from just that one person. Oftentimes, even getting to the ideal customer profile is a process of discovery. Your MVP is only a starting point and not the destination. Collect feedback from many people that fit that ideal customer profile. The idea of building an MVP is to validate the product concept, so stay focused on that until you get answers for your next move.
3. Little focus on doing less
MVP isn’t about building less and less. It’s about building the right amount of features that showcase the core value proposition of your product. Your set of features will also depend on the type of product you’re building and its competitive landscape. If you’re building a completely unique product in a new market, that’s your opportunity to build just that little, which gives you market validation. For instance, if your idea is an app to provide home delivery of food from restaurants in a market that doesn’t have this at all, you could do with just a landing page and a phone number to validate whether people want to have their food delivered home in the first place. Once you get sufficient validation, you can start automating the various parts of the app. But if you were to launch the same app in a market that already has many such apps existing, your first version of the product would look more complex.
4. Focus on testing
You build a minimum viable product to test your hypothesis with the least amount of time and effort spent on product development. And so, with that, go out and test the market for just that. Don’t seek to make money right off the bat with your MVP. Don’t seek profitability. Seek to get validation or valuable feedback to help you build a version that can scale to become a big business. I don’t mean to say not to charge for your MVP. By all means, do charge if there’s value enough, but don’t focus on making money. That’s not what your objective of building an MVP is.
5. Small, contained launch
The launch of an MVP is not the same as launching your product. The objective of an MVP is different from that of a product launch. You launch a product when you’ve confirmed the demand for it. You build an MVP when all you have is an idea that people will buy your product. You can expect to make many mistakes as you iterate on the first few versions. Make those mistakes with as few people, to get the product up to a point where you find greater conversions, engagement and retention. It’s easier to scale from an MVP which has all those three.
Actions You Can Take
- Assess Feasibility of MVP from Scope and Requirements
- A program in the early stages where requirements haven’t been locked down in a major requirements document yet is ideal.
- If a requirements document is complete, is there a divisible subsection that could be delivered to users early. Depending on constraints this may need to be as a prototype vice a certified operational system.
- If not, assess the feasibility to change the requirements document with the approval authorities to deliver one or more MVPs.
- Assess Contracting Conditions
- If not on contract yet, the contract strategy can integrate MVP deliveries and feedback mechanisms. If on contract, examine feasibility, trade-offs, and incentives of a contract modification to enable MVPs.
- Identify contractual language to include in future RFPs.
- Work with users to identify the core priority features to demonstrate value and learning. Identify users who are willing to be early adopters of a new product or service. Take early prototypes to them.
- Work with engineers and vendors to scope out a MVP to include more readily available materials, prototypes, and software.
- Work with testers and certifiers to streamline processes, tailor strategies, and align resources for user acceptance tests of MVP(s).
- A Minimum Viable Product Is Not a Product, It’s a Process, Jim Brikman, YCombinator
- A Minimal Viable Product needs to actually be viable, Patrick Thornton
- The Lean Startup by Eric Reis
- The Lean Startup Principles by Eric Reis
- Minimum Viable Product, Marty Cagan
- 5 Common Traits of a Successful MVP, Rahul Varshneya
- Is this a prototype or an MVP? Well actually, it’s a proof of concept, George Krasadakis
- The Digital Services Playbook, published by the US Digital Service, contains more detailed information about this approach. Two sections from the Playbook are particularly relevant to this discussion:
- Play 4 (Build the service using agile and iterative practices)
- Play 5 (Structure budgets and contracts to support delivery)
- The TechFAR Handbook, also by USDS, is a similarly relevant resource the program office should become familiar with.
- Prototyping Guide, OUSD(R&E)/EC&P, Dec 2018