4 Situations which Warrant Building a POC • Slash

Table of Contents

A POC to Check for…

Feasibility

The first, and seemingly most obvious time a POC is needed, is when the feasibility of a product or specific feature set therein must be tested. You may think the market and/or your users need it, but diving head first into a lengthy development cycle without testing your idea first can have serious ramifications for more than your budget. This is not coming from me as a solution architect, this comes straight from the horse’s mouth; in this case product owners and actual clients.

Just as programmers will test their code to ensure it works properly and is bug free, so too must we test product ideas and even specific features. Maybe you want a certain animation or design incorporated into your mobile app. Have you considered whether or not it’s feasible with the current design? How will potential users react to this? Will this feature work smoothly with all the other feature sets currently in the mobile app? In order to answer these questions, building a POC is necessary and will serve to validate or invalidate the feasibility and effectiveness of what you’re trying to accomplish.

For example, adding some catchy eye-popping animations might sound like a great idea. Who doesn’t like a good PowerPoint with transitions, am I right? Me for one, just give me the slides thank you very much. My point here is that some features that for example work for a dating app, don’t work for a wellness app. On the surface it may not seem that way, but when you’re looking at a POC then the reality will clearly set in and you’ll have a clear idea of whether it’s a go or no-go.

Complexity

In the world of development, not all features and their lines of code are made equal. Some, as you can imagine, are considerably more complex than others. For example, imagine your team is seasoned with AWS development and has no issues with this tech stack. Suddenly, a client comes to you and requests something built in Salesforce. Well naturally this creates an unknown situation which I will cover below, but wrapped into that unknown is the complexity of developing in this new tech stack.

Therefore, it’s necessary to build a POC to correctly understand how the tech works, how complex it is and judge whether your team can handle the task or if additional training and/or onboarding will be needed until the team’s ability and velocity get up to par. If the team is not up to the task after tackling a POC, then you know walking away from that and looking for an alternative is the optimal thing to do.

Understanding

Understanding, this is key to knowing what exactly you are tasked by the client to build. Are you creating a web app with multiple plugins, an intricate dashboard, super admin features and so on, or are you creating a mobile app in native Android and iOS? Or perhaps this is feature related… What is the purpose of this specific feature? What are the client’s intentions and goals for this feature in regards to user interaction and engagement? Features like in-app purchases, payment abstractions, data lake terraforming and more can cause additional complexity issues if you cannot first understand how they will be implemented.

When you cannot clearly answer these questions, the time for a POC is here and now. The POC will help you better understand once you can see the moving parts, what precisely needs to be done and whether or not you can deliver. Increased understanding will aid in estimating, product roadmapping and more.

Unknowns

As I hinted at above, unknowns can often be an ideal situation to whip up a POC before moving your project forward. If your client is looking at building something truly cutting edge and there’s nothing out there you can compare or analyze it to, then the level of unknowns will be naggingly painful. These are the unknowns that wake you up at night with a cold sweat wondering how you’re going to manage to get this feature set aligned with this other one and whether or not the code is robust enough to handle the API stream and so on.

Imagine being asked to build an entire new social media app with built-in dating app features and full custom AR interaction capabilities for users to communicate with unique AR messaging, with AI generative text-to-video/photo, a crypto coin for an NFT e-marketplace and so on. Point being, this is a situation that has so many unknowns you may even need more than one POC so roll up your sleeves and get to it.

Consider the situations and examples above all as possibilities. Worst case scenarios or not, if it doesn’t work like you thought and the POC ends up sending you back to the drawing board, it’s a small price to pay rather than going ahead without a POC and running into considerable trouble down the line that could even derail the product and see it ultimately end up failing.

A POC is not a panacea for what ails your development project; however, it can be a very useful and even powerful tool to leverage to your advantage when the situation calls for it. Therein lies the catch, only look to build a POC when the situation calls for it rather than wasting time when the cost-benefit analysis is not in your favor!