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:

• Contracting
• Vendors
• Users

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.

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.