Proof of Concepts

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

With so much at stake — in terms of time, resources, cost, and the quality of your software product — taking the time to properly plan software development and the end product before the actual launch is more important than ever. A Proof of Concept, or PoC, is a great place to start. But what is a POC, and why should you create one?

PoC vs. Prototype

Think of a PoC as a type of a small test prior to the project to test the idea, which shows that a product concept is both functional and can be developed.

Creating prototypes helps the development team visualize how a product will function. It’s a working model of the end product. It shows the design, navigation, layout, etc. To clearly state the difference, a PoC shows that a product can be made, while a prototype shows how it’s made. A PoC shares knowledge with the team, allows them to investigate emerging technologies, and of course, shows the stakeholders that the concept works.
Once the PoC convinces everyone that the project is viable, a prototype is developed as a selling point for the client. So while they’re different, a PoC and a prototype are not mutually exclusive.

The Value of a PoC

An effective PoC helps a project manager identify gaps in processes that might interfere with success. A PoC also elicits feedback from everyone involved in the project. It can help to find the weaknesses of the product and to understand if and how your idea is relevant.

The proof of concept is so important because it’s a test project to evaluate before work begins on an actual project. A PoC verifies that the theoretical concepts applied to a project will have real-world applications. A proof of concept in software development explains how the project should work based on a detailed description of requirements and specifications. The PoC, ideally, is a complete satisfaction of those functions that need to be realized. PoCs do not produce deliverables but check the feasibility of software being considered for development.

Use cases for proof of concept development
When there is a need to check the value of software product idea
To ensure that the chosen method of software development is efficient
To determine whether the proposed software product idea matches the needs of the intended users
To find out the limitations of the software for a specific problem and demonstrate its functionality

Making a Proof of Concept

The process of creating a PoC in software development has some essential steps, which can be modified depending on the type of software or PoC being created.

1. Plan the effort
When you’re building a software proof of concept, remember that while it is an important project, it is not the final project. So plan the invested time, effort, and resources accordingly. A typical software PoC should not take more than two weeks to complete and a team of two-three developers to work on it. There are also several third-party tools available today that can be used to create a proof of concept in a matter of a few days.
2. Scope of the project
Even if the proof of concept proves to be viable, that proof is worthless if the scope is not correct or is missing the end objective. So it’s important to keep the scope of the software PoC focused on resolving the specific problem(s). Keeping too wide a scope will become counter-productive.
3. Pick Your Resources
Make sure you pick a team with the right skills to make a proof of concept because you will be checking the long-term viability of an idea, of a vision. So you need a project manager with the perfect mix of business and technical experience, as well as developers who can quickly translate an idea into a more tangible product.
4. Select the right metrics
To have accurate feasibility measurements, you need a clear set of project metrics that will collect the project’s most pertinent information and determine its success or failure. The best way to go about doing this is to interview the client using targeted questions that lead the project to the intended objective.
5. Gather feedback from intended users
Once you have a ready document with a description of the software and the functions it should perform, the next step is to get feedback from users, or if you’re so lucky, the actual customers. The proof of concept is not a product demo, but you need an environment similar to the one you expect to have at full implementation.
This doesn’t mean it needs to be a full-scale environment, but it should function in the same way. Offer users your product as a solution to a specific problem and explain how it’s meant to work. Be open to the feedback and suggestions you receive, as these will go a long way in helping you improve the final software product. Be prepared that some of your guesswork will be broken.
6. Course correction
Now your proof of concept for software development is ready to be finalized. You’ve received user/ customer feedback, and have a better picture of how users will interact with your project. It is necessary to understand that this is a preliminary evaluation of the software proof of concept and that some of the suggestions received will be insightful. In contrast, others may not have actual value. Thus, based on the information received, it is necessary to consider what can be changed to make the project more convenient. If the feedback you received was largely and strongly negative, then it might be a good idea to stop the proof of concept development process. Or at least pause it until you can come up with a new, improved version.

