Making your Idea Happen with a Proof of Concept (in software development)

Disclaimer: This blog post was written by a human, with no AI-generated text

Have you ever considered the concept of the proof of concept? I bet you’ve been asked more than once in your career to prove something works before committing fully. It could have been anything - a change in UI, a performance optimization, or a new feature. The underlying contract is that if you prove the concept works, you’ll get the resources to develop the new thing. At least in theory.

So let’s assume you’re an engineer with an idea. An idea that will make a whole lot of good, at least in your opinion. You probably approached your manager or another stakeholder with the idea, which led to some discussions, and eventually, you were asked to make a POC. That’s a good first step, you must have done something right because the idea wasn’t dismissed right away. So now, how should you approach that POC? What’s important and what’s not? Is there some politics involved in the matter? What are your managers and stakeholders looking for to make your idea a reality? Here are a bunch of tips and points I suggest following.

Identify the concerns and doubts

Consider why you’re tasked with a POC in the first place. It means an idea has merit, you’ve convinced someone it might be good, but you didn’t convince them fully. Why not? What’s there to prove? Depending on the context, they might be worried about high development costs, concerned about specific technologies, or uneasy about you, specifically, leading that project. If you identify those concerns, you’ll know what to focus on in the POC to alleviate them.

Admittedly, there’s a chance you’ll be asked to do a POC for a doomed idea. Something that will appease you, or fulfill some curiosity, but has no real chance to be approved. Let’s just ignore that possibility for now.

Prove that the idea is easy to implement

One of the main concerns in software is high development and maintenance costs. Developers aren’t cheap, you know. The best way to convince the implementation is easy and maintainable is by making the POC quickly and as fully featured as possible. Nothing impresses more than seeing a working solution.

Remember that this is a demo. It doesn’t matter how ugly the product is under the hood. It also doesn’t matter if it’s fully functional, just that you can show it works from a specific angle at sunset for two seconds. In demo rules, same as with hackathon rules, you can make all the shortcuts, hacks, and workarounds you want. You’ll also want to invest as much time as possible on the POC within the allocated time. Nobody takes into account how busy you were doing other things. They’ll think that what you showed them was achieved in the entire given time and make their conclusions.

Prove that the idea will be good for users

It’s always good to highlight advantages for the users. Even if they are minor and can be achieved in other ways, for the sake of the argument, it’s still one more justification for your idea to be developed. This advantage might be a better user experience, faster performance, or new functionality. In case of a new feature, it will be great to back up your claims with hard facts, like showing the amount of user feedback requesting this.

Prove that the idea will be good for the business

Even if you just want to work with some new tech, your stakeholders probably care very much about the business. Think of a justification that makes it beneficial to the bottom line. The benefit can come in different ways. You might lessen the cost of goods sold (COGS), like cloud costs and license fees, or your new feature might improve the user experience, which will bring in more customers. Or you can argue that the idea minimizes development times. There’s always something.

Prove that the idea will be performant

Performance is usually the first thing engineers are concerned about. If you convince the performance is good, you’ll have the engineers in your corner. This includes execution times, memory usage, storage, network, etc.

To prove you’re right, I suggest using a known performance framework, like BenchmarkDotNet for .NET, or PageSpeed Insights if you’re making a web page, or your favorite profiler. Whatever you use, show hard numbers and a nice Excel chart. There’s nothing that talks to an engineer’s heart like a good chart.

Prove that the idea is better than the alternatives

To make your point, you have to address alternative solutions. Even if your solution is better than doing nothing, it doesn’t mean that a different implementation won’t be even better. But how can you really prove yours is better without making a POC for every alternative method? I’ll argue that you don’t need to prove that your method is better, just that it’s not much worse, and you don’t need a POC for that. The concern is usually that you’re not missing something big. For example, if you chose to use MongoDB instead of RavenDB , and RavenDB was slightly better in the latest benchmarks, that’s not the type of concern stakeholders have. On the other hand, if you chose to use an expensive Oracle database instead of a cheap storage solution, that’s a problem.

To alleviate stakeholder concerns about alternatives, you just need to list those alternative solutions, explain that you considered them, and why yours is going to be better. Or at least not worse. Management wants to hear you’re not running blindly into your first idea.

Another approach is to make the point that you don’t know what’s the best solution yet. You’re considering A, B, and C and you’ll make an educated decision as you learn more. It’s perfectly valid not to have all the answers in advance. It even instills confidence that you’re being thorough and responsible.

Make a good presentation

Instead of sending an email or having a hallway conversation, I suggest setting up an official meeting where you’ll present the idea. With a PowerPoint deck and everything. The reason is that a proper presentation sends a message. It says this is a serious proposal and that you’re invested in it.

Advising about good presentations is far from my specialty, but I do think it’s an important skill to have. I personally find it helpful to practice a presentation, before giving it, at least once in front of an empty room. This helps me relax and be in the moment instead of concentrating on what I’m going to say next.

Be fair

A POC exists to prove a concept that may be wrong. You might discover along the way that your idea isn’t that great or that other solutions are better. I’m hoping everyone behaves with integrity in these cases and presents fair results, even though it’s entirely too easy to change some numbers or run a biased test. The worse thing that can happen is that you’ll get caught cheating, which will hurt your reputation for a long time.

Be ready to accept either outcome

Sometimes, a proof of concept is done just as a failsafe, in a project that’s already approved. Other times, it’s an elaborate pitch for a new idea, one that wasn’t planned for. In the case of the latter, the chance of success is relatively small. For a POC to move to the next stage of development, you’ll need to convince a lot of smart people with an idea that they haven’t thought of themselves. This is likely not to work even if you did everything right. I certainly had it both ways. But usually, if you’ve done good work, you’d have impressed a bunch of people and learned something interesting.