The Proof is in the Pudding!
Photo by Edward Howell on Unsplash
As a junior in the industry, I'm still working my way around some of the terminology that gets used. One such thing was around the point of a "proof of concept" or PoC. Honestly, when I was asked to make a PoC, I thought this was a learning exercise for me - a good way to get my practicing what I've learned. I didn't realise that I was actually being asked to do something "real" that would add value to my team....
What is a PoC?
A PoC is a pilot project, usually a basic version of something that a business wants to implement to check the feasibility of it. The idea is that before a company/team invests a load of time and resource into a new tool or process, they check to see if it might actually work. A PoC helps to answer questions that theory alone can't..for instance..does this new tool actually work for the specific context? What blockers are there for implementation? Is the amount of work worth the change?
What a PoC isn't...
You'd be forgiven if you thought that a PoC is a great learning tool, and should be used as such. (Well, I'll forgive you because this is what I thought at first.) You might have some of your own knowledge about a PoC and if you've read this far you might also be thinking that a PoC sounds like a great way to learn how to implement something you've been reading about.
Well, you're not entirely wrong, a PoC is about learning..but it's more about company learning that personal learning. Though, let's face it, the personal learning is a handy bonus! If you are looking to do some personal learning, it's probably not a PoC that you're making. Rather, you're probably making a demo or sample project. Equally valuable, but for personal learning and not really for direct business impact.
So, should I make a PoC?
Well, I think it depends on your team. If you're a junior in the team, your work might be guided by your line manager/seniors on the team. But, that's not to say that if you think that the team could get value from a PoC that you shouldn't suggest it!
Whether you should be suggesting one, and whether your team should be doing one I think comes back down to what a PoC is for. To help determine business feasibility of a new process/tool. But, there are other nuances that I'm sure I haven't covered. From my junior perspective, this is what I would start my thinking before suggesting or asking about a PoC and even when I am asked to do one. The goal in my mind stems from the ultimate goal of the PoC...
For instance, I'm making my first PoC for my team, because that's what my line manager asked me to do. At first I thought it was a dummy project to improve my own learning and show them that I could implement the theory. Through better understanding and conversation, I've come to understand that this isn't about me and my personal development. Rather the focus is on how I can input to the development of the team goals and it's a happy side point that I can consolidate my learning too.
What I have gained though, is more than technical knowledge, but also confidence. Confidence in my abilities, how I can contribute to the team and also my understanding of how my team thinks/works (and by extension this industry.) In the future, I'm hoping that I might be able to take some ownership of work and suggest a PoC that I can build that would add value. Without this opportunity, and the time to understand what a PoC is, I might not have...