Final Thoughts
the truth is that the more experienced a software professional or software development company is, the more likely they will be interested in the proof of concept. Once the initial pilot is ready, it should be able to confirm the success of the new software product to lay the way for an official rollout. A software development proof of concept helps prove a concept not only for the development team but also for customers.

1. Identify specific business cases and expectations for the new technology
Going into any POC, it is always advisable to have specific business cases and expected outcomes from the technology identified and agreed to between IT and end users. Identifying your business cases and results expectations upfront assists your POC team in focusing on the important elements of the project. It is also invaluable for your vendor, who can verify that the product can do what you want it to do and also assist in product configuration and testing.
2. Know your current performance baselines
If you are performing a POC on a system that you hope will improve your warehouse operations workflows by 50%, it is imperative that you know your present workflow timings in the warehouse so you have something to benchmark against. IT and end users (in this example, in the warehouse) should carefully figure out the current workflow timings of the warehouse so the new product or system can be benchmarked against them.
3. Set your performance goals
It's important to set your return on investment (ROI) and key performance indicator (KPI) goals in advance of any POC. Once you've identified the baseline of current performance and costs (see step 2), you should be able to set goals for improvement over present performance that will deliver a positive investment return to you by way of reduced costs or improved revenues.
4. Run your POC project
Coordinating with your vendor, the next step is to run the POC project itself. From the point of configuring the project solution to concluding the POC pilot, a reasonable POC timeline should not exceed three months. During this time, it's critical to note any challenges and/or problems that came up during the project and to identify the solutions to these problems.
5. Track your metrics
Once the POC is complete, you're in a position to compare the KPIs that you've achieved for the POC to the current KPIs that you're getting from your existing systems. Your vendor can assist you in setting up an appropriate way to measure for projected ROI—with the caveat that you and your staff should take ultimate charge of the ROI measurement formulas to avoid any favorable skews that the vendor might have built into its ROI formula that favor its solution.
6. Present the results to project stakeholders
Some POCs succeed and some don't. The beauty of a POC is that you haven't committed to anything except the test of a vendor solution. If the POC comes out favorably, you should be prepared to present the POC methodology, the business goals achieved, the ROI, and the KPIs, along with a recommendation for implementation into production. If the POC fails, you should conduct a project "post mortem" to determine what went wrong and then present a summary to management. In both cases, you achieve closure for the POC project.
7. Set your investment levels
If your POC is successful, and management is on board after your presentation, it's time to scope out the project implementation into production and determine a budget. Your vendor can provide costs for its solution, but it's equally important to get finance involved, as it can produce true costs of ownership and assist you in preparing for price negotiations with the vendor. 
8. Transition the POC to the active projects list
Once you've chosen your solution and obtained budget approval, it's time to move your POC to the active projects list and set a timeframe for implementation.

