As a product manager, or simply as someone involved in the product development process, you’ll naturally want to create a great product that works.
But successful products aren’t just those that meet your organization’s strategic goals. They also need to be well-designed, intuitive to use, and meet the needs of your customers.
All this is why, before diving into full product development, product managers often use what’s known as a proof of concept.
A proof of concept (POC) has multiple uses. For starters, it shows investors, executives, and other stakeholders why the product is worth pursuing. And from a project management perspective, it also allows you to test a product’s feasibility before committing time and resources to its full development.
In this article, we’ll explore what a proof of concept is, what it’s used for, and how to create one. We’ll cover:
- What is a proof of concept?
- Advantages of a proof of concept
- What’s the difference between a proof of concept and a prototype?
- What’s the difference between a proof of concept and an MVP?
- How to write a proof of concept: Step-by-step guide
Ready to supercharge your next POC? Then let’s dive in.
1. What is a proof of concept?
In product management, a proof of concept (commonly referred to as a POC) is a demonstration—usually code-based—proving that a product can be successfully implemented.
A key step in the product development lifecycle, it occurs early in the process, before significant resources have been committed to product development. Typically, we use a POC to show that a proposed solution is practically feasible and to try and gauge its potential impact.
Because the proof of concept is only a test, it usually differs from the eventual end product. And since most projects also include a prototype stage, some may believe POCs are unnecessary. However, testing a product’s mechanics early on can offer much insight, saving you pain and cost overruns later on.
While it can take numerous forms, in product development, POCs are usually similar to a small-scale prototype or simulation.
It’s important to emphasize that a proof of concept is not the same thing as a working product.
Rather, it’s a way of testing if an idea is worth pursuing. Not all POCs will become products. But the best products will start as a solid POC.
2. Advantages of a proof of concept
POCs are not limited to product management—they’re used for everything from devising project management methodologies to business tasks. However, they’re perhaps most commonly used in software product development.
Unfortunately, when time and budgets are tight, the proof of concept stage is often an area where product managers cut corners. This is because POCs don’t take up a lot of time, which makes it easy to presume they’re dispensable. However, that’s far from the case.
There are several advantages of employing them. Four of the most important ones are that they help to:
- Reduce risk
- Reduce development costs
- Ensure better products
- Attract investment and stakeholder buy-in
Let’s take a look at each of those advantages briefly:
Reduce risk
By its very definition, the purpose of a proof of concept is to test and determine whether an idea can work in practice.
If the answer is no, you’ll have saved yourself a lot of time, effort, and money that otherwise would have been wasted by jumping right into development.
Reduce development costs
Even if the answer is yes—it’s successful—you’ll still have done yourself a favor, saving money that you would have otherwise spent doing costly development work upfront.
A failed POC helps product managers avoid the cost of building software products that will never be used, while successful ones can refine a product’s design.
Ensure better products
A successful proof of concept will give you confidence in your product idea.
It’ll allow you to validate any assumptions and ensure that the product is fit for purpose. Does it meet your strategic objectives as well as customer needs?
If you need to make changes, the POC may not highlight everything you will bring to fruition in the final product, but it’ll likely help you to spot major issues that need fixing early on.
Attract investment and stakeholder buy-in
You can also use a successful proof of concept to attract investment and buy-in from stakeholders.
Demonstrating its viability will assure stakeholders that the product has a high chance of success. Using a POC for this purpose is especially important for start-ups, which often have to pitch their ideas to potential investor partners.
3. What’s the difference between a proof of concept and a prototype?
So far, there might not seem to be a big difference between a POC and a prototype. And while they do share some similarities, they’re quite distinct.
The key difference is that while a POC demonstrates a solution’s feasibility, a prototype is a working model of the end solution. And, since prototypes build on the data collected from a POC, it’ll be a more polished version of the end product.
If you’re not sure how to tell the difference between a POC and a prototype, here are some key features to look out for:
If you’d like to see how a prototype differs from other similar design terms, check out our guide to prototypes vs wireframes vs mockups.
4. What’s the difference between a proof of concept and an MVP?
If you’ve been anywhere near a product development lifecycle, you’ll also have come across what’s known as a minimum viable product, or MVP.
Again, while an MVP shares similarities with both POCs and prototypes, it has some distinguishing features of its own.
In the same way that a prototype builds on a proof of concept, an MVP builds on a prototype. Essentially, it’s a working version of the product that has just enough features and functionality to meet a customer’s demands.
It’s then used to obtain feedback from end users, helping inform product development over time.
Once again, if you aren’t certain how to distinguish between a POC and an MVP, look out for the following differences:
5. How to write a proof of concept: Step-by-step guide
One thing is for sure—these are a vital aspect of the product development cycle. As an essential pilot of your product, you should give it the appropriate level of attention.
Here are the main steps for writing a POC:
1. Identify the problem you are aiming to solve
Bring together key team members, including stakeholders, to identify the problem you want to solve.
Identifying the problem often begins with market research to determine your target audience’s habits, needs, and desires. Based on this information, you can then create a typical user persona and better understand their needs.
Alternatively, if you’re creating the product for a client, they may already have identified the problem. For instance, perhaps your client is a supermarket chain consistently struggling with long self-checkout queues in their stores.
Whatever the problem, once you’ve identified it, you can conduct research into other products on the market before devising your own solution.
2. Describe your solution
Next, outline your proposed solution to the problem. The product might be an app, a platform, or some other type of software.
You should draw a potential solution from insights from the wider team or the client. For instance, if you’re trying to solve the problem of the long self-checkout queues described in step one, perhaps you need to redesign the client’s software.
Your proposed solution should include an estimated product development timeline and the resources you expect to need to achieve this goal.
3. Explain why your solution will be effective
Naturally, there’s no point in creating a POC without explaining how it will benefit the client and end user.
Rather than simply saying: “we will redesign your checkout software” be specific and explain exactly how you will do this and why.
For instance, maybe you need to create new software that eliminates the need for staff members to approve certain purchases, thereby reducing queuing time. Your POC therefore will test this new functionality.
The solution doesn’t need to be complex or over-engineered, but it does need to be very clear.
4. Outline the scope of work
Next, outline the scope of work for the proof of concept. The scope of work is where your initial discussions with the team will come in handy.
Outline what will be involved in creating the POC, the human input and skills required, whether or not you can achieve it alone, or if third-party involvement is needed.
The scope of work is also the place to determine a technical solution, success metrics, and how you will track these. For instance, can you pilot your POC using the client’s existing test environment? Or will you need to devise something from scratch?
Another consideration is the features you want to test. Often, a proof of concept will focus on just one or two core features rather than the entire product concept.
For instance, if the client is generally happy with their checkout software and simply wants to make some tweaks, you don’t need to reproduce the whole product: just the aspects that might need updating.
Keep in mind: While not all of these things may seem vital to proof of concept planning, they’ll be important further down the line. Whether or not you decide to pursue the POC in its current format is almost irrelevant. All this information will inform your product, whether you stick with your current plan or change track completely.
5. Build the proof of concept and test
Finally, select a platform on which to build your POC. Hopefully, this is already in the scope of work. It might be a client test environment or another software solution.
You’ll then need to build your POC. Remember: This is not a working product. It’s not even a prototype. You’re just testing the feasibility of the concept, so you may need to keep an eye on the development team to ensure they are not spending more time on it than they need to.
Once your proof of concept is up and running, you should test it with “users”. These users will likely not be the end users, but colleagues working outside the development team.
It doesn’t matter that they aren’t your target audience. The main thing is that they can offer a sense check and ensure the POC meets its core objectives.
If feedback suggests that it hasn’t met its aims, this may be the point where you abandon a proof of concept and return to Step 2.
6. Report your findings
Last but not least, report your findings. Even if you had great feedback from your test users, this is where you need to analyze your key performance indicators to ensure the proof of concept did the job it set out to do.
You’ll also need to report on preliminary lessons learned and, if appropriate, your recommendations.
The reporting stage can vary—you may need to present the POC directly to clients, to internal stakeholders, or it might be sufficient to write a report of your findings for the executive team to read.
The main thing is to document everything you can and be open and impartial about the proof of concept’s degree of success or failure.
If the proof of concept is successful, you’ll need to take your findings and use them to inform your product roadmap. This might mean changing strategy or continuing with your plan.
If it’s unsuccessful, you’ll need to analyze your findings to understand why that’s the case. This will help you decide whether or not to continue with the project. If it’s a failure, or the stakeholders reject it, that’s okay—that’s exactly why you conducted the POC in the first place.
Now, aren’t you glad you tested it before diving headfirst into development?
6. Next steps
So there we have it! Everything you need to get started with a proof of concept. Grasping what they are is key if you’re looking to become a product manager.
In this article, we’ve explored what a POC is, why it’s important, and how it compares to a prototype and a minimum-viable product. We’ve also outlined the steps you’ll need to take to create and test one, and to report your findings.
As we’ve learned, a POC is a great way to test the feasibility of an idea before committing time and resources to it.
By following the steps outlined here, you can be sure that your POC is well-designed and informative and that it will give you the insights you need to make informed decisions about your product.
If you enjoyed this blog post and want to kickstart your career as a product manager, why not sign up for this free Product Management for Beginners course?
Alternatively, check out the following articles to learn more: