roof Of Concept (PoC), sometimes also called as Proof of Value (PoV), is a rough prototype which intends to prove that a system or solution has the potential to become the end solution for a problem or challenge. This rough prototype is an exhaustive test of the possible limitations of the system or solution proposed for the presented problem.
When relating this topic to the OutSystems ecosystem, PoCs are very common in the sales cycle for new clients. One of the stages of the sales cycle is the technical evaluation of the platform. Usually, during this stage, the prospect is trying to compare the OutSystems platform with other platforms available in the market and trying to understand if the platform fulfils all the technical and non-technical requirements they have in mind. Furthermore, trying to challenge the limits of the platform to understand the future proof of the platform as a long term solution for them.
This stage is vital and very powerful to establish viability, isolate technical issues, and suggest an overall direction, as well as providing feedback for budgeting and other forms of internal decision-making processes. Not only the technical challenges can be addressed in this stage but also non-technical questions, like the ease of use of the platform, the learning curve for non-technical people, etc. It’s critical for the success of the PoCs to set the right expectations and to monitor everything that happens during those days when the development of the PoC is performed.
The desired outcome of a PoC must be that the prospect clearly understands the power of the platform, the people in the organization get enthusiastic to use it and the board members see the value that this solution can bring them. This value is more commonly measured in a direct impact on the ROI, but can also have an indirect impact by influencing metrics like satisfaction, happiness or environmental improvements. All this information must be collected and discovered during the PoC by engaging with the prospect on several levels.
As mentioned before, PoCs are very powerful, but there are a few rules that must be followed to keep the governance of the proposed solution. PoCs are rough prototypes and should only be used as prototypes. This means that they should not evolve into a production product. It is not unusual to see prospects getting enthusiastic with the prototype, wish to add a few (always just a few) more features, and want to turn the prototype into a product.
While developing a PoC make sure that you don’t “cut all the corners”. Changes in the requirements can and should occur and the corner you cut might be of use. By this I mean even knowing that it’s a rough prototype I’m a personal fan of following best practices always, overall, doing the right thing the right way doesn’t cost much more time and can be very useful when less expected.
And here it goes my golden rule: Less is more! Make sure everything that you deliver works and doesn’t fail, the most inconvenient thing that can happen is that your application breaks during the final demo and you get stuck in the middle of your brilliantly prepared journey.
The right ingredients for a successful PoC: A small but very experienced team, as you may face questions that you have never been exposed before. The right set of expectations. These must be mutually agreed before the starting of the PoC, confirmed regularly during the execution and revisited at the end of the work. The right people from the prospect should attend the meetings and demos. Having the right people from the prospect has the same importance as executing an excellent job. Without them, your shiny and impressive PoC will be invisible to the eyes of the decision-makers.
If you are new in the OutSystems ecosystem and don’t feel ready to do the first PoC alone, send me a message using the medium channels or leave a message in the comments and I will be very happy to guide and support you with my best efforts.