Proof Of Concept V Minimal Viable Product

05/10/2016

The debate goes on…Proof of Concept vs. Prototype vs. Minimal Viable Product.

Debate was raging in the Cucumber camp last week. We were in the midst of putting together a proof of concept for a client, when we started exploring integrating into real life data to prove the concept was viable. By doing so a whole bunch of questions were raised around what a POC really was and were we crossing the great POC to MVP divide?

Proof of concepts (POC), prototypes and minimal viable products (MVP) are all common approaches in our world to test ideas and get useable, useful solutions to market quickly. But what do they really mean and when should we use each approach? Here are my thoughts:

Proof of Concept:

What: Used to determine IF a solution or a feature will work. By definition we are simply looking to prove this to be the case for the internal stakeholders in order to build it out properly within a project itself.

When: Generally, we use POCs at Cucumber when working with emerging technology, new integrations or a particularly complex technical area of a project that we want more certainty on before jumping into development. More often than not this is testing a subset of features rather than the full solution itself.

Considerations: These don’t have to be pretty and they don’t have to utilise real data. In essence this is throw away development rather than the first phase of a wider programme. As such everything that is done in a POC should be aimed at validation, not extensibility. The words quick and dirty come to mind.

Prototype:

What: We are big fans of prototypes in the Cucumber camp and use them extensively to show HOW something will work without going down the track of actually building it. A prototype is therefore a sample version of the current thinking of a solution used to elicit user feedback before building out the real life solution.

When: Generally, we create interactive prototypes (usually clickable wireframes) that walk through the user journey in order to quickly test the concept with real users. This enables user feedback to shape the solution that will go on to be built, without the costly development changes of a more waterfall approach. In my view – if prototyping was used more, as an industry we would design better solutions and save a whole bunch of dollars.

Considerations: One of the misconceptions of prototyping is that is should be done once to gauge user feedback before refining the real solution. However, I am definitely a member of the ‘test little and often’ school of thought and this technique should be used not just before a major build but following launch to continue to optimise.

Minimal Viable Product:

What: Typically, we use a prototype to inform our thinking of an MVP. An MVP (funnily enough) is the minimum set of functionality required to meet both the organisation's and the user’s goals for a solution.

When: Typically, an MVP is (and should) be more expensive than a POC as we are building the real deal that will need to evolve over time so in this case we are using real data and integrating systems together where required to meet the minimum needs of our users.

Considerations: The obvious benefit here is reducing wastage in building out functionality that users do not need or want. When we do an MVP however we are building the actual end product, rather than a throw-away or test solution so we do consider the bigger picture before scaling this down to the bare minimum feature set. By ensuring we only build the MVP, we allow real user interaction to guide future enhancements rather than hunches or ‘the team with the loudest voice’.

So I know what you’re thinking, what was the conclusion of the great Cucumber debate? In short we were all right. My common recommendation would be to start with a prototype to test the validity of the solution and refine based on user feedback. Then take that informed view into a MVP which may also have a series of POCs within the project to test certain functionality or integrations before building.

Written by Clare Swallow