https://designli.co/blog/5-steps-proof-concept-successful-software-development/
Step 1: Prove the Need
It only makes sense to put time and money into building a product if people really need it. Maybe those people are the company’s employees, who need to improve their productivity. Maybe they’re a new market the company isn’t currently serving but could easily reach. Whoever they are, you need to know that your software will meet their needs.
Before you begin building the software, you’ll want to be crystal clear on the pain points your target audience is experiencing. You don’t want to guess what these issues are or assume you know without actually talking to a representative sample of people in the group.
You don’t have to talk to hundreds of people at this point — just enough that you start hearing the same concerns repeated. As you interview potential users and stakeholders, be sure to ask about the implications of each pain point. You’ll want to learn both the business impact and the personal impact of each one in order to create a prioritized list. Eventually, you’ll see patterns and common threads emerging. You may be surprised at what you don’t hear in these interviews as well. By the end of this step, you’ll have a list of specific needs and goals that the software should solve.
Step 2: Map Pain Points to Solutions and Get Feedback
This step involves brainstorming ways to solve each of the pain points you identified in the first step. There will likely be several ways to solve each issue. After your brainstorm, you’ll evaluate each possible solution to determine how it stacks up in reference to cost, competition, timeline, technology challenges, etc. When this process is completed, you should have a clearer idea of which solutions to include in the final product.
Once you have this list of solutions, go back to the users and stakeholders you initially interviewed and learn their reactions and responses to the recommended solutions. Describe how you envision the product working, and ask for their feedback. This input will provide you with valuable insight as you move forward.
Step 3: Prototype Your Solution and Test
Your next step is to create a prototype that wraps your solutions into a rudimentary product that you can use to test with those you interviewed previously. This prototype should have the expected feature set and UI/UX.
Once the prototype is built, test it with your interviewees for additional feedback. Record their use of the product to track how intuitive the interface really is, and find out if you overlooked any important functionality.
Step 4: Create a Minimum Viable Product
An MVP is different from a prototype in that it’s a fully-functional solution that you can put out into the world for use. While it will include only the most-important features that are essential for solving the primary pain points you identified, it should function on the user’s side just like the final product.
The MVP gives you the ability to test the product beyond your small group of interviewees, to a wider group that’s more representative of your market or audience. It offers an opportunity for more feedback that will tell you if the product in its current iteration resonates with users and stakeholders.
Step 5: Design a Roadmap
From all of the information you’ve gathered in each of the previous steps, create a roadmap that describes what you’ve learned and outlines a recommended step-by-step process for building the product. Think of this roadmap as a set of blueprints for constructing a building. With this roadmap as a guide, everyone will be kept on the same page through product development and will have a clear picture of what the end goal is.

An effective proof of concept (POC) bridges the gap between expectations and reality. For developers of data migration software, it is not only the best way of illustrating features, functions and benefits, but also ensures that the end product matches the client’s expectations.
In this guide to creating a proof of concept for migration software, we’ll explain how to keep the client in focus and add some tips on successful preparation too. You may also be interested in: an example of a successful proof of concept.
Explore why the customer needs the software
Carefully scope the client company’s requirements for the final product. Ensure that the scope is accompanied by a clearly defined way of measuring success.
Also explore the business reason behind the customer’s need for the software, and clarify how the product will assist in overall business improvement. A full view of the business’s needs helps to identify any extra requirements necessary to ensure a successful migration. In addition, assess the customer’s systems to understand the impact on them of the final product.

Understand exactly what the customer is looking for
Clarify all the outstanding questions that the customer expects the POC to answer or demonstrate. Some of these will be direct, such as:
• How long will it take to implement the software?
• How will the product be structured?
• What will the interface be like?
• How much will the product cost?
• How will it be deployed within our architecture?
Also prepare for questions which are indirect and wider in scope, which may include:
• How will it fit with our current products?
• How will it fit with our current processes?
• Do our users believe in the product and are they enthused by what they see?
• How easy is the product to use?
Assess where the proof of concept will be deployed
The customer’s data stores and offices may be dispersed around the world. For each location, consider how the product will be deployed on the site’s servers.
Establish when the customer requires the proof of concept
Ensure all deadlines are clearly listed in advance to allow suitable time for follow-up actions.
Consider whether the execution of the POC should be restricted to particular times or days. Ensure that the windows for execution are fully communicated within the client company.
Clarify who the stakeholders are
It is usual for a wide range of stakeholders to have an interest in a POC. It is the first impression the customer will have of the end product, and first impressions last. Often, more people are exposed to the product in the short timeframe of the POC than will have exposure to it for a good while afterwards.
Typical stakeholders include mangers, architects, security experts and users. A successful early introduction to the project’s stakeholders will encourage decision-makers to give go-ahead quickly and cost effectively. This means that it is crucial to understand the requirements and expectations of all these groups.
Prepare for the practicalities
There are many useful ways to ensure that the POC progresses without issues. In addition to being fully prepared from your own standpoint it is important, where possible, to ensure the customer has carried out any preparation that they are required to do.
A key item is availability and access to all the components required for the POC. From the customer you will need:
• Access to: buildings (if onsite); networks; datastores; live or sample data.
• Availability of key personnel such as domain experts and systems experts.
And from your own viewpoint:
• Ensure that any customised components are complete;
• Where possible, review sample data sets and data schemas;
• Confirm that success measurement criteria are clearly defined and agreed;
• Expect users to highlight particular issues they are experiencing;
• Ensure the POC shows what happens when things go wrong and how mishaps are handled.
A POC does not have to cost a great deal, but its thorough preparation is a crucial stage in the success of a data migration project.

