What Is Proof of Concept & How to Write One in 6 Steps

The results help project teams and stakeholders make informed decisions about whether to move forward with the project.

What Is the Purpose of a Proof of Concept?

The purpose of a proof of concept is to support long-term project success and identify issues early to minimizes risks for the full-scale implementation. It can also help reduce costs, as well as build stakeholder engagement and confidence because they got to see the idea work on a smaller scale before full sign off.

PoCs also allow for data collection and experimentation specific to the project initiative, letting you as the project manager learn about the project's strengths and weaknesses before investing in a large-scale project.

Pro Tip

If you are running a project or change that impacts a large group of people such as implementing a new process, a PoC can greatly help build awareness and champions within the target market for the new process while also pointing out issues prior to launching at larger-scale.

Proof of Concept Examples

Here are a few examples of proof of concepts at work in various disciplines.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

1. Software Engineering

Proof of concept is exceptionally common across STEM. In software engineering, proof of concepts are used to validate the need for new systems or services. New software startups often produce a pre-production version of their app to have a select population give it a try and provide feedback.

2. Pharmaceuticals

In pharmaceutical development, proof of concept processes are carried out through pilot studies, and various levels of clinical drug trials. These processes give feedback to the drug creators which helps them to create a safer, more effective drug.

3. Process Change

One of my favorite examples of running a proof of concept on a process change was for a project I led at a large software company. We ramped up hiring in 2020 and 2021 and needed to completely change the way we executed onboarding.

Instead of overhauling everything at once, we created a small team to define and build a new process that was used on a few specific new hires (the proof of concept). What we learned was so incredibly valuable that we were able to shift the way we were thinking about the process entirely, leading to a much better long-term outcome that was more sustainable, more automated, and produced a better result.

How to Write a Proof of Concept

When planning and executing a proof of concept, follow these steps:

1. Identify the Problem or Opportunity

The first step in planning a proof of concept is identifying what it is that you want to try or test. Build the beginnings of a project plan, including scope, schedule, and cost.

When getting started, I like to go for a full-on project charter or overview document to share with anyone that will be related to or working on the project and PoC. Remember, just because a PoC is smaller than a full-scale implementation doesn’t mean people don’t need thorough communication about it.

2. Define Success Criteria for the PoC

Once you have the problem to solve and you have an approach you want to test, define success criteria for the PoC. Defining success criteria will help everyone understand what you are trying to achieve and when.

Success criteria can be both experiential and outcome-focused. For example, your success criteria could include identifying if a new process can work on a small scale, or it might involve gathering five key takeaways from the experience to inform the next steps in project development.

3. Build a Plan for Implementing and Executing the PoC

Next, it’s time to build a plan that reflects the opportunity you are trying to test and that works toward the success criteria.

The plan for implementation and execution must be time-boxed, and must either be a representative sample or test for what could be implemented at larger scale to address the problem or opportunity.

Pro Tip

Be as specific as you can and over-communicate While a PoC might seem like a small step on the way to project delivery, successful completion of the PoC is often a critical milestone to gaining full approval and funding to move forward with the full project or implementation.

4. Determine Required Resources

Once your plan is defined, gather the required resources. Work with your core project team members to figure out who needs to be involved, then work with the various resource managers, development teams, and others within your organization to gain approval for folks to be involved.

I've also found that it is easier to get commitment from managers across an organization when the ask is time-bound and specific.

5. Run the Experiment and Gather Feedback

Next, run the experiment. Remember, this is a test, so anything you observe, correct, nudge, or support along the way should be noted in a lessons learned template so that you have as much data as possible to apply to the full implementation.

When the PoC ends, celebrate the involvement of all resources and teams as you collect user feedback and lessons learned to be incorporated into your results and project plan for full-scale implementation.

6. Share Your Results

Once your PoC has concluded and feedback is gathered and organized, it’s time to share the results of your PoC experiment with project stakeholders, sponsors, and interested parties. Communicate both on paper and in meetings to make sure your information reaches those that need it in ways that will maximize their understanding.

Share the problem you tried to address, how you went about it, what resources you engaged, the success criteria for the experiment, how the experiment went, and what lessons learned you gathered.

When to Use a Proof of Concept

