Open Concept: Everything You Need for a Persuasive PoC
So, you’ve been asked for a proof of concept (PoC) to demonstrate a new feature, share a new idea, or show a customer what you can do. Whether this is your first PoC or one of many, stay calm. In this article, we cover everything you need to have in place to create a PoC that will wow everyone. Later we will share how you can create a PoC at lightspeed, using all this infrastructure.
In the Beginning, There Was the PoC
First things first. The goal of a PoC is to demonstrate one or several theoretical concepts in practice. For the purposes of this article, we establish that a PoC is one or multiple applications built to prove the various OutSystems Platform capabilities. With that being said, to create a good PoC in record time, you will need to:
- Get all the stakeholders involved and onboard: All the people involved (delivery manager, engagement manager, developer, internal or external client) have to be committed and available when needed. You might have to do a little bit of “selling” to get them excited and enthusiastic about the project so they are happy to be available and committed.
- Identify the type of PoC: Determine whether you need a web application, mobile application, integration, or a combination of any or all of these. You’ll also want to decide if a specific type of device is required.
- Define your evaluation criteria: What objectives will the PoC need to meet and how will their success be measured? It’s important to answer these questions and get everyone’s agreement on them before development starts.
- Have accelerators and all the reusable content available:This will ensure that you can quickly create a structure that serves the PoC’s purpose.
If all these conditions are met, you will have the foundation to start your PoC with success, so we’re going to take a closer look.
Roles in the Deep
A successful PoC starts with a team that knows exactly what to do and when to do it. This is especially important for fast-paced development, where there is no leeway for misunderstandings or delays. On this team, there’s an engagement manager (or product owner) who is responsible for engaging with your client and transforming the client’s vision into user stories to be implemented and presented as the PoC to the client. The engagement manager should be comfortable working with the technology, and you’ll need to make sure that all the right permissions and configurations are in your demo environments.
The delivery manager or tech lead is the go-between for the engagement manager and the developer. The delivery manager should help create the data model for the PoC and be able to answer any technical questions from the developer, all while ensuring that the dev and demo environments are available and in good shape. The most important responsibility, however, is monitoring the PoC’s progress, especially during the development phase.
The developer should have a good grasp of usability concepts, be ready to suggest additional implementations that could wow the client, collaborate with the engagement management on PoC improvements, and be willing to challenge the status quo. Getting a PoC exactly right means being critical and being able to suggest adjustments to the use case scenarios. And that’s just for starters. A good PoC developer focuses on what is important to prove, taking responsibility for the use case implementation, and checking and rechecking that what is being implemented is really what the client wants.
Discovery and Definition
Now that you have a team with clearly defined roles, it’s time to take care of the scope and acceptance criteria in what we call the discovery and definition stage. This stage is critical to building a successful PoC, and it needs to happen before any development begins. It’s at this time that the engagement manager meets with the client to gather requirements, define the scope, and identify the evaluation criteria points.
The engagement manager then visualizes and translates all the client input, which will have a business focus, into the main user stories to be implemented in the scope of the PoC. These, of course, will be technology oriented. Based on meetings with the client, the engagement manager can determine some features, capabilities, or something else extra-special that will impress the client and sell the Poc. (Our favorite term for these extras is “wow factors.”)
It’s also at this stage that any specific integration, VPN needs, or database configurations must be addressed. All the infrastructure must be tested before the PoC development begins.
At the end of this phase, you will have:
- A clear understanding of the scope
- Customer branding
- A main use case
- Seed data
- Success criteria
- Plan and timeline
- UX/UI mockups (if applicable)
- Wow factors.
To Best Practice or Not to Best Practice: That Is the Question
A PoC is a one-time event. This means that the code of each PoC is not to be replicated and that most times you’ll just throw it away. So why am I saying this? Because, although you need to meet all the requirements and be proud of the end result, the POC is not ready for production. It is built for demo purposes only, and may not follow all best practices. For instance, usually, there are no concerns about architecture and scalability. For example, if you are using OutSystems to build your PoC, here are the best practices you can disregard:
- Modular architecture (4 layer canvas)
- APIs for core actions
- UI validations
- Indexes
- Mobile complex synchronizations
Of course, there are plenty of OutSystems best practices that you should use, such as Green True Changes, and other favorites.
Note that a PoC should not grow into an app. When it’s time for the real thing, use all the best practices and give the needed TLC to your app. I can recommend some articles on front-end architecture, application architecture, and mobile best practices that will take your PoC from a good idea to a full-blown application.
With a Little Help From My Friends
Besides the best practices, there are some nice ways to accelerate PoC development. Consider these your best friends:
- Sample users: Every proof of concept has users. Build a database with users and all kinds of information needed per user that you can reuse. This ensures users are always available for each PoC.
- A well-defined framework: Don’t waste time re-creating components and references that already exist. Instead, use a framework that already has components and references, like Silk, that you can use multiple times.
- Patterns and code pieces that you can turn into components: Whenever you find graphic designs, UI, plugins, and other things that you believe you’ll keep using, instead of copying them from one PoC to another, componentize them, and add them to your framework.
Lessons Learned
Every time you do a PoC, you must get the participating team together afterwards to discuss the lessons you learned. This phase is fundamental to accelerating your overall PoC creation process, and yet it is often overlooked. No matter your role in the PoC practice, do your best to make this discussion happen. Not only can you highlight what went well and why, but most importantly, you’ll identify what went wrong and why. Just like any other project, you will have challenges and issues throughout the development. By discovering what they are, you can design practices and solutions that can prevent them in other iterations. This is also a great time to find out if there’s something you can turn into a reusable pattern or if you have discovered a new accelerator.
A Perfect PoC
When all of these pieces come together, you will have a perfect PoC. It’s that special place where you end up with a demo that meets or even exceeds the client’s expectations. The user stories are fully tested, there is data you can reset (so it’s ready for more than one demo), and a great UX/UI and wow factors are in place so you can close the deal. The engagement manager and delivery manager are invested and know the demo by heart and can even make changes live during the demo that knocks the ball out of the park. Usually, this change scenario should be well defined and previously tested.
A Never-Ending Story
Creating PoCs is no easy task. Yet, every new PoC opens new possibilities and presents new challenges. The thing is, if you don’t have everything I’ve talked about in place, the weekly fast-paced, controlled chaos in which we live will quickly become just nerve-wracking chaos.
That’s why you need these prerequisites to be in place (even the ones that come after the PoC) before you start to code anything for a PoC. With them, your blood and sweat will bring you to a perfect PoC instead of to tears.
