Speaking of questions, what’s the difference between a POC and a Pilot?!
I work with Alchemist Accelerator as a mentor and guest speaker for the Sales curriculum, provide 1:1 founder coaching, and occasionally join as an advisor for early-stage startups developing the next generation of enterprise software. A common pain-point I often hear, is how to distinguish a POC from a Pilot and effectively engage with a customer.
The primary factors that differentiate between a POC and a Pilot, are scope and duration. Really the question is, how can we set up a potential customer for success as they evaluate our technology, which is what we’ll unpack today.
The 3 P’s of evaluating enterprise software
The “3 P’s” is a time-tested, proven model for organizations to evaluate an enterprise software platform. It’s a process that helps ensure everyone is comfortable in the decision to move ahead with an important buying decision, and also provides a clear path to budgeting for the project over time.
So what are the 3 P’s? A Hypothesis suggests something can be done. A Proof of Concept (POC) demonstrates technically it can be done. A Pilot validates with user feedback it can be done, and will support a larger-scale deployment. Once a service is deemed ready for full deployment it moves to Production. These stages provide organizations a proven path to evaluate and invest.
1) Proof of Concept (POC)
A POC is exactly what it sounds like: as a customer you’re getting tangible evidence from the technology partner that they have a solution to the problems you’re solving for (pain points), but does not represent deliverables around end-user experience. As a provider, it’s an opportunity to engage with a potential customer and demonstrate the feasibility of your service.
The purpose of a POC is to assess whether technically the service will work, and verify the service can likely be used as advertised. While the length of a POC can vary, it is typically short (hours or days) and contained to a handful of users. A POC can be free or paid, but there should always be an equal exchange of value between both parties. As a provider, don’t overextend yourself trying to support window shoppers just looking to kick the tires, with no real pain they’re committed to solving for. The main objective of a POC is to provide Technical Validation.
Typically a POC is trying to answer questions similar to the ones below:
- Will this product or service meet our technical requirements (ie. work in our current environment?
- Does this product perform as advertised?
- Is there potential that the prospective end-user communities will be productive with the new way of doing things?
- Will the ultimate solution be feasible?
IMPORTANT: A POC is often unnecessary if a demo environment provides suitable validation or there is enough customer (ie social) proof.
2) Pilot
The purpose of a Pilot is to evaluate the functionality of the product with real users, in real world scenarios, over time (and it should be paid). A Pilot provides the opportunity for an organization to demonstrate the functional value and assess end-user acceptance of a service “in the wild”. A test deployment of your software by the customer, a Pilot is a small-scale, short-term (ideally 12-month) experiment that helps an organization determine whether a large-scale, longer-term (multi-year) deployment makes sense. The desired outcome of a Pilot is User Validation setting the stage for a broader deployment.
Typically a Pilot is trying to answer questions similar to the ones below:
- Does this service meet our needs/solve for our pain?
- Will this service deliver on our users’ needs long-term?
- Will this product provide the user experience we want?
- How meaningful do our end-user communities find the service in their daily business?
- Does this service provide the tools we need to manage and support our users?
Generally once there is enough social proof, Pilots are not required. The value of the product or service is understood, and there is trust in the market and among your customers that your product or service will deliver.
3) Production
If the Pilot deployment is considered a success, and the organization as a whole (from IT, to the help desk, to management, to the business) is comfortable moving forward, the service is ready for Production. Many organizations define “production” differently as it relates to change management, control requirements, help desk processes, etc. Make sure you understand what’s involved as it may be different for every customer. Moving to Production can happen early in a Pilot based on user adoption and service consumption, which is a positive indicator of success. The objective of moving to Production is to introduce the benefits of the service to the entire user base.
The following are often completed before Production is reached:
- Formal training for end-users and help desk support
- Formal schedule for transition to the new systems– and associated communications to the user community
- Placement of the service into a formal operations and support organization with whatever processes are required
- Sign-off from the business
A good way to think about Production is in terms of “operational readiness”. How do end-users get support when they have technical issues? Are all the systems and processes in place to support this?
Conclusion
The “3 P’s” provide a proven enterprise engagement model and increase the probability of success for large customer deployments. The more “out of the box” and “off the shelf” your pricing and packaging, the easier it will be for a customer to go through a decision-making process and invest. Make the buyer’s journey as simple and easy to understand as possible. Ensure a smooth and seamless path to purchase. This will aid in driving velocity in your deals and help build momentum in the business.
About Andrew Elliott
From MVP to Scale. Over $50M in ARR. My passion is helping companies develop the people, programs, and process to drive net new ARR. I’ve been selling enterprise software since 2001 and have over 15 years’ startup experience, in every major vertical/market, across all segments from SMB to Fortune 10, including 6, 7, and 8-figure deals. I’ve been a single digit hire 4X and helped companies scale from $0M -> $5M, $5M -> $20M, $20M -> $100M, and $100M+. Over 4 years’ experience at publicly traded companies with revenues >$1B. Key customers include Amazon (F10), AT&T (F10), Wells Fargo (F50), Google (F50), Intel (F100), Disney (F100), Nike (F100), Fluor Corporation (F500), CBS (F500), Nordstrom (F500), Facebook (F500), Charles Schwab (F500), Salesforce (F500), Expedia [F500], PayPal [F500], LinkedIn (F1000), Kaiser Permanente, Uber, Slack, Rubrik, Airbnb, Wayfair, Dropbox, Box, DoorDash, Asana, Snap, Shopify, Instacart, TripActions, Coursera, Zoom, Robinhood, Twilio, Flexport, Confluent, Stripe, and Zalando among many, many more.
About the Alchemist Accelerator
Alchemist is a venture-backed initiative focused on accelerating the development of seed-stage ventures that monetize from enterprises (not consumers). The accelerator’s primary screening criteria is on teams, with primacy placed on having distinctive technical co-founders. We give companies around $36K, and run them through a structured 6-month program heavily focused on sales, customer development, and fundraising. Our backers include many of the top corporate and VC funds in the Valley — including Khosla Ventures, DFJ, Cisco, and Salesforce, among others. CB Insights has rated Alchemist the top program based on median funding rates of its grads (YC was #2), and Alchemist is perennially in the top of various Accelerator rankings. The accelerator seeds around 75 enterprise-monetizing ventures / year. Learn more about applying today.