How the Americans Won the Space Race — MVP vs POC — Part VIII of Lessons from the Lunar Landings

In early 1965, halfway through Kennedy’s goal of reaching the Moon by the decade’s end, the Soviet Union seemed to have an insurmountable lead in the space race. The list of achievements they had made before the Americans was daunting:

• First human in space — 1961
• First human to spend 24 hours (and sleep) in space — 1961
• First dual-human mission (two manned spacecraft in orbit) — 1962
• First woman in space — 1963
• First spacecraft with a crew of three — 1964
• First space walk (leaving the spacecraft in orbit) — 1965

Their unmanned achievements were just as impressive:

• First satellite to orbit the Earth — 1957
• First animal in space (the dog Laika) — 1957
• First probe to reach the Moon (albeit a crash landing) — 1959
• First probe to photograph the far side of the Moon — 1959
• First probe to make a soft landing on the Moon — 1966
• First probe to orbit the Moon — 1966

But later in the decade the Americans had overtaken the Soviets, achieved many of their own “firsts” and in 1969 they landed on the Moon. Why had the Soviets not been able to take their initial achievements and keep their lead in the long term? What did the the Americans do differently which enabled them to achieve long term success and reach Kennedy’s goal before the Soviets did?

There are many reasons for their success, one of which was certainly the clear goal they were working towards compared to the less focused Soviet plans. However, another major reason — and the subject of this article — involves two different approaches which are used in modern application development too.

A “Minimum Viable Product”(from here on an MVP) is the

smallest possible version of a product that can be used to run a meaningful experiment to test key hypotheses and determine whether to continue investment.
- Get started with Enterprise Design Thinking

MVP design flow (IBM)

Another way of stating this is that an MVP is

the least amount of design, development, and infrastructure that is needed to prove that your proposed solution meets the users’ needs.
- IBM Enterprise Design Thinking

on the other hand, a “Proof of Concept” (from here on a PoC) is

evidence, typically derived from an experiment or pilot project, which demonstrates that a design concept, business proposal, etc., is feasible.
- lexico.com (Oxford University Press)

Note that a key difference between an MVP and a PoC is that the MVP answers a question (or a hypothesis) for which the answer has real value (either as an investment or meeting user’s needs) while the PoC answers a question to which the answer is a technical yes/no, without regard of how useful the solution really is.

If we examine the spacecraft the Americans and Soviets used for their initial forays into space — the Soviet Vostok and American Mercury, we can see that they were both designed to be similar MVPs. They both set out to prove that:

Vostok — the highly successful Soviet 1st generation spacecraft (Wikipedia)

• Man can survive in space.
• Man can remain for a meaningful period in space (the longest flights were long enough for full eating and sleeping cycles).
• Man can work in space (cognitive facilities are not harmed by micro-gravity/weightlessness).
• Ground control can support spaceflight, perform the necessary calculations and manage emergencies in space.
• In the case of the Soviets, they also proved that they could manage two flights simultaneously (launching two rockets and controlling two spacecraft in parallel requires much more coordination than doing so twice, but one after the other) and that women could function in space as men could.

In 1961 both superpowers developed one MVP spacecraft and, by 1963, performed a number of tests which successfully proved 5–7 hypotheses which they had set for themselves.

At this stage they each developed their 2nd generation spacecraft (the American Gemini and Soviet Voskhod) with which to continue their space efforts.

2nd generation Gemini (on the right) and 1st generation Mercury (NASA)

In broad strokes, the goal of Gemini was to prove that all the individual tasks required to land on the Moon could be achieved. Lessons from Gemini would be used to develop the even more capable 3rd generation spacecraft — Apollo.

• The spacecraft must be able to maneuver in space — change orbit, link up with other spacecraft.
• The spacecraft must be able to survive in space for two weeks without hardware and computer failures.
• Ground control must be able to manage and operate multiple spacecraft simultaneously, working in shifts for up to two weeks.
• Astronauts must be able to survive for up to two weeks in space.
• Astronauts must be able to make a “space walk” by leaving the Gemini capsule and performing meaningful work whilst floating in space.

Ed White, spacewalk outside Gemini IV in 1965 (NASA)

