How to run a Proof of Concept Project

Because you don’t just jump into the fire with both feet…
New product development are really risky projects to undertake and before you pump money and time into a project, how can you be sure it will deliver on its mandate? You don’t want to sink your company’s funds into an investment that will quickly run out of steam, or one that barely has any legs to stand on from the word go.

Understanding Proof of Concept

A proof of concept (POC) project allows you to mitigate risks and test new systems or technologies before you give them the green light and go all in. Pacing the development process before you fully invest in it enables you to address critical issues that would have caused the project to fail later on, and avoid the losses that would have resulted. Project teams need to show their investors and clients the practicality of the product, its usefulness and commercial viability for them to buy into it. This is done through a POC process, where business ideas are developed into small-scale visualisations to show their feasibility and real-life application.

Proof of concept vs. Prototype

The terms Proof of concept & Prototype are often used interchangeably, However they are definitely not the the samething. They essentially answer two different questions and the subtlety in the definitions is very important to understand:
A term related to discovering should a product be developed.
A POC is required to get stakeholders to approve the idea for the product. The Product team tests out the concept. Often this is referred to as Product Discovery 
A term related to discovering How a product can be developed
A prototype is a physical presentation of the product’s basic functions – a miniature version of its final form, bringing the idea to life through a working model of the product.
In book, Inspired : How to create tech products customers love, Marty Cagan provides an excellent easy to understand breakdown of these two concepts. We really recommend that any members of new aspiring technical  product teams read this book before engaging on their journey to developing products.
Cagan emphasises that their are four critial questions that POC or Product Discovery should answer:
  • Will the user buy this product or choose to use the product?
  • Can the user figure out how to use the product>
  • Can our engineers build the product?
  • Can our stakeholders support the product?
The primary purpose of Product Discovery is to quickly separate the good ideas from the bad!

In INSPIRED, technology product management thought leader Marty Cagan provides readers with a master class in how to structure and staff a vibrant and successful product organization, and how to discover and deliver technology products that your customers will love

Steps of a Proof of Concept Project

The fundamental questions this step tries to answer are:
  • Why is the product needed?
  • Is there a gap in the market?
The focus here is accurately determining the target audience and which of their problems are being addressed. Note that these are not just assumptions that can be made from the head office. The team involved needs actual answers from the end users. For instance, the company can run a survey where customers detail their pain-points, how they would like a product to be improved, and their perspective on what would be their ideal user experience. Online market research tools like Survey Monkey and Recollective come in handy here.
With the feedback from the customers using the product, the project team then comes together to brainstorm on the solutions that will address the issues raised.
Each solution is then looked at on its own merit, from the costs that it will likely be incurred, whether it is in line with the company’s policies, the technology and other resources needed to actualise it, all through to what the competition already has in place. The project team narrows down this list to the most suitable options.
Take this list of solutions and go back to the individuals you had initially interviewed in the survey. Describe the solutions and how you picture the product working, and take note of their responses. This feedback will give you more insight that will be beneficial moving forward.
Be open to random ideas at the initial stage. They don’t have to be perfect. You can then sift through them as you weigh the different options that have been raised. Some of those half-baked ideas may even be beneficial in adding to the final decision.
After settling on the most feasible idea, a prototype can then be created. The prototype should have a functional UI/UX and the expected set of features.
Members of the POC team can test out the prototype to see whether the solution addresses the problems that had been raised when initially surveying the customers. Document the feedback from the team members.
Take care not to get stuck in this stage, trying to make the perfect prototype. The goal here is to have a working version of the final product, which features solutions addressing the bulk of the issues raised – but not a perfect prototype that will go right to mass production. Sure, the better you can make it, the more feedback you can get for it – just don’t take too long such that it grinds the POC project to a halt.
The focus here is testing out the prototype on a sample size of the final users. The important questions we ideally would like to answer at this stage are:
  • How is the experience of the interviewees when they interact with the product, and what are their reactions?
  • How is the user interface?
Using your loyal customer audience during the proof of concept process is key. The key point to remember here is 35% of companies view customers as being their most important innovation partners.
Go through the feedback they provide, which will be key in verifying the feasibility of the product. Their feedback also provides pointers to improvements that need to be added to the proposed product. Cloud-based platforms can be used here for better collaboration amongst the sample group.

Working with an MVP

Erc Ries, in his book, The Lean StartUp : How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, captures why it is important important to have a Minimum Viable Product (MVP), not only from a StartUp perspective but also from any mature companies perspective, especially when it comes to developing new products.
Once the product team is clear on the Leap-of-faith assumptions, they will need to enter the Build phase as quickly as possible with a MVP. The MVP is a version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.
The MVP product lacks many features that may prove essential later on. The important aspect here is the ability to measure the impact of the product.
If time and budget allow, you can create a Minimum Viable Product (MVP). This is a step further than the prototype, since it is a fully functional solution that can be released to the end users. While it just includes the critical features needed to solve the identified problems, on the user’s end it should still work like the final product. This way, you can expand your test group beyond the few sample interviewees, to a larger audience in your target niche – getting more feedback in the process.
However, remember that the primary goal of the POC is to convince the stakeholders, like project managers and investors whether the idea is worth implementing. The MVP is a tested version launched into the market that can be taken to full-scale production. As such, it is advisable to only add an MVP to the POC project if resources permit it.
Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched.
Compare the POC with the current performance baselines. For instance, if you’re working on a product that is meant to double your package delivery timelines, you’ll need to know the present performance and use it as a benchmark.
After testing the concept and adding improvements based on the feedback that had been provided, a presentation that will be made to the stakeholders can now be prepared.
The critical components your presentation should include:

Conclusion

If the POC presentation is successful, the stakeholders will approve it – at which stage the project can now start to be implemented. With management on board, you can go ahead to plan the project’s implementation and move it from the list of “concepts” to “active projects”.
Not every POC will succeed. However, since you won’t have committed many resources except for the prototype testing, it reduces the hit to your bottom line. In fact, one of the benefits of POC projects is that they enable you to avoid bleeding out your budget on products that don’t solve your problems, deliver on customer needs or those that are packed with bugs. You can walk away before saddling your organisation with solutions that don’t work. For the POCs that fail, a “post mortem” can be conducted to determine where things went wrong, and a summary of this presented to management. You can now close the POC project.