1. Keep it simple
 
Remember that a proof of concept is a microcosm of a full implementation. Don’t go into your proof of concept trying to replicate or build your entire data warehouse. Or even part of it. Start small. 
 
How small is small? You want a project that you can easily implement and quantify with measurable results. Pick a sample data source, dimension, and fact that would illustrate a typical data flow. This type of use case will give you a good indication of how the product performs. For example, moving some Salesforce data from an on-premises warehouse to a cloud data warehouse and doing some simple transformations is a common proof of concept for Matillion ETL. 
 
2. Do your research and make a plan
 
First, research and make decisions about the considerations that will go into your proof of concept:
 
Resources: in-house and external, team members and stakeholders 
Your technical architecture
The product itself: cost model, installation, maintainability
Evaluation and defining success
 
Are the right people involved? Will the product support your use cases, work within your environment, and yield value? These are things that are good to know before you go, and they will all be instrumental in creating your project plan.
 
3. Get stakeholder buy-in
 
It’s hard to kick off a proof of concepts without getting buy-in from the appropriate stakeholders. It an important step, and putting together a proposal is also a great way to help you get some answers to some important overlying questions that often go beyond logistics:
 
What is the problem you’re trying to solve?
Why this product or solution?
What are the real benefits for the business? Better productivity or decision making? Cost? Present your case in those terms. 
 
Making a business case for a proof of concept is also a forcing function for outlining the scope and making a detailed project plan that shows you’re serious about staying on time and in budget. 
 
If you’re not sure how to put together a proposal, we’ve put together a deck template that you can fill in with your own information or use as inspiration. 
 
4. Get input from your stakeholders
 
If you’re struggling to select a project, think about your stakeholders. What data and insights are most important to them? What project stands to deliver the highest value? Ask them. And use their answers to help define the project that best combines simplicity and importance to the business. 
 
5. Choose the right team
 
A proof of concept is only as successful as the team running it. Make sure you have a blue-chip roster of external support. Choose vendors with an excellent track record of support. Pick partners who are experienced in implementing your solutions, whether you are migrating data to the cloud, transforming it, or setting up cloud data analytics. 
 
Keep these 5 key steps in mind, and you’ll be ready to take the first step on your way to a successful ETL proof of concept.

A better question these days is, why not do a proof of concept? In the past, PoC projects could take up a lot of time, a lot of resources, and still come up inconclusive. Today, thanks to the cloud, there are a lot of benefits to doing a PoC, and very little downside. Here are four reasons why doing a PoC with Matillion or any cloud-based product is a wise move.
 
1. It’s the best way to prove tangible value
 
As companies increasingly migrate to the cloud, and are contemplating products built for the cloud, a proof of concept can provide fast and accessible options to test out and prove value. Running a PoC delivers insights into how a product can fit into your organization and gives tangible evidence of gains in productivity, supportability, scalability, and cost reduction.
 
2. It’s a low-risk way to help ensure success
 
A Matillion proof of concept allows you to test your idea and arrive at the best version to save time and money. It can provide insight into the fastest and most direct route to success. A PoC provides something tangible that people can get excited about and creates a gravity to pull in new ideas. It can also provide an opportunity to investigate new skills and capabilities, and give insight into partner relationships and approaches to customer support.
 
