Using Proof of Concepts (POCs) To Develop New Software Products

A Proof of Concept (POC) is a small exercise to test the product idea or assumption. The main purpose of developing a POC is to demonstrate the functionality and to verify a certain concept or theory that can be achieved in development.

So what exactly are these POC projects and why should one care about them?

As a PM, you are expected to work on driving the product vision, performing user research, working closely with engineering, customers, and partners to bring products & features from inception to market, prepare Product Requirement Documents (PRDs), Product Roadmaps and what not! But sure enough you will also find yourself working on many POC assignments, trying to prove the feasibility of various concepts and ideas.

At first, It may not be clear as to why you are working on something which isn’t a product yet? why are you offering to conduct Research & Development on requirements and problems that only a few clients have? In essence it’s the other way round. At times, you are not offering your services to clients rather they are helping you to test your theories and capabilities by collaborating with you on these short POCs which later take the form of full-fledged Products — with clearly defined features, pricing, packages, etc.

“You don’t develop products and take them to the clients, rather clients come in with the requirements first and while finding the solutions to their problems, a new product comes into existence” — Yours truly

The development of almost all the software products starts with a concept or an idea for which we try to demonstrate operational feasibility to the internal stakeholders as well as the initial adopters (clients/consumers).

The focus here is not to deliver a complete product that is fully functional rather deliver a solution that is valuable but might require several POCs to fine-tune the features and transform it into a packaged product.

As you proceed in this journey of developing a new product along with a user base of early adopters, getting feedback on what works and what doesn’t, you get to know if the product actually holds some value and if the users are willing to adopt the solution.

This transition from feedback to iterations marks the beginning of your journey towards creating a product-market fit. Based on the feedback, you progressively work towards attaining the perfect product-market fit.

This article aims to demystify the entire process to give way for innovative products to get developed; products that customers want!

I am sharing below the steps to structure a POC such that it delivers value to both institutions — The makers (Company/Person developing it) as well as the beneficiaries (Customers/Clients who will use it).

When should a Proof of Concept be performed?
Scenarios include:

• Client -> Has a problem -> Looks for products that can be used or partnerships which can lead to the development of such products.
  
• Company -> has an idea for a product and wants to find early adopters to test their theory.

In the both scenarios, a POC is a set-up to validate the concept, where the company gets to work on a new idea and the client gets a working solution to their problem.

It is essential to have the core team working on the POC to be a part of the inception, review/feedback and closing meetings to ensure that the definition of ‘Proof of Concept’ and the success criteria are understood by all.

A successful POC would require setting agreed upon scope of work, key deliverables, success KPIs, and timelines on which the POC would be enacted.

Some of the first questions to ask include:

• Why are we doing this and what are we trying to achieve?
  
• What are the measurable success criteria?
  
• Is it achievable in the time frame allowed?
  
• Is it achievable with the resources available?
  
• What’s the real value we are hoping to achieve?

Post this the team assigned to work on POC conducts research and begins to develop the features/solution with the goal of proving that it’s feasible.

In particular, measuring and reviewing progress against a predefined set of success criteria at each stage in the process should improve the quality of deliverables. At the least, it would increase your understanding of the project as it progresses. Taking it a step further, applying the lessons learned from previous POCs would help to fine-tune your approach to future ones.

Once this is proven, the POC is extended to develop an integrated working model to provide a snippet of the final product.

After that, it’s either presented to the client and the product team to sell the idea for an upcoming project or it can be used internally within the development teams to share knowledge and stimulate innovation.

I presented two scenarios at the beginning of this article stating when a POC can be performed — when a client requests a company for it or when a company requests a client for it.

Below mentioned are some of the key points to consider for a successful POC.

If You’re a Company Requesting a POC:

• Understand what resources you will be expected to provide.
  
• Determine what the end result/benefit will be for you as well as to those performing the POC.
  
• Make sure that you are serious about the necessity of this project; typically POCs are requested and completed by companies who are already mostly certain that the process will be necessary, and just need to be convinced of the best method to accomplish it. If you’re still in planning phases, it may be better to wait on a POC until further down the road.
  
• For some projects, it may be good to ask the company for examples of other times they have performed similar tasks, as mentioned above; while every organization is different and reading case studies certainly won’t negate the necessity of a POC, it can be insightful and add experience to the process if you go into it knowing what to expect.

If You’re a Company Delivering the POC - A successful POC comprise of:

• An internal assessment of whether or not your company has the means to do take on the project.
  
• A separate POC for your internal team, covering how it should be carried out, what pitfalls will be inherent, what needs to be concentrated on, and how to work through the main challenges the project poses.
  
• An eye-catching, well-polished presentation for the customer; part informational, part marketing, this section should carefully outline the work you propose to do and how you will accomplish it, while also convincing them that you are totally awesome and that your awesomeness will rub off on them if they work with you.
  
• A technical write-up for the client’s internal test teams, detailing what will be expected of them, what your teams will take care of (or have taken care of already), pros and cons, how to address potential problems, etc.
  
• A detailed write-up of how the project will be completed, with a timeline and potentially a projection of costs for each step.

When a POC is possible, it can provide benefits to both the clients and the company providing it, offering both parties a deeper understanding of the undertaking, its costs, and its benefits.

The Most Important Step Here is to Document Everything!

Documentation should be done for your POC and it should include the step-up and configuration, steps of installation, results of tests that were performed, final findings and recommendations.

It’s important to document the POC environment so it can be easily replicated for the teams supporting your product. Well-written documentation will also ensure that other teams within the organization understand the POC steps and why certain decisions were made.

If you would like to get in touch to talk more, please reach out to me on LinkedIn. Alternatively, you can also email your queries to [email protected].

I send out newsletters every month answering your questions on any topic — sign up here. Thank you so much for reading till here :)

Happy learning!