Don’t confuse your POC with a real MVP or else you may end up SOL with a POS

Do I have your attention?

I was at an all-hands meeting for work. One of the presentations was a review of a successful project that encouraged employee participation and hopefully taught them something along the way. During the presentation the product owner noted that the project was a Proof Of Concept, testing several things about effectiveness, engagement, etc. In the Q&A part of the presentation after the applause, they were asked what other training they could use the tool for. The Product Owner made an offhand remark that it was not really ready for full production, but was really just a Minimum Viable Product.

It made me think. I’m not worried about the enterprise readiness of that project’s work because I know that team and they are on it, but I fear many program managers believe that a Proof of Concept (POC) is the same as a Minimum Viable Product (MVP). I’d be willing to bet that a lot of program managers and teams who believe this are in or are heading for a world of pain.

Why? If the POC is good enough to use for a service being used by thousands of employees, shouldn’t that be considered functional enough to be counted as a viable first release, AKA an MVP of the first iteration of the system? Well, it depends.

There are several things that must be delivered in an enterprise-ready service in order to be truly enterprise ready, and none of them are usually noted in the backlog of a POC. Proving a concept can involve simply showing that a thing can be done with existing tech. It could also be proving a concept about something else, like culture shifting, and that the system implemented was not the thing being proven, but just supports the ability to test it.

A technical POC should rarely, if ever ever be let loose in production. It’s usually because the developer(s) put all their focus on delivering a thing that does something that nobody was sure it could do. They don’t adhere to useful and important unwritten requirements, like usability, data management, legal, licensing, security, or privacy. That’s not the point of these kinds of POCs. If you want it to go into prod because the tech works, then rewrite the whole thing with all the requirements, including the ones below.

If the business owner of the POC says something like, let’s release it now anyways, they’re forgetting that they’re POC immediately violates tons of IT policies, which are there to keep the business running smoothly, and non-compliant systems will start causing serious problems, AKA disasters. The whole company will pay for people to spend a lot of time, resources, and money fixing it. Everyone ends up being Sh-t Out of Luck with a Piece Of Sh-t that stinks up everyone’s performance reviews.

A Minimum Viable Product should be defined not just by its business or technical features but also with the features that make it possible to manage the system in your environment. That means that you have stakeholders that aren’t paying for the work but who’s own workloads are going to be impacted by this new system. For example there are a raft of enterprise security and data protection features that must be built into that first release. Your lawyers are always overworked, so you should also resolve all your legal requirements and licensing before release too.

Just as a tiny example; if your company has invested in an expensive identity management platform that provides authentication, authorization, and auditing, then that POC about to go into production had better have started out using that identity platform’s services from the start. It needs to be in the first demo, period. Don’t even think of writing it without login security. Just . don’t.

I’ve seen POCs go directly into production and I’ve watched the clown show that ensued when one of those typically unstated requirements is missing. Exposure to employee data, unauthorized transactions, running on rogue hardware or cloud instances, etc. To fix these after the fact takes productive people offline to fix the problems, not to mention the possible losses of money, reputation, valuable employees, etc.

So when I say “don’t confuse your Proof Of Concept with a real Minimum Viable Product or else you may end up Sh-t Out of Luck with a Piece Of Sh-t” I’m saying that a true MVP is not one unless it explicitly handles all of your company’s policies as well as common sense performance, security, and data privacy functionality. These requirements may not fulfill the problem at hand, but they’d better fulfill the standing orders your company has for making that service fit in efficiently and safely.