POCs in this glittering world of MVPs

Only Engineering does POCs today…

Whenever it’s time to venture into the unexplored, Engineering teams promptly put on their gears and dive head-first into POCs(Proof of Concept) to test the uncharted waters.

And that is indeed an effective strategy.

POCs help us uncover potential complications with minimal investments. Their findings empower us to take pragmatic, data-driven decisions about whether to move forward in a direction or not.

But Product Teams tend to replace POCs with MVPs.

Whether it is a new feature or an entirely new Product, Product Teams readily pick up their markers and begin scribbling out MVPs (Minimal Viable Products) on their whiteboards.

Is it wrong to replace POCs with MVPs?

Every Product is built upon a ‘Concept’

• Facebook is based on the concept that “people like connecting to friends and family online”.

• Netflix is built on the concept that “people love bingeing on good, quality content”.

• Amazon is based on the concept that “people like to buy things online without having to go to a physical store”.

Every Product Feature is also based on a ‘Concept’

• Facebook Pages is built on the concept that “Businesses and Individuals would love to host independent pages where they can post niche content and build a following”.

• Netflix Watchlist is based on the concept that “People will be more invested in the platform if they can bookmark content they will like to watch next”.

• Amazon Customer Reviews is based on the concept that “People would love to give reviews of the products they bought. This will not only help other buyers in their buying decision, but it will also help Amazon boost the rankings of well-performing products thereby driving more quality sales.”

As the market matures, so does this underlying ‘Concept’

• Any new Social Networking Product being built today, will not be based on the same concept as Facebook — because that is already proven. It will now be based on the concept that “Facebook is not good enough”.

• Similarly, a new Content Streaming Platform will be based on the concept that “Netflix is not enough. There is a market for a different streaming platform”.

• And so on…

POCs are meant to validate these ‘Concepts’ with the most minimal investments

The goal of a POC — Proof Of Concept, is to provide proof that “this concept works”.

The best part of a POC is that it can be very narrow, scrappy, and pinpointed on a very narrow segment. This makes it easy to keep the overall time, effort, and monetary investments very low.

An MVP on the other hand is the most ‘minimal form’ of your end Product. But a Product, nevertheless.

The goal of an MVP — Minimum Viable Product, is to get the first set of customers.

An MVP is a fine balance between two important factors viz. minimum-ness and viable-ness of your product.

• Minimum-ness means we try to keep the scope of the MVP very tight. The goal is to keep our overall investment as low as possible.

• Viable-ness means we ensure the MVP has all the must-have functionalities of the end product.

Thus, if our end product is a Cake, then our MVP is a cupcake.

• Minimum-ness ensures that we do not end up making an entire cake with just a lesser amount of icing and decoration.

• Viable-ness ensures that we do not build just a raw piece of cake with no icing and decoration.

Thus by nature, MVPs are more expensive than POCs.

Since an MVP is a Product, it cannot be as rough around the edges as POCs can afford to be. MVPs are thus naturally more expensive(in time, effort, and money) than POCs.

In the absence of a POC, an MVP becomes an expensive POC which then struggles to maintain its balance between minimum-ness and viable-ness

Since there is no POC, the responsibility of proving the validity of the ‘Concept’ falls on the MVP. But now, the struggle is real:

• The investment feels heavy since the ‘Concept’ has not been proven

• But at the same time, the MVP needs to be viable

When such MVPs fail, it is hard to diagnose the actual reason

• Did the MVP fail because the ‘Concept’ was not valid?

• Or, did it fail because the MVP itself was not good enough?

The POC should thus come before the MVP

Therefore, if we skip the POC to dive straight into the MVP, we are missing a vital step here.

What does a good POC look like?

As we saw, the only goal of a POC is to provide proof that “this concept works” and deduce this proof with the most minimal amount of investment possible. As long as a POC can satisfy this equation, it is a good POC.

Let’s now take a look at the different forms of a POC.

Research

Sometimes, good research is enough to serve as the POC. This is even more prominent for Product features. Good research includes:

• Qualitative data (one-on-one interviews, focus groups, case studies, etc.)

• Supported by, Quantitative data (surveys, polls, questionnaires)

Rand Fishkin, Founder of SparkToro — An Audience Research Tool, wanted to gauge demand for his Product even before launching it. He figured the best way to do this is by better understanding his Target Audience.

“When you’re an early-stage startup founder, your job is clear: find product-market fit.” — Rand Fishkin, Founder of SparkToro

Rand used a TypeForm to build a simple survey that his audience would fill out on his Beta-signup page. This idea validation survey has allowed Rand and his team to quickly get to the core of what their product should be — what features to focus on and the areas where people were struggling.

Video PrototypeHere a launch-like video demonstrating the end product is posted online. Do note, the actual product building has not even started by this point. The primary idea is to demonstrate the problem end consumers face today and how the product will solve it.

The end goal is to see how people react to this video. Do they seem excited? Are they willing to signup for the beta program? Or does the response seem lukewarm and okayish?

Video prototyping is a great way to understand the demand for our product and get a better understanding of the end consumers before even building the product.

Back in 2008, Drew Houston (founder of DropBox), and his team wanted to quickly confirm the underlying concept of DropBox — “File synchronization across devices is a real problem, and if a solution can provide a seamless experience for solving this problem, people will flock to it”

But because of the technical challenges involved, building and demoing an actual working product was almost impossible without significant investments.

So Drew and his team used a “Video Prototype”. They put together a simple 3-minute video of how the product would work and released it on YouTube. The response was amazing. In Drew’s own words —

“It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away. — Drew Houston, Founder of DropBox”

You can read more about it and even watch the original video here.

Working PrototypeThere are times when Research or Video Prototypes are not enough. This is when the need arises to get the Product in front of actual customers and see how they react. A “Working Prototype” is what is needed in such cases.

A Working Prototype is the most minimal working model of the final Product. Such POCs employ the “Wizard of Oz” technique. For example having actual humans simulating a Chatbot, simply to validate the ‘Concept’ — “Our consumers will be satisfied if their queries are resolved promptly by a Chatbot”

Zappos has set an excellent example of using a Working Prototype to validate the Product’s underlying ‘Concept’.

In 1999, Nick Swinmurn with his Co-founder and investor Tony Hsieh wanted to quickly validate the underlying concept of their online shoe store — “People will be willing to buy shoes online”. But back in 1999, setting up an online shoe store was not only an expensive idea, but it was also an unproven one.

So Nick and Tony set up a “Working Prototype” in the form of a website called Shoesite.com. Nick would go down to local shoe stores, take pictures of the shoes and then post them online on Shoeshite.com. When a customer would end up buying those shoes from their website, Nick would actually go back to these local stores, buy those shoes and then ship them off to the customer. In his interview on “How I built this with Guy Raz”, Tony Hsieh spoke about this model in length,

“We were obviously not making any money from each of those sales, but it was a really cheap and easy way to test the actual demand and learn whether users would buy shoes online or not.” — Tony Hsieh, Co-founder and CEO of Zappos

Once their ‘Concept’ was proven, Nick and Tony renamed Shoeshite.com to Zappos.com, and the rest as we know is history.

You don’t have to stick to a single form of POC

Feel free to mix them up and experiment.You can use “Research + a Video Prototype” to validate your concept or maybe even use all three, “Research + a Video Prototype + a Working Prototype”.

You can be as creative as you want with them

A highly recommended book for getting creative ideas for POCs is — Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp

In this book, author Jake Knapp puts together a 5-day framework on how to quickly test the underlying ‘Concept’ of our products. He also gives us a detailed account of how different Startups have used this framework to put together creative POCs quickly and cheaply.

POCs and MVPs do seem interchangeable, but they are NOT

It is natural and understandable to think that POCs and MVPs are the same. But remember the points we discussed earlier:

• The goal of a POC — Proof Of Concept, is to provide proof that “this concept works.

• The goal of an MVP — Minimum Viable Product, is to get the first set of customers while maintaining the balance between “minimum-ness” and “viable-ness”.

• If we are struggling to maintain the balance between the “minimum-ness” and “viable-ness” of our MVP, then we know we need a POC.

Conclusion

Today Product Teams have romanticized MVPs, and have strayed away from POCs.

But POCs and MVPs are not the same. They are in fact independent steps of the Product’s life cycle. Their goals are different and thus if we happen to skip one for the other, then we are actually skipping an important step in the path toward building a great product.

“Don’t jump any steps, because it is difficult to start again”

This Blog was originally published here.