Surviving the POC Valley
Part 2: Three tests between "it works" and "it's deployed"
This is Part 2 of a six-part series on selling technology with a physical footprint into legacy industries: manufacturing, industrial, and operationally complex enterprises.
In Part 1, we identified four organizational gaps that kill deals. Those gaps explain why enterprises struggle to move from POC to deployment. This part shows how those gaps appear in practice and how to spot them before you've over-invested.
But first, we need to understand the force that drives every enterprise decision: risk.
Why Risk Is the Only Thing That Matters
Enterprise buyers evaluate risk differently from what startups expect. Every stage (from POC, to pilot, to deployment) deepens the buyer's commitment and their risk exposure. The larger the manufacturer, the more costly each minute of downtime becomes.
Here is what it looks like in practice: 10 minutes of downtime at GM costs $380,000. The same 10 minutes at a Tier 2 supplier? $2,500. Same failure, but a consequence 150 times smaller.
This asymmetry explains everything about how enterprises evaluate new technology. They're not asking "is this better?" They're asking "what happens if this fails?"
So much of the business is based on forecasts. If you miss a forecast, that introduces a massive amount of risk. Warranty risk. Customer perception... Founders aren’t thinking about it in terms of risk to the business. They’re usually thinking about it in terms of cost, from a fiscal perspective. — Former Investor focusing on Automotive and Semiconductor
So how do enterprises manage this risk? By breaking it into stages.
What Each Stage Actually Tests
Each stage is a gate designed to catch failures before they become catastrophic. The purpose of each stage is to contain risk before it propagates. And each stage asks a different set of questions.
POC: “Does it work at all?”
The POC tests basic technical feasibility. Can your system handle their part geometry? Their data formats?
This is a single question under controlled conditions and a limited scope: Does the technology do what it claims? And could it be at least 20% better than what we have?
Pass this test, and you've earned the right to face a harder one.
Pilot: "Does it fit our operation?"
The pilot tests applicability. Now the buyer needs to know whether that capability survives contact with their operational reality.
There are probably ten different companies doing bin picking at Automate. But they usually show picking something out of a bin and setting it on a conveyor belt. We have to pick our parts out of a bin, then load them onto a pallet with bullet nose pins. You have to line up the holes on the part. Place them on those pins.
— Head of Automation, Melling Engine Parts
This is the gap between a demo and a deployment. Ten companies can pick from a bin. One company can pick their parts, their way.
When sophisticated buyers watch a demo, they're mentally running it against their constraints. The slightly different part geometry. The lighting during second shift. The legacy fixture that doesn’t appear on any floor plan.
The pilot answers: Can this technology survive our reality? But surviving isn’t the same as scaling.
Deployment: "Can you support it at scale?"
Deployment tests operational maturity. It tests whether you've built the infrastructure to support what you're selling. What’s your lead time on replacement parts? If something breaks at 2 AM, who answers the phone? How do you handle maintenance and recalibration over time?
Manufacturing is not a service you buy. It's a capability you build.... If a company's hardware operations can be summarized in one sentence, it doesn't have a hardware strategy. It has hope. — Rui Xu wrote, reflecting on why his robotics startup failed (Source: Six Things I Learned Watching a Robotics Startup Die from the Inside)
Enterprise buyers can tell the difference. A startup that can't answer supply chain questions with specifics (lead times, redundancy plans, service-level commitments) signals something dangerous. Deployment will become the buyer's problem, not the vendor's. That's a risk most operations teams won't take.
So if every stage has a clear purpose, why do so many deals stall? Because startups and enterprises are playing by different rules.
Where the Mismatch Happens
A POC can hit every technical milestone, and still never reach the next stage. Most POC failures trace back to a fundamental disconnect: you're iterating, while they're validating. Neither approach is wrong. They’re just incompatible.
This incompatibility shows up in three predictable ways.
Mismatch 1: Entering POC Without Knowing What Pilot Requires
Buyers are testing you before the POC even starts. They'll ask about integration requirements, failure modes, and service-level norms.
Your answers sort you into one of two categories: a vendor who’s done this before, or a startup that’s going to learn on their floor.
“Early on, unfamiliarity with PLCs and MES made us look stupid. They’ll ask about how we integrate specifically in their environment, like Allen Bradley vs. Siemens. If you don’t know what those are or can’t confidently say yes, it shows you’re a noob, and you lose trust.” — Founder selling into manufacturing
The fix isn't to fake expertise. It's to ask the questions that prove you've been burned before. When you ask about part drift across suppliers? Or what happens when something fails at 2 AM?
You're not exposing ignorance. You're demonstrating that you know where automation breaks down. That's credibility in the room.
Mismatch 2: Ignoring Supply Chain Until It's Too Late
It's tempting to treat the supply chain as a later problem. But this may be the most important question to answer early. You can't build supply chain infrastructure in a quarter. If you win the pilot but can't support deployment, you've wasted everyone's time.
If there's an issue with the equipment and the part to fix it has a 12-week lead time, my production will be halted for more than three months.— Engineering Manager, Industrial Automation Company
Supply chain readiness is about proving you can support the technology. But there's another question buyers forget to ask: who's actually going to use this?
Mismatch 3: Building for the Evaluator, Not the End User
A POC can validate perfectly at the management level and still fail at deployment. Why? Nobody asked the people who'll actually use it.
The shop floor knows instantly whether you built something for them or for someone above them. — Nick Haase, MaintainX (Source: Manufacturing Tech )
Sometimes the boss signs off on an Industry 4.0 project. Tests were ran and success was declared. Meanwhile, the people who'll actually use it sit in the room nodding along, unsure how this will affect their day-to-day.
Management might assume "they can be trained.", but that doesn't mean they will be. Operators who inherit technology they didn't choose will work around it. It gets underutilized or abandoned entirely. You won’t find out until the deployment has already failed.
Qualifying for the Next Stage
The three mismatches share a common root: optimizing for the current stage while ignoring what the next one demands. Startups treat each stage as a finish line. Enterprises treat each stage as a filter.
The frameworks below force you to think like the buyer: Asking tomorrow’s questions before you’ve committed to today’s test.
Before POC: Is This Deal Worth Entering?
Before you invest engineering time in a POC, you need to answer two questions. Get either one wrong, and you'll spend months learning what you could have known in the first conversation.
Question 1: Is this buyer serious?
Not every inquiry is a real opportunity. Some buyers want to check a box. Others want to see what's out there. The POC Qualification Scorecard separates serious signal from noise.
If a deal clears all three gates, commit fully. If it clears one or two, proceed with caution and name what’s missing. If it clears none, you’re looking at innovation theatre.
Question 2: Is this deal building toward something?
A deal can have strong buyer signal and still teach you nothing scalable. The matrix forces a harder question: even if we win, can we repeat this ten times?
Innovation theatre isn't always obvious. Sometimes it looks like a signed POC with a real budget. The question isn't whether the deal is real. It's whether the learning is real.
Before Pilot: Can You Support What You're Proving?
A POC proves your technology works. A pilot proves you work, your support model, your integration depth, your ability to operate in their environment. This is where Mismatches 1 and 2 become fatal.
If you don’t know what pilot requires, you’ll learn on their floor. If you can’t support what you’re selling, deployment becomes their problem.
If you can answer these questions, you’re ready for the pilot. If you can’t, you’re not unqualified, you’re just not ready yet.
Before Deployment: Have You Validated with the End User?
A pilot can succeed at the management level and still fail at deployment. The gap is Mismatch 3: building for the evaluator, not the operator. The shop floor knows instantly whether you built something for them or for someone above them. If you haven’t tested with operators, you haven’t tested.
Before committing to deployment, confirm: Have operators actually used the system, not just watched a demo? What friction did they report? What workarounds did they invent? Who owns training, and is that plan defined?
If you’re checking “No” on any of these, deployment will surface it. Better to know now.
One more question: Does this deployment build toward something repeatable? Return to the matrix. A deployment with strong buyer signal but weak market signal might still be worth taking, but don’t let it consume resources that should go toward repeatable wins.
At Any Stage: When to Walk Away
Some deals cost more than they’re worth. The hard part isn’t recognizing them. It’s walking away when the revenue is real, and the pressure is high.
The cost of a bad POC isn't just the time you spent. It's the better opportunity you didn't pursue. Every month in a deal that was never going to convert is a month not spent on one that could.
A clean exit sounds like this: “Based on what we’ve learned, I don’t think we’re the right fit for this use case right now. If the requirements change, I’d love to revisit.” Buyers remember honest vendors. Some come back when circumstances change. The ones who don't weren't going to convert anyway.
Conclusions and what’s next
Most startups fail not because the technology isn’t ready. They fail because they don’t realize which test they’re taking.
Part 1 explained why POCs fail. This part showed what each stage tests. And why deals stall in the transitions. The frameworks force clarity earlier. Before you've spent six months learning which deals were never going to convert.
Part 3: What to do when you're stuck in pilot purgatory.
About this series
Hi! I’m Trista. I’m a former founder, founding GTM at UnitX, and now a GTM strategist for technical founders deploying in legacy industries.
This series grew out of conversations with founders, operators, and enterprise leaders working at the intersection of hardware, automation, and manufacturing over the past 18 months. Special thanks to Aaron, Abdul, Pete, Kevin, and Ned who allowed me to quote their insights that shaped this analysis.
If you’re building in this space, or buying, or stuck somewhere in between, I’d love to hear from you.
P.S. A few readers pointed out places where their experience diverged from what I described in Part 1. I appreciate those notes more than you know. My vantage point is one slice of the market. If something doesn't match what you're seeing on the ground, tell me. Those discrepancies make the next piece better.
Glossary
Allen Bradley — A brand of programmable logic controllers (PLCs) and industrial automation equipment manufactured by Rockwell Automation. One of the most common control system brands in North American manufacturing.
Cycle time — The total time required to complete one production cycle, from start to finish. A critical metric that determines throughput capacity and often serves as a hard constraint for any new technology.
DCS (Distributed Control System) — A control system architecture used in process industries where control functions are distributed across multiple nodes rather than centralized. Common in chemical, oil and gas, and pharmaceutical manufacturing.
Deployment — The final stage of enterprise technology adoption where a system moves from a limited pilot to full operational use across production environments. Tests vendor maturity, support infrastructure, and scalability.
Downtime — Any period when production equipment or systems are not operational. Costs vary dramatically by company size—from thousands to hundreds of thousands of dollars per minute—making downtime risk a central factor in technology evaluation.
Innovation theatre — Organizational activity that creates the appearance of innovation without genuine intent to adopt or scale new technology. Often characterized by POCs that check boxes but lack pathways to deployment.
MES (Manufacturing Execution System) — Software that tracks and documents the transformation of raw materials into finished goods. Bridges the gap between enterprise resource planning (ERP) systems and shop floor control systems.
Pilot — The second stage of enterprise technology adoption, following POC. Tests whether a technology can survive real operational conditions—variability, integration requirements, and workflow constraints—before committing to full deployment.
PLC (Programmable Logic Controller) — An industrial computer designed to control manufacturing processes. The backbone of most factory automation, PLCs execute logic for equipment control and communicate with higher-level systems.
POC (Proof of Concept) — The first stage of enterprise technology adoption. A controlled test to validate basic technical feasibility under limited conditions. Answers the question: “Does this work at all?”
Rockwell Automation — A major industrial automation company and manufacturer of Allen Bradley control systems. Understanding whether a plant runs Rockwell, Siemens, or other platforms determines integration complexity.
SCADA (Supervisory Control and Data Acquisition) — A system architecture for high-level process supervision and control. Collects data from sensors and equipment across a facility and provides centralized monitoring and control interfaces.
Siemens — A multinational industrial manufacturing company whose automation division produces PLCs, drives, and control systems widely used in global manufacturing. Along with Rockwell, represents one of the two dominant control system ecosystems.
SLA (Service Level Agreement) — A commitment between a vendor and buyer defining expected performance standards, response times, and support obligations. Lack of clear SLAs signals to enterprise buyers that deployment risk will fall on them.
Tier 1 / Tier 2 supplier — Classification of suppliers in automotive and other manufacturing supply chains. Tier 1 suppliers deliver directly to OEMs (e.g., GM, Ford). Tier 2 suppliers provide components to Tier 1s. Tier position correlates with operational scale, downtime costs, and procurement sophistication.