3. With the cloud, it’s never been faster or easier to do a PoC
 
A new generation of cloud products (Matillion included), whether cloud-deployed in the infrastructure, PaaS, or SaaS, make it relatively easy to spin up a proof of concept and see results within a few weeks. Many products can be quickly downloaded from the cloud marketplace of your choice (In Matillion’s case, AWS Marketplace, Google Cloud Marketplace, or Microsoft Azure Marketplace). And many come with a free trial period, often letting you complete a proof of concept and incur very little cost – or no cost at all. Matillion ETL comes with a 14-day free trial on AWS and a 30-day free trial on Microsoft Azure, and you can go from launch to live with Matillion ETL in minutes. 
 
4. Help is there if you need it
 
During a PoC, your internal team will be a critical resource. But depending on which product you test, many cloud vendors have an extensive team of solution architects and account executives dedicated to helping you run a successful proof of concept. These vendors also work with a variety of top-notch integration partners to lend a hand as well. How much or little help you tap into is up to the needs of your organization, but it’s always there as a resource.
 
For example, Matillion has a dedicated solution architects and account teams committed to helping you plan and execute a successful proof of concept, including making a business case, choosing a use case, mapping out your project, successfully extracting, loading, and transforming your data in the cloud.

IoT

https://www.iotforall.com/proof-of-concept-for-iot
https://kynektyd.com/wp-content/uploads/2019/04/Maximizing-the-impact-of-your-IoT-PoC-WP-1.pdf

ETL

Planning an ETL Proof of Concept? Here Is What You Need to Consider
David Lipowitz
(whiteMocca/Shutterstock)
Picture this: You are trying to track the sentiment of your product using first-party customer data, social data, and social listening data to determine the success of a new feature. Getting a daily report on this can help your product team make better prioritization decisions, or your marketing team to craft better messaging around a feature that spurs product adoption. In your current reporting structure, this will take hours of manual work. To expedite the process, you can create a proof of concept (POC) of an extract, transform, and load (ETL) workflow using cloud-based tools that can consolidate and transform your data sources for near-instant reporting and analytics.
POCs are frameworks of tests that help a user determine if a product will function as envisioned, and if it will provide the long-term value that merits a full investment in the technology and resources. These tests should not attempt to build an entire solution; they should confirm or deny if an entire solution should be implemented. A POC is an implementation on a micro-scale, that can demonstrate that the larger project can be done.
The POC should take minimal time. If it works, it creates a starting point for the development project and helps lock in stakeholder buy-in. Specifically for data architects and engineers, an ETL proof of concept can prove the value that cloud-native data integration can bring to an organization, in a scalable and flexible way.
What does a successful ETL proof of concept look like? It’s fast. It’s relatively painless. It shows tangible value that merits a larger implementation. And with the right strategy, it can be done at low cost–or even no cost–to your organization.
Before you launch a POC, you need to identify your use case and give yourself a few guardrails to ensure you don’t burn cycles without proving value. There are several areas of focus where you will need to identify and align stakeholders, technologies, and processes. Before you create a formal project plan, here are some things you need to research and consider for your POC.
 Resources
