ProtoTyping, Proof of Concept & MVP Services

We’re all visual creatures. Cyclosys can assist in the rapid development of an MVP (minimum viable product) prototype.

Why developing a POC or an MVP before developing the final, complete product makes sense

Since the time when software development first came into being, there has always been a debate over which development methodology is best: Waterfall or Agile/Scrum. Some people still prefer Waterfall, some prefer Agile, and there are some others who feel that a blend of Waterfall and Agile commonly known as Hybrid Agile works best.

Despite all these disagreements about the various development methodologies, most people in the software development community are in a common agreement that the fastest and most economical way to develop a prototype or a product is to develop a Proof of Concept (POC) or a Minimum Viable Product (MVP).

What exactly is a Proof of Concept (POC)?

A proof of concept (POC) or a proof of principle, as per Wikipedia, is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential to be used. A proof of concept is usually small, and may or may not be complete.

In the context of software developmentand product development, a POC is how a development team or startup demonstrates whether the product is actually technically feasible or financially viable. They demonstrate this by developing a prototype of the software with minimal functionality, or by testing a product with a limited set of features.

For example, a startup could develop a POC with only core features to test whether their product will really be accepted by their target audience, or an enterprise could try developing only a part of a new, complex functionality that has never been tried before in their industry within their existing e-commerce application to see if it is technically feasible to develop a full version.

What exactly is an MVP (Minimum Viable Product)?

“A Minimum Viable Product, or MVP, is defined as the smallest possible experiment to test a specific hypothesis, all the way up to the tangible realization of a product vision.”

Unlike some other methods of collecting customer feedback, such as win-loss analysis, beta programs, and focus groups, the MVP approach does not negate the need for market research. You must understand what problems your market needs to solve. However, according to the MVP approach, you do not need to address every problem at once. Solve the most important and most basic problems first, and then gather feedback. The idea is to maximize your learning and minimize your development costs.

So, what really is the difference?

In contrast to traditional software development, which involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not to complete it. Unlike a prototype or concept test, an MVP is not just designed to answer product design or technical questions. Its goal is to test fundamental business hypotheses.

Why are they so essential?

There are many good reasons why you need to develop either a POC or an MVP.

These reasons could vary from purely technical to financial, or even just to test a hypothesis.  The idea is to build and launch something quickly and test it out in the market. If the concept is accepted, then build in more features and grow it, and if it is rejected by the market, then work on improving it further as per the feedback you received from the market, or drop the idea altogether. This is what Mark Zuckerberg, founder of Facebook,  insists on.

“Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.”

The following are some of the main reasons to develop a POC.

To Test Technical Feasibility

There are times when you want to develop a product, but are not sure about either the technical feasibility of the whole product, or of a particular module.

For example:

When ISAIX Technologies, a Canadian company, approached Net Solutions to build a mobile version of their flagship product Burst that needed to be optimized for all major smartphones and tablets (iOS, Android, and BlackBerry), they were not sure whether it would be possible to create the necessary pinch zoom functionality using HTML 5, or whether they should get a native mobile app developed.

As Maninder Bains, CTO of Net Solutions, recalls:

Since ISAIX Technologies wanted a solution which was cross-platform compatible, we were more inclined to recommend a solution that saved costs for ISAIX without compromising on the user experience.

So the idea behind developing a POC was to develop and test the functionality about which we were uncertain. We weren’t sure whether HTML 5 could provide technical feasibility to build pinch zoom functionality, which was critical to the user experience.

Once we developed the POC and were successful in implementing pinch zoom functionality, we knew that this product could be developed using HTML 5, which is a cross-platform solution, as its frontend technology, and we were sure that we could recommend building the whole product using HTML 5.

To Test Market Acceptance of the Product

Sometimes, you want to develop a product on a large scale, but you are not sure whether the market or the consumers you are planning to target will accept it or not. You aren’t sure whether the market is ready for your idea, or, even if it is ready, whether there are enough buyers to give you a return on your investment in your idea.

This is more relevant for startups who want to launch a brand-new concept that does not already exist in the market.

For example:

The team at Jaypore had a very clear idea that their product line, which is a collection of rare Indian art, had a market consisting of art lovers and art collectors in the United States. In other words, their product was originally not meant for the masses, but only for the classes. One of the premises behind their project was that this particular audience would use iPads for shopping, and so they decided to offer their products only via an iPad store, rather than a website which anyone could access.

When Net Solutions built a native iPad app for them using the Magento E-Commerce Solution as the backend to manage products, they realized that, using the same Magento backend, they could scale and reach out to more users (the masses as well as the classes) by creating a website in addition to the iPad app.

To Save Costs

Developing an MVP also helps considerably in saving costs. Developing a POC or a Prototype is one sure way to de-risk your investments and play the game with a small amount of money, rather than investing all your capital in one go and then discovering that there are no returns on the money you invested.

For example:

Front Rush, a US-based sports startup, had their entire web platform developed by Net Solutions, but in early 2009, they realized that mobile was going to be big, really big. That was when the Front Rush team decided to launch something on mobile. However, they didn’t want to invest immediately in developing native apps, since the smartphone mobile market was still in its early years.

With guidance from Net Solutions, Front Rush decided to develop a cross-browser mobile website for its users. The cross-browser capability of HTML 5 means they saved costs compared to the cost of developing separate native apps for each platform, i.e., iOS, Android, BlackBerry, and Windows Phone.

It turned out that Front Rush’s mobile website was a big hit and increased their signups considerably. This led them to conclude that mobile was a big game changer, after which they decided to develop native mobile apps for iOS, Android, BlackBerry, and Windows Phone.

