Imagine that a new tech idea strikes you that is presumed to change the fate of the startup. The team working for the startup does its research around the concept, and it seems quite possible to bring it into reality. But, it lacks proof of concept.
That is, there is a need for a solid and undefiable proof whether the idea will even work or not. Being the founder of a startup, you just can’t afford to take unplanned risks.
A PoC, aptly called the Proof of Concept fits in here. It answers the big question: whether you can proceed with the hypothesis or not?
Here are the two outcomes of running a PoC:
- Yes, the concept is viable from a technical standpoint
- No, the concept is practically unfeasible
If a PoC gives a startup the green signal, the transition can be made to develop a prototype followed by an MVP, which further leads to the development of a full-fledged distinctive app.
A Real-Life Example of PoC Implementation
Walmart supposed the blockchain technology to be a good resolution for its decentralized food supply ecosystem. To validate the hypothesis, they created a food traceability system based on Hyperledger Fabric.
They partnered with IBM to test the practicality of blockchain technology in building a food traceability system. One PoC revolved around tracing mangoes around Walmart’s US stores, while the other revolved around tracing pork sold in China.
Both the PoCs worked! With the go-ahead from IBM, the retail giant was able to trace the origin of over 25 products from around 5 different suppliers using the technology.
If it was not for the Proof of Concept, Walmart would have been still pondering on to invest or not in the blockchain technology, leaving it to be in a high-risk situation either way.
The Key Expectations When Building a PoC
A Proof of Concept (PoC) precedes the real-life implementation of an idea. A Proof of Concept is meant to determine the feasibility of an idea, and it is advised to never overlook or skip it, especially when the business stakes are high.
This is an illustration of the entire flow of the process followed by PoC.
To guide you through, here is what to expect when trying to build a PoC for your startup.
A good understanding of the expectations will not only keep the business makers informed but will also help them make a smart decision before draining all the resources.
There is No Reference “Prior-Art”
When building a PoC, the first thing that comes into the picture is R&D (Research and Development). The tech team needs to conduct extensive research around the history of similar work done or being done across the globe.
If there is none, the next step should be to analyze existing guides, PDFs, scholarly articles, or even tutorials that would act as a key point of reference for the team.
In case, even that is not readily available, consider your idea to be novel and if it falls in place, it can mark you as a leading pioneer!
However, proving the technical feasibility of a stand-alone project does not have a “How-to” reference.
So, the development team is left with three things:
A. Their instinct that comes with experience
B. Skills that are driven by knowledge, and
C. Curiosity to try something new
Thus, combining the art of technology and the development team’s understanding, a unique path of a PoC is quite achievable.
Key Takeaway: It may take time to build a Proof of Concept. It may sometimes seem infeasible. But, challenging the team’s technical abilities is the key here. Setting your own standards can call for success when a business is still in the developing phase.
PoC’s Don’t Always Follow the Plan
Turning theoretically existing concepts into practically feasible ventures is the purpose behind building any Proof of Concept. Although the experts might be having a plan on how to prove that practical feasibility, they may sometimes fall off the track.
It should be understood that Proof of Concepts follows a try-and-test trajectory that cannot rely on a consistent path across the flow of the process.
It is similar to a “Snakes and Ladder” journey which sometimes takes the team up the ladder, but might also lead to making a fall.
This is where it is essential to give weight to inner instincts, i.e., it is time to make a data-informed decision.
And, if you are wondering what might cause the snake to bite your progress, (metaphorically speaking) the answer narrows down to the selected technical solution simply failing to produce the desired result, technical inefficiencies of the team, financial limitations of the budding startup, or the team not meeting the set deadlines.
Another reason that might hamper PoC development could be a problem with patents. The path to a solution may lead your team through a minefield of patented solutions that you would either have to license or work around.
Key Takeaway: Accept what comes your way and be ready with a Plan B when Plan A seems off track. Having a broad perspective should be the bigger agenda of the team. Do not stick to traditional methodologies, as the possibilities introduced by technology are infinite.
PoCs Are Not MVPs
The most common misconception that has been doing the rounds in the tech world is that people think that PoC is the same as the MVP. But, here’s the truth:
PoC (Proof of Concept) exists to check the feasibility of bringing a technological concept into reality before the startup spends its resources into its building phase. It, therefore, mitigates risks associated with trying something for the first time.
On the other hand, an MVP (Minimal Viable Product) is tiny or let’s say a basic version of the real product that exists for market validation.
As and when potential user personas are exposed to MVPs, refinements to the product are made based on user feedback and reviews.
In short, PoCs exist to convince the stakeholders, managers, and investors, whether the idea the startup is working on, is worth trying or not.
It is more of a surety that any business entrepreneur would require before spending too much on a concept’s full-scale production.
And, MVPs contrarily are tried and tested ideas that are launched in the market with the intent of getting better with time.
There are user personas involved that interact with the MVPs, who in turn provide feedback based on the digital customer journeys experienced.
Here’s a summarised table that lists the differences between PoCs and MVPs.
Key Takeaway: Do not believe what others say or preach. Deploy the team to conduct their own research on what a PoC is all about before moving any further. Also, conducting meetings to explain your agenda behind the PoC development process is a good idea.
Everybody Has an Opinion
Everybody is entitled to their own opinion, and that is a good thing. At least, your startup is giving a platform to everyone to have one.
The truth is that everybody has a different perception and interpretation of the Proof of Concept.
Be it be prime decision-makers, IT head, development team, or the principal stakeholders, they all take PoC differently.
So, respect each of the parties involved to achieve a common understanding of the goal.
Bringing everybody on the same page is highly crucial, which starts with:
- Defining success and acceptance criteria for the PoC
- Sticking to technical “to-Do’s” over UX design requirements
- Aligning expectations that are subject to mutual interests and decisions
- Having a communication model that works towards keeping everyone informed and updated
- Close collaboration among key people involved so that the PoC does not fall short on loose information
- Having a pre-set timeline for the building a PoC and sticking to it as much as possible
Key Takeaway: Build the foundation of the PoC based on three areas, i.e., communication, collaboration, and timeline. Let the key people involved in building a PoC have a say in what they expect out of the PoC. Do not leave anyone behind just in the intent of rushing things.
Your Tech Partner May Get it Wrong
PoCs can be hard to get through, especially when the concept is completely new in the market.
So, hiring a tech partner could be the right choice owing to the knowledge and experience involved in their case.
If they prove that the technical concept stands a chance to witness the dawn, nothing could be better.
On the contrary, you can also hear a “NO” from the tech head honchos.
Does that mean you need to give up and agree to their words?
Perhaps you should take that with a grain of salt till you see the proof & data behind the denial.
Challenge the tech partners, have some additional documented proof that you can rely on, or when your gut feeling tries to convey a different story, feel free to consult and even engage a different third-party expert to validate. Because tech partners can be wrong too!
Here are the five mistakes you should avoid when working with the tech partners:
However, that nowhere means that the startup stays stuck upon an idea that has no practical perspective. In simple words, if you choose to challenge the PoC feasibility, know when to stop.
Because if you don’t, the startup will be wasting its resources and time, thus, stagnating the overall growth of the business endeavor.
Key Takeaway: Ask for an undefiable proof that negates the possibility of the concept. If you decide to take your own course, talk to the experts about your doubts and related queries. Going the extra mile could be your best bet if you believe strongly in something.
Conclusion: What Works?
A Proof of Concept purely answers whether the technology that is under consideration would fulfill the purpose it is being designed for or not. And, knowing what exactly to expect when building a PoC is ever essential.
When building a PoC for a mobile app development project, these are the common aspects of the app that need proving:
- New-in-the-Market APIs
- Security Technology
- Custom Controls
Taken that your startup is excited to try something untried, hiring a tech partner for app development is the best strategy to try. The decision is similar to killing two birds with one stone, i.e., they will build a PoC and will also help with bringing the concept to life.
Thus, a win-win situation!