Software development Proof of Concept in 4 weeks — is it possible?
Many people tend to confuse Proof of Concept in software development with prototyping. Well, it’s not the case. And this article will help you tell the difference once and for all, by also answering the pressing industry question: is it possible to complete an effective PoC in less than 1 month? Keep reading to find out!
But first, let’s learn what Proof of Concept really is and how it is classified.
What is Proof of Concept in software development?
A Proof of Concept focuses on determining whether an idea can be turned into a reality. At Miquido, we distinguish 2 main types of PoC: innovation research and market validation. However, there are a few other options that might work best in your specific case. Let’s take a look at each of them.
An innovation research
This type of PoC is also called a feasibility study where we figure out how to boost your business with new technologies, like Artificial intelligence, Augmented Reality, theInternet of Things, etc. With innovation research, we test and investigate whether your idea is actually doable.
After all, the right choice of the SDK on which the core feature is based may affect the selection of the entire technological stack. At this stage, it is very important to clearly communicate that something may not turn out as the customer expected, explain why the solution did not work, and propose alternatives. Don’t be afraid to disprove the hypothesis and try again.
Market validation
Market validation of the idea for all the stakeholders to see if the idea is worth implementing. Here, we already know that something will technically work, but we still need to evaluate the feasibility of the business opportunity. Many companies would have a dedicated Research and Development department to deal with it. R&D experts are focused specifically on validating concepts and verifying innovative ideas.
Internal validation
This type of PoC is usually conducted at the vendor’s expense. Internal validation proves useful when an innovative solution is encountered during the development stage, meaning that it hadn’t been taken into consideration while creating the technical requirements. That’s exactly why it has to be verified before it could be implemented — to make everyone in the team sure how or whether it would work at all.
“Sales” Proof of Concept
Finally, there is also a “sales” PoC, when a customer cannot imagine how the product is supposed to work. By carefully examining your needs, R&D team can help you check if the vision for the project makes sense.
With so many options at your hand, a natural question arises: how to perform a rewarding PoC in one month? Let’s learn some best practices which result from our experience (the more met, the greater the chance of success):
1. Know the PoC meaning and sense
Nomenclature can be confusing and cause misidentification of the assumptions. You should not confuse the PoC with a clickable prototype or an MVP.
Proof of Concept is carried out for a well-defined purpose: to prove technical and/or business assumptions. It may be a functional product but can not be released on the market. The key is to be aware of the difference and when for what purpose we use what.
Sometimes a PoC is called a prototype interchangeably, and that’s not bad, as long as it’s not to be confused with clickable designs. Determine what exactly you want to show and test. Knowing your needs, sometimes we advise our customers not to do PoC, because choosing PoC is not a universal solution that will cover all customer needs and doubts.
2. Define precisely what has to be done
It is a common good practice to determine the solution range that you do not want to cross, the hypothesis and objectives, what you want to achieve, and possibly what alternative paths you see in case of failure at the very beginning of the project. The well-defined scope is the key.
If you want to take it a step further, treat your scope as the ultimate guide and steer away from any changes to the plan.
3. Clear your path before the takeoff
Think your business idea through and gather as many relevant materials as possible. Don’t be afraid to prepare a risk matrix to identify technical opportunities and restrictions. Remove all visible blockers and obstacles before development. Have designs as well as all the external components your PoC needs (such as backend or libraries) ready beforehand, gather your prototype’s complete specification and double-check project documentation to be sure to have a smooth start.
4. Accept that PoC’s code is disposable
Make sure your customer knows they deliver something for a review, not to have a complete working and market-ready product. Regardless of the type of PoC, it is very important that the customer does not expect reusable code from which to develop the product further.
Whatever arises will be suitable for throwing away. In the process of creating PoC, everything is done faster, without paying attention to the unnecessary details (such as RWD) and delivery of valuable production code. Unit tests, as well as code reviews, are basically non-existent. Remember that during the PoC we do not deliver a clean code. All this is unnecessary because we just want to validate something rapidly.
5. Simplify your solution as much as possible
You should cut your project’s scope to an absolute minimum. The best, yet radical approach for a PoC is to deliver the least possible. A common example is the authorisation by social media (Google, Facebook, Instagram, etc.), which normally includes several MDs of development. Instead, you can do Firebase Anonymous Authorization (no account creation) and take just a few hours to do it or, simplifying even more, hardcode the users in the database.
Furthermore, try to only focus on the crucial features. For example, think twice before spending time and budget on premature optimisations and stuff like that. Instead, assess only the core processes of your product.
For example, instead of creating Chat or InApp notifications yourself, you can use GetStream and RevenueCat. Doing so will save you money in the beginning that you can later spend on creating your own implementation when the ready-made solution exceeds its limit as your product growth.
Note: Of course, the above-mentioned examples are not universal, they have their advantages and disadvantages. If you use GetStream to create a chat and then decide to create your own, there may be a problem with migrating existing data. It all depends on your needs and requires tailoring from the very beginning.
6. Speed up the communication
You might have noticed that the industry benchmark for an MVP delivery is 3 months. Proof of Concept, however, operates in a much tighter timeframe that, ideally, should take about 4 weeks.
In some cases we draw inspiration from extreme programming whose goal is to satisfy the customer by delivering high-quality, valuable software in small intervals. Each Sprint is divided into 1- or 2-day iterations (Innovation Spikes), after which we come back to the customer to talk about the findings and define further actions. Projects of this type are very dynamic, we quickly check which way to go, because there is a tree of possibilities ahead of us.
One problem often consists of a series of smaller sub-problems. Sometimes you have to go back and change the assumptions a bit, usually because they may prove to be impossible to implement without any adjustments. During the cooperation, it is crucial to maintain constant communication to talk through the research findings and discuss the next steps.
To achieve the best results in a limited timeframe, the process should be highly iterative! We evaluate ideas together with the client and gradually implement improvements. We place great emphasis on frequent, even daily verification statuses, and on the diversification of communication channels in case one of them fails.
7. Pay attention to the human factor
It is of utmost importance to engage developers who you can be sure will really check out all the possibilities before telling the customer that something is not feasible. Since this process is very agile, it is also good to limit the number of developers working on the product. This way you will be reducing the dispersion of knowledge and responsibility.
Our last one-man journey became one of Miquido’s greater success stories where the whole PoC scope was delivered twice as fast as it was initially planned. Senior Flutter developer was responsible for validating the idea of building an app consisting of gamification in retail. He performed solid research, prepared a risk matrix, created a backlog with a small commitment of a Project Manager and engaged the customer in frequent interactions. Thanks to his good work organisation and conscious resignation from code review, it allowed the client to save a really large part of the budget and let us gain his trust for future cooperation.
8. Choose your toolkit wisely
We use tools designed specifically for fast prototyping. When it comes to validating technical functionalities we use various technologies for this. When, however, we need to quickly verify a business idea, Flutter and cross-platform seem to be the best choice. Firstly, because the interface is created really quickly, and secondly, thanks to Hot Reload the app is ready right away for both platforms.
Here is how you launch a solid PoC in 4 weeks:
1. Start with a determination of objectives, initial analysis, and a kick-off meeting.
2. The study phase comes next. It is divided into 1 − 2 day Innovation Spikes — quick iterations fulfilling specific subsets of requirements and each followed by a results analysis and a discussion of the next steps.
3. Deliver a prototype after a couple of Innovation Spikes. It proves product feasibility (or a detailed explanation of why it is not feasible).
4. The process can be stopped here or be followed by the exploration of alternatives.