Fill out your POC team with a cross-section of users who will use or benefit from the solution. Identify their part in the process and what their evaluation criteria will be. They should adopt an optimistic approach toward a successful outcome and not be constrained by a reluctance to change.
Take time to choose the right people for your ETL POC (pgraphis/Shutterstock)
An in-house POC team should include at least three personnas:
Decision Maker: The person who will ultimately make the yes-or-no decision on the technology and project once the POC is complete;
Technical Lead: The person who validates the integration and implementation of the product and leads the development of the PoC;
Business User: The person who can appropriately quantify the business benefits that feed into the success criteria.
Your vendor POC team should include an account executive who works to align the expectations for a successful adoption of the product and a technical resource. This person is the counterpart to the technical lead in-house, providing backup for the project in the form of product support and expertise.
Technical Architecture
When considering a product for the project, you need to ensure that it integrates with your target architecture and addresses any security concerns. For example, do you need to keep sensitive data within your private cloud, or is that less of a concern? Ultimately there will be a set of technical requirements that a product will need to adhere to if it is to meet an organization’s technical governance.
Costs, Installation, and Maintainability
Gain a firm grasp of an organization’s cost model. Are there additional costs as you scale, or can you scale the solution without financial penalty? Do you have control of the costs? Does the cost model offer the flexibility your enterprise needs in order to build the environments you need for your implementation?
Use the proof of concept to understand the options and speed of installation. But remember, you are not building a production system.
ETL implementations can be complex and tough to maintain
Maintenance can account for as much as 80% of the total cost of a solution. As data changes and business logic evolves, does the solution remain easy to maintain? Can you quantify any improvements in the amount of maintenance effort required, and compare them to existing processes?
Evaluation Framework
You need to ask yourself: why are we doing this and what are we trying to achieve? Ultimately a proof of concept should give you proof of value. Identifying where this value lies will provide a framework for how you want to define your success criteria. Cost savings are driven by:
Increased productivity: Does it speed up the development process? Is the interface easy to use and navigate?
Resource availability: Do you need specialists or is it simple and intuitive to use? Does it simplify the process? Does it support an industry standard language, like SQL?
Scalability: Do you need to have specialized configuration knowledge to scale the solution for future use? Are there cost penalties or gates that depend on usage? Does it leverage the benefits of the cloud computing approach to simple scaling and consumption-based pricing?
Maintainability: Can you develop data flows in a visual way? Are there built in retry mechanisms, monitoring, and alerting? Do you have control over data and alerting processes? Do you need specialized skills to maintain the product, or can it be done through a standard interface?
Use Cases
First, identify the pain points in the current process. Find a small number of typical use cases and keep it simple. Then, choose a wider variety of use cases, including those you’ve identified as particularly painful. Evaluate the technology’s ability to scale for larger projects and more complex projects when you are ready. This will provide a good indication of how the product performs.
Don’t try and replicate legacy implementations. Take advantage of the features and functionality, including best-practices, as directed by the vendor of the product you’re evaluating. This may not be an apples-to-apples comparison, and that’s a good thing. You have the opportunity to think about your existing challenges in a new way, and to redesign solutions for them accordingly.
Vendor Relationship
Evaluate vendor support. Are they willing to help you succeed? Do they value your feedback? Are they customer obsessed? Once you find answers to your questions in each area of consideration, you should be in a good spot to begin executing your proof of concept.
Overall, you’ll achieve the most benefit by keeping your POC simple and taking a measured and methodical approach. Avoid doing too much, too soon. This will help you and your team realize cost-savings, performance benefits, and pros and cons of the solution, at a comfortable pace.

Microservices

Imagine this scenario: you’re an early stage founder or sales leader. Every time a customer validates the need for your product, it feels like the best thing you’ve ever heard. Every customer you talk to that isn’t as excited about what you’re building feels like a crushing blow.

In this imaginary scenario, you’ve identified an early prospective customer, and managed to engage them in an evaluation of your product. This alone feels like a huge victory. Fast forward a bit and you’ve now run an endless series of discovery calls with decision makers. Your product impressed the people it needed to impress. You shared pricing and it seems to align with the buyer’s budget. Then, out of nowhere, you hear that dreaded question:

“Would it be ok if we ran a proof of concept first?”

As frustrating as it can be, it’s a fact of life: before your early customers feel comfortable buying, they may ask you for a proof of concept (we will also refer to this as a “POC” for short.) This doesn’t mean you have to grant it, but they will certainly ask.

It’s very easy (and may even feel natural) to excitedly agree to whatever your early customers ask for in order to sell your early key deals. Giving away a proof of concept too easily is one of the most time consuming (and thus, resource and money consuming) mistakes you can make as an early founder or sales leader.
First, what is a proof of concept, aka, “POC?”