Use a proof of concept when project success depends on an idea, technology, or approach that hasn't been validated. It helps you test feasibility, identify potential obstacles, and make informed decisions before committing significant resources.

I'd recommend using a proof of concept:

• When introducing new or unfamiliar technology: If your project involves technology your team hasn't worked with before, use a PoC to verify its capabilities. For example, test whether an AI tool can accurately process your company's documents before committing to a full implementation.
• When technical feasibility is uncertain: A PoC helps you determine whether a proposed solution can meet specific technical requirements. This is particularly useful when you're dealing with complex functionality, performance constraints, or unproven approaches.
• When integrating multiple systems: If your project requires different software platforms to exchange data or work together, test the integration before development begins. You'll uncover compatibility issues, API limitations, and data transfer problems that could derail your timeline.
• When project risks are high: Projects with significant financial, operational, or technical risks benefit from early feasibility testing. A PoC lets you investigate your biggest uncertainties before those risks turn into expensive problems.
• When evaluating competing solutions: If your team is considering multiple technical approaches, use a PoC to compare feasibility against the same requirements. This gives you evidence to support your recommendation rather than relying on vendor claims or assumptions.
• When stakeholder approval depends on feasibility: If sponsors are hesitant to approve funding for an unproven concept, a PoC can demonstrate whether the proposed approach works. Define measurable success criteria beforehand so stakeholders have objective evidence to inform their decision.
• When project requirements push existing capabilities: If your project involves unusually complex calculations or demanding performance requirements (or other unfamiliar conditions), test whether the proposed solution can handle them. This helps identify technical limitations before finalizing your scope and estimates.
• When scaling an existing solution: A solution that works for one department won't necessarily support an entire organization. Use a PoC to test specific scaling assumptions, such as whether the architecture can handle increased workloads or larger datasets.

My Advice

Don’t run a PoC just because a project is large or expensive. Focus on whether there’s a meaningful feasibility question that needs answering. If the approach is already proven and your main uncertainty concerns user adoption or business value, a pilot project may be more appropriate.

PoC vs. Proof of Value vs. Prototype vs. Minimum Viable Product

A proof of concept, proof of value (PoV), prototype, and minimum viable product (MVP) all help you validate a project idea before committing to full development. However, each serves a different purpose and answers a different question.

A PoC tests whether an idea is technically feasible, while a PoV measures whether the proposed solution delivers meaningful business value. A prototype demonstrates how a solution might look or function, while an MVP delivers a working version with enough features to test with real users.

Here's how they compare:

Aspect	Proof of Concept	Proof of Value	Prototype	Minimum Viable Product
Main question	Does it work?	Does it deliver value? If so, how much?	What could it look like or how could it work?	Will users adopt and benefit from it?
Primary purpose	Validate technical feasibility	Demonstrate measurable business value	Explore and test design or functionality	Validate user needs and product assumptions
What it tests	Technical assumptions, capabilities, and constraints	Business outcomes, ROI, and operational improvements	Design concepts, usability, and user interactions	Core functionality, user adoption, and market demand
Typical output	Small-scale technical demonstration or experiment	Test results with measurable business outcomes	Wireframe, mockup, or interactive model	Functional product with essential features
Intended audience	Technical teams, project sponsors, and decision-makers	Business stakeholders, executives, and project sponsors	Designers, developers, and potential users	Early adopters and real users
Level of functionality	Limited to what needs technical validation	Enough functionality to measure the intended benefits	Can be nonfunctional, partially functional, or interactive	Functional and usable for its intended purpose
When to use it	When technical feasibility is uncertain	When you need evidence of business value to justify investment	When you need to validate design or usability before development	When you're ready to test a working solution with real users
Success criteria	Technical requirements met and feasibility demonstrated	Measurable benefits achieved against predefined targets	Design assumptions validated through feedback	User engagement, adoption, and validated product assumptions

Getting Started on Your PoC

As you get started planning your proof of concept, don’t forget to stick to the project management basics of planning, communication, documentation, and collaboration. Project management software can help keep those pieces organized as the PoC moves forward.

Many of the principles of full-scale project management apply to a PoC, just at a smaller scale and hopefully in a shorter time.