To Explore Financial Viability

It is easy to build a product, but it is not as easy to find customers who are willing to pay for the use of that product. Therefore, the financial viability of the product becomes essential for it to sustain its profitability over the long term.

For example:

Truffledig, a startup from New York, worked with Net Solutions to develop an online gifting platform targeted towards customers visiting coffee shops and restaurants in New York City. We advised them to build a prototype first with limited features and test the prototype locally in New York to determine whether their concept would be accepted in the market, and whether it would be a financial success, before they tried to scale it.

The initial concept, named Truffle Dig, was based around launching a customized mobile page for deals offered by restaurants when a user scanned a QR code while sitting inside the restaurant. The idea was to buy gifts on the go using your smartphone. Once this concept was launched, they realized that the market needed something else, and modified their concept as per market feedback. Instead of a mobile website, they launched a web platform called Smartgift, which has been re-launched to capture market share in the online gift space.

To Win a Potential Customer

Developing a POC for a product sometimes becomes necessary when there is a need to impress your potential clients by showing them your capabilities, or when proposing a new concept to a client, something which he might not have thought of.

 

For example:

Xerox wanted to approach a large company that was active in the sea exploration space in the Northern Sea. They wanted to build a Proof of Concept iPad app for their client’s staff, which was an interactive map to help users locate different areas of the oil refinery.

The ultimate goal was to use the POC iPad app as part of a pitch for a bigger project.

This trend is being followed by many IT services companies as a way to make their clients aware of the capabilities of a particular technology and how it can benefit their business.

To Pitch to Investors for Funding

While all of the above reasons are important, another equally important reason for developing a POC is to develop an MVP (Minimum Viable Product) and show it to investors to get funding from venture capitalists.

For example:

Consider the case of Usherpoints, a social media stock exchange of Loyalty Points that allows you to find out and share your favorite stores among your friends. Usherpoints, when they approached Net Solutions, aimed to build the next BIG social commerce platform, and wanted to develop a full-blown concept. It was only when the Business Analysis team at Net Solutions discovered the scope of the project that the client was advised to build a POC first and show it to his investors. When the client was able to show the wireframes for the new platform to his investors, he was able to get funding from a large payment gateway provider.

Advantages of developing a POC or MVP

As it has become very clear to us, when engaging in a new project, it is imperative that the development of one or more POC or MVP systems be considered before one settles on the architecture and design of the final deliverable. Development of a POC or MVP system has provided us and our clients with many benefits, including, but not limited to:

• A clear understanding of the project’s requirements.
• The ability to maximize your learning dollars and minimize your development costs.
• The ability to release iterations (i.e., versions) quickly and to learn from your mistakes.
• The opportunity to build a core group of customer fans (also known as product evangelists) in the marketplace.
• An understanding of the capabilities and limitations of new technologies.
• A chance to assess design decisions early in the process.
• The ability for the customer to visualize the look-and-feel of the solution early on.
• Reduction in the overall risk of project failure.

Things to look out for while building a POC or MVP

Understand the Objectives

There are two ways to look at the objectives associated with any POC or MVP. The goals are to educate the customer and eliminate any objections to your solution that might block a sale. The customer needs to determine two things.

• First, your product has to prove that it can deliver the savings that your sales team promised.
• Second, you have to demonstrate that your product works in a manner that meets the customer’s operational guidelines.

Discover Unique Customer Challenges

Before creating a POC or MVP, you have probably given someone at the customer site a demonstration.  However, demonstrations are usually brief, and customers do not always fully understand your technology yet. Therefore, the idea behind building a POC or MVP is that, at this stage, you want to work with your customer to identify any misconceptions they may have about your solution, and any goals they need to accomplish that are outside of your standard proof of concept.

Break it up into small parts

One of the goals behind building a POC or MVP is to test how different variables impact its performance. You may find that there are lots of variables to test. If so, be careful about trying to combine them all in one breadboard. For more complex models, it can be a good idea to break them into separate builds that isolate complex systems from one another. Later on, you can combine them to more closely simulate the final product.

Build for test parameters

A POC or MVP doesn’t just let you test whether an idea works or not. A successfully-designed product allows you to find out what variables make the process work, and to what degree they influence the result. Design your system around the variables you believe will have the greatest impact on performance, and test. Run lots of experiments by tweaking different variables, and be prepared to adjust your model as you learn which variables do and don’t matter.

Build-Test-Iterate

If you follow the points above, you will discover that you will need to change or discard some of your initial work. Along the way, you will inevitably run into a scenario that you did not anticipate, or hit a snag that you had not thought through in advance. The solution? Be flexible, iterate, go back to the drawing board, and modify it and try again to find the answer. Every breadboard I have built needed some modifications after it was built. Being flexible and thinking creatively on your feet will keep you moving along.

Understand the Customer’s Environment

Once you build a POC or MVP, you need to demonstrate to the customer how you will use or replicate these components in your proof of concept. Get all the details you can. Do not assume they are using standard components. You need as much background information as you can obtain in order to ensure that you know how to work with these components before you go onsite.

Most people forget that the customer’s environment is more than software and servers. It is also people. POCs or MVPs are often created while working with technical and business teams in the company. But in order to build a usable product, you also need to work with non-technical and business teams in the company. You need to identify who you will need to work with and who needs to be present when you arrive onsite to install the proof of concept.

Cyclosys partners with you to build your Ideas. For a free quote, reach us at [email protected].