It’s basically a trial of your product where a decision maker wants to confirm a certain checklist of items before they purchase.

Let’s start with the wrong way to run a proof of concept- the wrong way is simply saying “sure!” and deploying the product for your decision maker with maybe a quick walkthrough and demo, with a promise in place to reconnect in a month once the trial period ends.

This is not a good idea because, 9 time out of 10, your prospect will just forget about you, you’ll have wasted a month, and be in the same place you started. You need to make sure a prospect is dead serious about buying before you even think about granting a proof of concept.

A proof of concept must be extremely intentional in order to yield fruit. A proof of concept is a privilege for your customer (free usage of the product and a ton of time without any commitment to purchase) so before you, as a seller, agree to that proof of concept, you must establish some key ground rules. Let’s explore what those ground rules look like.

Proof of concept ground rules
First, you should view a proof of concept as a huge give on your end, and it’s your job (as a seller) to make sure that the customer views it the same way. Your team will be spending time, energy, and resources on giving this customer free access to the product and making sure they’re successful
The rules of POCs
First, your customer should understand that you only do POCs for customers who are [far] more likely to buy than not. The purpose of a proof of concept should be, very specifically

(a) the customer refuses to buy the product without trying the product first, and has a valid reason for needing to validate the way the product works

(b) the customer agrees that they expect to buy at the conclusion of the POC if all their success criteria are met. I can’t emphasize this point enough. Just like “coffee is for closers,” POCs are for legitimate, expected buyers, not people who are still on the fence.

Rule #1: You need to get full decision maker buy in BEFORE starting a POC.
You should never grant a POC to a champion without them having full decision maker buy in. Before giving a potential customer the “keys to the kingdom” you need some assurance that you’re working with the person who can sign the contract, or at the very least, this person is committing that the decision maker is ready to move forward if the POC is successful.
Rule #2: Never do a POC to prove ROI - only to prove functionality
Sometimes, decision makers will want to prove impact in a proof of concept. Meaning, I want to PROVE that our team was more productive with your product, that your product drove a meaningful amount of new leads compared to the old way, etc.

You should never allow ROI to become part of your POC success criteria. First of all, a few weeks isn’t nearly enough time to predictably prove anything, so that means you’re just taking a massive coinflip risk on something that is unlikely to work out the way you want.

Secondly, a POC involves time ramping onto the product, oftentimes WITHOUT a customer success manager’s help. So you’re just shooting yourself in the foot if you think a POC will be an accurate representation of what a real rollout would look like.

On the other hand, if your prospect simply wants to confirm the product is easy to use, that a few people on the team actually like it, and that the functionality advertised works as promised, that’s a different story- that’s totally fine.

The litmus test: anything you test in a POC, you should be over 80% sure that it’ll go well. Whenever you fall below this line, you’re taking too big of a risk.
Rule #3: Leadership must approve all POCs
This may not be applicable if you’re super early stage, but at some point, you should not allow sellers to unilaterally decide to grant a POC. You should have some criteria in place, or an approval process, where a head of sales would need to approve POCs.

This forces sellers to actually think through the purpose of the POC, and first conclude “I can make a strong case for why this POC needs to happen.” That’s important, because it can become way to easy to just grant POCs willy nilly where the prospect isn’t accountable to any outcome, and doesn’t value the free access to the product as a favor.

If the prospect doesn’t value the proof of concept, there is a strong chance that they will forget to start it, get distracted, etc. - and a few weeks can easily turn into months of intending to trial.
Rule #4: Prospect must agree to success criteria before starting a POC
Before you launch a proof of concept, you and your prospect should sit down and map out the exact things they’re looking to test. Make a checklist together- if the following things are true, the prospect must agree that they plan to purchase at the conclusion of the POC.
I think of this a “microcontract” - microcontracts are little agreements or trades throughout the sales process that help you drive accountability.

