How a Proof of Concept (PoC) Aids Development
#design #product strategy
Bringing a new idea to the market can be full of risks. The significant issues may be that the concept doesn’t work in practice, or the target audience doesn’t want it. Producing a minimum viable product (MVP) will quickly bring an idea to market at a lower cost than a fully-featured product. However, it won’t address these risks until the end of the development of the MVP.
A Proof of Concept (POC) is a faster and less expensive solution to testing the feasibility of an idea, both in terms of technical viability and market acceptance.
It allows developers to test out solutions and trial aspects of a product before committing to the complete development process
It provides stakeholders with the information needed for informed decision-making
It helps persuade senior management to proceed with full application development
It helps persuade investors to invest in the development of the application
Why would Developers Need a Proof of Concept?
Coming up with a brilliant idea for an innovative new application is terrific, but how can you be sure it works? Unless you’re running your own development business, chances are someone else will be paying for your time. They will want to know that they won’t waste their money on an application that will never make a profit — the more innovative the idea, the greater the potential risks.
A brilliant idea that requires a novel, expensive infrastructure may not be economically viable for its target marketplace
A function that is sluggish or prone to excessive latency may be too unresponsive for users to tolerate
Explaining the concept of your new application to non-programming stakeholders can be difficult. Showing them the idea is feasible with a working demonstration is a much more straightforward proposition. Some examples follow to explain this better. This approach is subtly different from a feasibility study for a development project that we’ve discussed before.
Examples of a Proof of Concept
Prototyping a Software Function
Suppose your brilliant idea is to develop a voice-activated app ride-hailing app. Users tell the app where they want to go, and it gets them a ride as quickly as possible. The majority of the functionality already exists, so you know that it will work. What you don’t have is any experience in voice recognition.
To eliminate the risk, you’ll either need to get expensive expertise to implement this function or develop a PoC to see if you can do it yourself.
The PoC will comprise software that decodes audio signals from a microphone and uses Natural Language Processing to detect spoken commands and generate an output demonstrating command recognition. This software will run on any laptop or desktop, so test users anywhere can try it out.
The purpose is to assure that the software will work across the target user base, irrespective of age, gender, accent, etc.
Potential additional benefits are that test users may try commands that the software won’t recognize because the developers forgot to include them, or no one thought a user would want to use them.
Feedback from test users can be in the form of a questionnaire or built into the functionality of the prototype code.
The code can be migrated to the target development environment when the PoC works consistently and accurately to prove effective. A significantly simpler process than starting from scratch.
Nailing down the User Interface
Another example is the user interface for the app may be proving troublesome to nail down. The customer may not be entirely sure what they want. The developers may not be sure the requirements will work.
A PoC for a user interface can start with a simple sketch or a computer-generated image shown to the customer, developer, and end-users to gather their views.
The feedback collection can be through interactive discussions, face-to-face meetings, or a simple set of questions.
The next iteration can be a dynamic user interface using simple HTML, a product like PowerPoint or, a specialist design UX tool to give users a more realistic PoC to try.
Feedback gathered can then feed into wireframe designs to create a representative app interface for a more thorough evaluation following the finalization of the user interface design.
Scoping the Proof of Concept
New applications may use standard off-the-shelf or reused software at their core. Typically, the innovative features are limited to small functional areas. You only need to prove that these novel parts will work to be confident that the whole application will work. A POC allows the developer to implement those parts of the application where there is a question mark. It’s an entirely different approach to prototyping an application or creating an MVP. The purpose is to mock up small parts of the application to test them out. The aim could be:
Implementing an algorithm to test how it works or check its performance in a realistic environment
Creating a mock-up of a user interface to test how users interact with it
Building an environment to see if the technology will work
A POC is the process of testing to see if an application idea will work in the real world. The typical questions that a POC can answer include:
Will the application work?
What skills, resources, and technologies will developers need to build and operate it?
Will the performance of the application be acceptable?
Can the application be implemented with the available technology and resources?
How usable will the application be?
Will the interface between the application and other systems work?
It may answer all these questions, or the scope may look to answer one specific question.
Proof of Concept Terminology
The term Proof of Concept can be prone to misunderstanding by customers, confusing with similarly-sounding terminology. We have previously discussed the differences between a POC, a Prototype, and an MVP in this article.
Here are a few more examples:
Proof of Concept vs. Pilot
A POC differs from a pilot regarding size and scope. It focuses on elements of the proposed solution rather than the entire solution. Its purpose is to validate the viability and performance of these elements. The evaluation results will de-risk the novel concepts, allowing further refinement if necessary. The result will feed into the development of the complete solution. A pilot, on the other hand, is a dress rehearsal for the complete solution. The scope is greater than a POC but still smaller than a full-scale implementation. A pilot tests not only the system but also the environment. A POC has a shorter timeframe and lower costs than a pilot implementation due to its limited scope. The pilot will give end users a representative product to evaluate.
Proof of Concept vs. Proof of Stake
Often terminology may become confused. For example, proof of stake is a process specific to validating the addition of transactions to blockchains, a mechanism for securing integrity by placing conditions on those performing operations. There is no equivalence between a POC and proof of stake.
Proof of Concept vs. Proof of Work
As for proof of stake, proof of work is another blockchain-related term that refers to the action of performing computational processing to create a new block for addition to a blockchain. There is no equivalence between a POC and proof of work.
Proof of Concept Benefits
1. Development Benefits
The POC will allow developers to test functionality in a live or representative environment.
A POC will show that the proposed function will work using available technology, and its performance meets expectations.
A POC for a user interface will allow developers to gain valuable feedback on its ease of use, attractiveness, and appeal to users.
User feedback in this instance can drive iterative development of the POC before finalizing the interface design. The results of this exercise can then feed directly into the product development.
Producing one or more proofs of concepts will allow developers to de-risk functions, trial technologies, and refine user experiences.
It can predict pain points and allow these to be avoided or planned around.
The POC resolves the challenging issues, smoothing the development process and reducing the time to market.
The POC can also allow the developer to identify aspects they didn’t know existed as an added benefit. It can provide opportunities for identifying additional features, or new market opportunities, or potential enhancements.
2. Financial Benefits
A POC provides evidence that the idea is feasible, practical, and achievable with minimum costs.
It can help demonstrate a business idea is economically viable before committing to full development.
De-risking development will mean that a business will not need to commit funding to develop a product that may not be viable.
An added benefit is that POC can offer potential investors better insight into the proposed product and demonstrate feasibility before committing funds.
Metrics from the development process can underpin development planning and cost estimations. In addition, feedback from the marketplace to demonstrate features can refine calculations of return on investment.
The key takeaway is that while proofs of concept generally focus on the technological feasibility of an idea, it also validates the business model’s viability.
How to Write a Proof of Concept
While producing a POC is a cost-effective short-duration activity, you’ll still need to follow a process to justify its expense. The following steps provide a template for how to write a proof of concept.
1. Scope the Idea
The first step is defining the problem that the POC will solve. Then, what is it trying to prove, and how will it achieve this?
Typical goals include:
Prove an algorithm is correct
Prove a code function will execute within a defined time
Gather user feedback on a user experience
Prove integration with other systems will work
A tight scope and clearly defined end goals will improve the chances of a successful result.
2. Demonstrate a Need
The POC needs a clear purpose derived from the scoping. This could be demonstrating technical feasibility to gain investment or commercial viability to get the development go-ahead.
3. Identify the Solution
Once the scope and purpose of the POC are known, a solution can be conceived, planned, and designed. If the problem is complex, break the problem down into several smaller development steps. Identify the resources required, the technology needed, and the timescales for each step. Where dependencies exist between these steps, include these in the planning process. The result will be a project plan for producing the POC and a list of prerequisites needed before development. Steps can be developed sequentially or in parallel, depending on prerequisites, dependencies, and resource availability.
4. Produce the Code
Creating prototype code should use the standard software development processes. In addition, code testing should ensure it is free of significant bugs that would prevent the evaluation of the prototyped functions.
5. Evaluate the Code
The prototype code can then be evaluated against its goals by appropriate evaluators. An assessment of a POC for demonstrating an idea that will work can be done internally. A POC for a user experience should ideally include feedback from representative users.
6. Present the Results
The results of the evaluation can be fed back into an iterative prototyping cycle for refinement. Once the results are available, decision-makers can use the proof of concept study outcomes to approve the go/no-go choice. POC also offers the ability to build a knowledge base of experience that can inform subsequent POC activities and future application development.
How do I get a Proof of Concept?
The following checklist provides a template guide to the proof of concept steps required.
Scope and Approach
Is the scope defined?
Have the business goals been identified?
Are the technical requirements defined?
Are any technical dependencies identified?
Have costs been estimated?
Is the POC process defined?
People and Resources
Have all stakeholders been identified?
Has the authorizing body been identified?
Has financial approval been obtained?
Have resource requirements been defined?
Are all personnel with the required skill sets available?
Are technical resources available?
Development Environment
Have all environmental requirements been identified?
Have all configuration and access requirements been identified?
Is a suitable development environment available?
Is a live or representative production environment available?
Implementation
Are all resources required available?
Are all POC application requirements defined?
Are design, implementation, and test tools available?
Code Evaluation
Has the POC been tested
Are the evaluators identified and available?
Has the feedback process been defined?
Are the key success factors identified?
POC Assessment
Have all technical reviews been completed and results documented?
Have all business reviews been completed?
Have POC recommendations been collated and documented?
What comes after Proof of Concept?
The results of the POC will provide stakeholders with the information needed for informed decision-making. Investors can decide whether to invest in the application. Senior management can decide whether to authorize the development and what resources to allocate. Finally, developers can incorporate the findings into the development process. The next stage may be to turn the POC into a complete function prototype. Alternatively, it may lead to an MVP. Or, if the POC demonstrated the idea was not viable, it may lead to a return to the drawing board to think up a better idea. No matter if you already have the prototype or looking for a partner to develop a POC Enkonix can help you at any point of your journey, just drop us a mail and we will contact you to provide free detailed estimation.
