Do You Need a POC?
Talking to a few folks recently, and it seems there's still a lot of confusion around terminology when it comes to "that very early initial version of a product." So let me give my personal explanation. Today: The Proof of Concept (POC).
POC: Can It Be Done?
A proof of concept has one job: Determine whether the core piece of your idea is feasible. To do this at the lowest cost, it strips away everything else. For a concrete idea, let's say you want to make an app that lets people virtually try on clothes. The core piece in that example is the image manipulation AI that would take an outfit and apply it to someone's image (or live video from their phone's camera.)
Assuming we don't know for sure that this can even be done, a POC would not concern itself with building a mobile app, integrating with the store's product catalogue, having cloud architecture ready to handle real customer data, etc.
Instead, it'd be as simple as having an app running locally, with static input data, figuring out if that one crucial piece can be done.
The outcome of a POC is not a product that you can ship to users. It's an answer to the question, does it work at all, and if so, how would it work? It's job is to de-risk your overall investment of time and money.
When Do You Need One?
Not every idea needs a proof of concept. If the biggest question isn't whether it can be done but whether it should be done, you should start with validating the market (again as cheaply as possible). So, what are some signs that your idea might benefit from an initial POC?
If it relies on new technology where the lack of maturity means nobody has a clear idea of where exactly its limitations are
If, at a technical level, nothing like this has been done before
If it involves using AI or machine learning beyond standard techniques on standard datasets
Why not just jump straight to coding?
I like to eliminate the biggest risk first. In situations where I advise to start with a POC, the biggest risk is not knowing whether the core piece is feasible. So any work that's not directed toward addressing that risk is potentially wasted:
Either it turns out the idea doesn't work, in which case the unrelated work was 100% wasted
Or the idea is feasible, but it took us longer to figure out the what and the how because our focus was diluted
(If this sounds like it goes counter to the advice to not delay integration for too long, i.e., not build everything in silos to only connect the pieces at the end, that's a topic for another email.)
For now: Figure out what the biggest risk with your product idea is, and seriously consider the simplest possible proof of concept before spending time and money on anything else.