The bottom line is this: if we prove all the specific things you want to approve, I need to know that you’re planning to buy. The worst possible outcome would be proving all the success criteria, only to have the prospect back away from purchasing. That means you wasted your time.

By the way, as a seller, it’s your job to not allow nonrealistic success criteria. If a prospect wants to tie the success of the POC to a certain level of ROI, a strong seller would push back and explain that it’s unrealistic to prove ROI after 3 weeks. If prospect isn’t ok with that, then you shouldn’t pursue a POC together.
A lot of times in sales, you must be willing to go all in on a belief, and risk losing the deal as a result. This doesn’t mean you should be irresponsible- it just means that if you allow certain conditions, you’re so heavily handicapping yourself from ever making a good sale that it’s not worth it.
Rule #5: POC deployment must align with buying timeframe
Most POCs tend to last four weeks, but my personal feeling is that this is a little bit too long. I think three weeks is the goldilocks zone- there’s enough urgency where there’s pressure to actually get started, but without it feeling like a total squeeze.

Beyond that, you must get a commitment from your customer that they’re ready to get started and actually use the product. Never deploy today so that they can actually start paying attention to the POC in a week or two.

If the customer isn’t ready to actually start the POC, insist on waiting to deploy until they’re ready. That might sound like: “we should both view this end date three weeks from now as the true end date of the pilot. If we don’t think we can make a decision by that date, we should wait to start the POC.”
Rule #6: Customer must agree to a project plan with timed milestones & stakeholders
It doesn’t have to be a crazy heavy lift, but as a seller, you should share a GSheet with key milestones of the POC, and which stakeholder owns them.

This means you can catch the moment where the POC has gone off track- it means that the mini milestones you’ve set up hasn’t been met, and you can pinpoint who was supposed to own that item.

If you establish ahead of time how big a favor the proof of concept is, prospects will value it more and be more respectful of the project plan. If you grant it too easily, or worse, actually PUSH a proof of concept on your prospect, it’s very unlikely they’ll meet you halfway, effort-wise.
Rule #7: The rules don’t go out the window for “bake offs”
There is a certain style of POC that sellers refer to as a “bake off.” This means a prospect will be actively comparing your product to your competition, and picking a winner based on the results.

I’d be very dubious of bake off scenarios- they’re very rarely worth your time as a seller, and puts the buyer in a huge position of power where they feel like they can boss you around at every step.

This could be its own article, but the TL;DR here is that all the rules of a POC that we discuss above apply in a bake off scenario. If you have an industry leading product, the prospect probably knows that too, and you don’t have to give in to a prospect’s demands without them trading an equal level of commitment to you in return.
Rule #8: POC must result in a go, or no-go, decision
This one is very simple and probably the most important- your customer should agree that when the POC ends, they’re either signing a contract, or you’re both going to agree that this is not the right solution.

In sales, a no-decision is the worst case scenario. A “no, this isn’t for us” at least allows you to focus on the deals that are more deserving of your attention, so that outcome is totally acceptable. But you can’t get to a no if the prospect forgets to deploy the POC, or can’t effectively reach a conclusion on the success criteria you outlined.

In summary:
A proof of concept can be a very slippery slope. You should avoid them if at all possible. If they are completely unavoidable, and customer has a valid need to test that the product works as advertised, a few things must be true:

1. Customer must appreciate the gravity of a free proof of concept- product cost is one thing, but human time is the biggest give. It must be valued correctly on both sides.
2. Customer must agree to realistic success criteria
3. Customer must commit to a project plan, and to be accountable for timelines
4. Don’t get in the habit of extending POCs. Explain ahead of time that we should only start the POC when it aligns with a decisionmaking and contract execution timeline.
5. Customer (and their decision maker) must agree that if proof of concept goes well, they will be buying at the conclusion of the POC.

Unstarred

Dunk (exclude from study)

Proof of Concepts

Review Questions

Todos

Sensemaker