POC Playbook

i.e How we try out new ideas before building products?

Overview

Proof of Concept (PoC) is a demonstration with the aim of verifying that an idea has practical potential. It is mostly used to determine the solution to some technical problem or to demonstrate that a given configuration can achieve a certain output within the defined constraints.

The goal of this playbook is to devise a process for effective building proof of concepts. For documentation, one can find a sample template here.

Steps to create a POC

  1. Clearly write down the functional aspects of the product on which one doesn’t have 100% implementation clarity. This may include all the major components which are envisaged to form the product
  2. List down potential approaches to solve for each of the functional aspects listed in pt. 1. Along with the potential approaches, one should also list down the following items for each approach:
    • Pros
    • Cons
    • Known unknowns (Things which the team does not know about but may be required or may be a cause for concern)
  3. Take feedback and inputs from the team at this stage. There is a possibility that people may suggest new ideas, strike off some functional aspect items from the list or merge a few things together which do not require a poc and can be implemented with past experience.
    There is also a possibility of some disagreements on the pros and cons assumed. Clearly mark them out beforehand.
  4. After deciding on the most viable approaches for problems, implement a POC(s) on the same. There can be multiple POCs, the decision for which should be taken on a case by case basis. Ideally, a POC should not take more than two days to build.
  5. List down the following for each POC and take inputs from the team:
    • Update the pros and cons of the approaches listed in pt.2 based on learnings from the POC
    • Decision to accept or reject the approach with reasoning. (The reasoning is very important to be noted for the current project as well as for future references)
    • Demo code/repo link, if any (Optional)
  6. In case of a failure for any of the POC or the rejection of an approach, one may repeat the process from pt. 2. This recursive approach should ultimately lead to a viable solution.

Additional notes

Learning from past experience, documentation is of utmost importance in this process. This helps in the whole team being on the same page and updated throughout the POC building process.

Back to Playbooks