Apollo astronauts would be required to spend nearly two weeks in space while maneuvering their spacecraft, linking them up and moving from one to another on the way to the lunar landing. While none of the Gemini missions did all of these tasks, each of the missions between 1964 and 1967 gradually proved that these milestones were possible.

Gemini IV was a short 5 hour mission to prove that the systems worked. Afterward Geminis V and VII stayed in space for nearly 8 and 14 days respectively — proving that humans, spacecraft and ground control could manage flights as long as a Moon mission would be.

“Space walks” were a more complex challenge and while the first American spacewalk was during Gemini V, only by the very last mission, Gemini XII, did the Americans consider that they had proven the hypothesis that they could do meaningful work while floating outside the spacecraft.

While Gemini was a completely new spacecraft, built from the ground up to prove new MVPs, the Soviet Voskhod was not a true 2nd generation spacecraft. Voskhod was simply Vostok with a few features added to it!

Cutaway diagrams showing the similarity of Vostok and Voskhod (basically changing seating arrangement and adding an exit “tube” for Voskhod 2) (NASA)

• Prove that a spacecraft could carry multiple Soviet cosmonauts? Add more seats and have the cosmonauts fly without bulky spacesuits so that they can all fit (The Americans made a larger spacecraft).
• Prove that a man can leave the spacecraft for a spacewalk? Change the existing hatch and add an inflatable airlock tunnel for the cosmonaut to wriggle through (The Americans changed the hatches completely to allow for spacewalks).

In short, while the Americans used 10 Gemini missions to prove all their MVP hypotheses, the Soviets used only two Voshkhod flights for each to demonstrate one PoC. The Americans advanced naturally from the 2nd generation Gemini to the 3rd generation Apollo spacecraft while the Soviets had to work that much harder to go from the 1st-and-a-bit generation Voskhod to the 3rd generation Soyuz spacecraft and simply could no longer keep up.

When thinking about adopting these lessons to Cloud Service Management & Operations and modern development we can consider the following:

If we want to create a manageable application which follows Build-to-Manage and Observability concepts, we would like the application to expose metrics which will help during troubleshooting. Our hypothesis is: we can expose metrics that will help us troubleshoot the application.

• A PoC would merely demonstrate that we can add the few lines of code which expose metrics.
• A proper MVP would involve deciding which metrics are important for troubleshooting (which are the Golden Signals for example) and making sure that they are handled correctly.

The PoC does not demonstrate that we know what we need to do to create an observable application, only that the technical design is sound.

Another example might be of converting an existing application with multiple log formats (which makes support difficult) to conform to 12-factor apps and stream the logs to a collector and then to an aggregator (which simplifies support). Our hypothesis is: we can unify the log format and, thereby, simplify the way we support this application.

• A PoC would demonstrate that we can write a log in the correct format and view it in the log aggregator.
• A proper MVP would require converting all the existing log writes to the correct format and validating that they appear in the log aggregator.

By not converting all the logs, the only thing the PoC has done is create a new log standard. Only by unifying all the logs under the new, improved, standard can we get the benefit of the log streaming and aggregator.

The MVP might require more effort — both in design and implementation — than the the PoC. But the MVP gives us the certainty of a working solution that validates our hypotheses while the PoC leaves us with uncertainties as to whether we really know the right answer (perhaps we won’t find the right metrics? perhaps there are some logs that will be impossible to convert?).

There are cases where a PoC may be the right answer. Perhaps you only want a technical answer you can “bang out in an afternoon” or perhaps you need (for marketing reasons) to present a PoC as a full MVP.

But as the Soviets found out in 1969, a PoC will only take you so far while a proper MVP is a stepping stone towards success — whether it be for a business application or for landing on the Moon.

Start your New Year with a Resolution — this year I will perfect my MVPs and not be satisfied with PoCs!

While this may be the last lesson of 2019 or the first of 2020 that you read, I plan to continue writing more of these Lessons from the Lunar Landing, even after the 50th anniversary year. To be informed when the next article is published follow me on Medium at Robert Barron or on Twitter at @flyingbarron. And of course, please leave comments and questions below.

Articles in this series:

Bring your plan to the IBM Garage.
Are you ready to learn more about MVPs?
We’re here to help. Contact us today to schedule time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development and startup communities we work in, and the deep expertise and capabilities we bring to the table.

Schedule a no-charge visit with the IBM Garage.