This newsletter covers go-to-market strategy for founders selling AI and hardware into industrial environments. If that’s you, or you’re investing in this space, you’re in the right place.
This is Part 2 of the Zero-to-one GTM Series. Part 1 studied how companies sell. This post studies how buyers buy.
I interviewed a dozen buyers across the manufacturing spectrum. I wanted to know: does the evaluation process change with scale, or is something consistent underneath?
The interviews spanned verticals across automotive, food and beverage, logistics, and warehousing. My interviewers include an automation manager at a hydraulic pump shop in Jackson, Michigan, a former plant manager running industrial chilling equipment in Toronto, a business development director at a top-100 automotive Tier 1 supplie, a technology transformation lead at PepsiCo, an operations executive at a global e-commerce fulfillment company, and several more. Their company sizes ranged from 50-person shops to Fortune 500 operations. Some had dedicated innovation teams, and some had never purchased from a startup.
Three patterns emerged from the interviews regardless of company size, geography, or industry, and I captured them in 3 decision gates.
Cold emails that say ‘I can save you X,’ I don’t believe any of them because most of them don’t even have a working product. I need to know someone who’s using them and that it works. If it’s a partner of mine, I’ll always take the call. If you’re telling me my competitor is using this, I will certainly be interested. — Operations Executive, Global E-commerce Fulfillment
Most factories don't have test environments. On 5-6% margins, any disruption to an optimized line is financially catastrophic.
If you disrupt a fully optimized manufacturing solution just for a day, it can cost millions of dollars. Nobody wants to put unproven technology into their factory. — Innovation and BD Director, Automotive Tier 1 supplier
A 2024 McKinsey industrial AI survey confirmed this: evidence of success in a comparable environment is the leading factor in manufacturing technology decisions.
The two biggest things: you’re addressing a real pain, and the solution doesn’t cause me more pain. What does this cost, and what is the ROI from all of this. —Former plant manager, Industrial Chilling Solutions
The ROI bar is specific and time-bound:
The ones that make the factory floor are the ones that have within two years an ROI on their CapEx. It doesn’t really matter what the technology is. — Innovation and BD Director, Automotive Tier 1 supplier
Demonstrating the right ROI also requires your understanding of the full deployment process. If you’re selling a subsystem, your ROI calculation should also include integration, commissioning, operator training, and five years of maintenance.
An internal team builds from scratch every time, but they have trust, floor access, and no procurement hurdle. A startup wins when ten similar deployments have produced a playbook the internal team can’t replicate.
It will always be cheaper to go with our internal partners. The only times we’ve picked somebody external is when their maturity stage is beyond entry level and they’ve worked with other big companies. If we’re working on it but it’ll take us a year, and the startup says ‘we are ready today,’ sometimes that wins — Technology Transformation Lead, PepsiCo
Roboflow's deployment blueprint describes the ideal vendor relationship as an inverse curve where vendor effort falls each quarter while internal capability rises. You don't just deploy faster. You make the buyer's own team faster.
These buyers want repeatable outcomes at scale. And they’re comfortable paying for it. — GTM leader, Roboflow
Underneath all three questions, customers are testing one thing: have you deployed this before, somewhere that looks like here, and did it work?
Gate 1 tests whether your deployments are repeatable enough that someone can vouch for you. Gate 2 tests whether outcomes are consistent enough to project with confidence. Gate 3 tests whether your playbook is mature enough to outpace an organization with floor access.
Startups that clear all three look the same way: deployment gets faster and cheaper each time, outcomes are measurable and referenceable, and sales cycles shorten as the playbook compounds.
In a standard funnel, PMF is validated upstream. Revenue is a direct indicator there is a clear product market fit. In deployment-dependent products, closing and deploying are different milestones. A bad-fit SaaS lead wastes hours. A bad-fit deployment lead that makes it to POC consumes weeks of engineering, pulls the product sideways, and produces an outcome nobody can reference.
Case in point: A growth-stage startup sold real-time retail data to brands, CPGs, and retailers. Each customer had different data sources, integration requirements, and success metrics.
Under growth pressure, sales closed whatever they could. Engineering built whatever each customer needed. By 30+ customers, they were maintaining 15+ custom installations. Engineering hit 60% of spend. Half of product and engineering was laid off.
What went wrong? They had funnel-PMF because deals were closing, but they didn't have deployment-PMF. The product fragmented into fifteen custom projects wearing one brand.
This pattern played out publicly at companies like C3.ai, which struggled when deployment complexity across verticals made unit economics unsustainable.
What does a GTM look like when it's designed to build deployment-PMF? I highlighted three shifts that might help.
Your deployment team has firsthand exposure to critical deployment-market fit information: connectivity requirements, environmental constraints, maintenance workflows, the gaps between what customers say and what actually happens on-site.
When treated as “post-sales” or “implementation,” this team gets siloed from the people making targeting and product decisions. But their insights need to flow in two directions: upstream to sales, where they refine customer selection toward environments you deploy cleanly; and upstream to product, where they surface the integration and debugging challenges that determine whether the next deployment gets easier.
In the first five deployments, the founder should be on-site. You learn things no report captures: which features operators actually use, what the plant manager asks when the system goes down, what the real timeline looks like versus what you quoted.
As the team scales, repeatability becomes a strategic focus. Aim for 80% of deployments to be repeatable: building speed, refining playbooks. The other 20% can be hard and novel, expanding capabilities. Skip that balance and you end up with 15 configurations across 37 customers.
Each repeatable deployment produces a reference, and clears Gate 1 for the next similar prospect.
Case in point
Anirudh learned this building Einsite, a construction equipment monitoring startup later acquired by Monarch Tractor. His team started trying to monitor 25 different machine types across massive construction projects. The complexity was unmanageable. They narrowed to earth moving: three machine types, five or six tasks. Only then did deployments start to compound.
“Repeatability is the lens I see the world through now. What are things that are repeatable? When you have repeatability you have scalability. Without that, you’re doing custom solutions.” -Anirudh
The tension: Dedicating 20% of capacity to learning feels like a luxury. If you have to chase logos, chase ones adjacent to your target: similar equipment, similar environment. A logo in an unrelated vertical fragments your learning.
I’ve come to think of embedded digital and hardware businesses as service businesses with a product component. Like a Michelin-star restaurant obsessing over consistent service delivery, product owners need to think through the entire customer journey, which ends in deployment.
That means planning for things that don’t come naturally to most product teams: remote debugging, field support, connectivity that varies wildly from site to site. It’s easy to categorize this as “deployment work” and therefore non-revenue. But when these issues surface late, the rework costs far more than building for them upfront.
Start by identifying where deployments break. Is it hardware reliability? Integration with legacy systems? Training data quality? Network connectivity? Build logging and diagnostics before features. You can’t improve what you can’t see.
As you scale, accept that integration will always be part of delivery. Most industrial environments are brownfield, equipment from the 1990s running proprietary protocols. The choice is whether you treat integration as a repeatable product capability or a custom project every time.
When your product absorbs deployment complexity, your ROI story gets simpler. You can quote faster timelines, lower integration costs, and more predictable outcomes. That's what clears Gate 2.
Case in point
Overview AI Co-Founder and COO, Russell Nibblelink discussed how they approached this from day one: “A lot of people could deploy a thousand cameras tomorrow. It’s very hard to deploy a thousand cameras and make sure they’re maintained with minimal effort for five years.”
Overview deconstructed the problem systematically: What does it mean to do inspection in the factory? What are the constituent elements? How do you integrate, deploy, and train? Is cloud the right architecture when internet is unreliable and the system needs to run for three to five years? Treating deployability as a product feature supported their growth to thousands of deployed systems.
The tension: Engineering pushes back on diagnostics and integration tooling because none of it drives immediate revenue. But the tradeoff is planned investment versus unplanned cost.
GTM leaders need to embrace technical and manufacturing reality instead of hiding behind pipeline metrics. In early stage, this is probably one person wearing sales, marketing, and product marketing hats, someone close enough to deployments to feel what’s working. As the company scales, it requires a GTM leader who can orchestrate across teams while staying grounded in deployment truth.
GTM is your product-market fit feedback loop. It generates a hypothesis about who to target, deployment tests it, product learns what worked, then GTM refines targeting. Each cycle sharpens where you fit, with two questions running in parallel:
Is there a market growing toward us? Are the problems we solve becoming more urgent? Are regulatory changes, labor shortages, or quality requirements creating demand we can ride?
Are we solving one problem better than anyone else? From deployments we’ve done, is there a pattern where we deploy faster or produce clearer ROI?
In early stage, this looks like structured experimentation: Anchor on one successful deployment. Study what made it work. Find the next prospect with similar conditions. Then test boundaries: take a deployment where one variable is different. See if it holds.
In later stage, the split becomes deliberate: 80% of GTM chases repeatable deployments in proven segments. 20% toward adjacent exploration, budgeted as learning, not revenue.
This is how you build the speed advantage that clears Gate 3. An internal team at a Fortune 500 starts from scratch. Your team walks in with a playbook built from ten similar deployments.That gap only exists if GTM sequences by deployment similarity.
Case in point: A vision AI startup selling into automotive manufacturing began by inspecting a single motor subcomponent, then replicated across automotive components to map what limited feasibility: field of view, defect size, and what slowed deployment: communication protocols, environment, lighting. They narrowed to components where deployments moved faster.
Meanwhile, they watched the market. Demand was growing in an adjacent vertical. They had a hypothesis: applications in this new market might fit what they’d already learned. They ran POCs to test which defect types matched their product maturity, then deployed where the fit was tightest.
The tension: Narrowing feels like shrinking your market. The data says it's the only way to grow it.
The evaluation process is remarkably consistent. A 50-person shop and a Fortune 500 operation both want the same three things. The only difference is how many layers of approval sit between you and the floor.
The traditional funnel doesn't build toward clearing those gates. The deployment-first framework does: anchor around the deployment team, build deployability into the product, and let deployment context drive who you sell to next.
This leaves practical questions. At what stage does each piece click into place? How do you structure POCs that generate both revenue and product learning? If you're at deployment number two, who should you hire first?
Part 3 covers the toolbox.
Only 5% of industrial AI pilots convert to full deployment. This newsletter is about that gap: what happens between your model and the factory floor.
Hi! I’m Trista, grew up in manufacturing, built GTM at UnitX, now helping technical founders close the gap between traction and deployment. If you’re new, start with the POC Valley Series.
If you’re building in this space, investing in it, or stuck somewhere without a playbook, let’s connect on LinkedIn. I’d love to hear from you.
80/20 Split – 80% of deployments in proven segments, 20% in adjacent exploration budgeted as learning.
Brownfield Environment – Industrial settings with legacy equipment requiring integration rather than clean installation.
Deployment Flywheel – Growth model where each deployment generates proof and learning that makes the next one faster.
Deployability – How many times you can deploy without custom engineering; a product feature, not an implementation detail.
Fully Loaded Deployment Cost – What buyers actually calculate: product price plus integration, commissioning, training, and multi-year maintenance.
Gate – Sequential buyer evaluation checkpoint. Gate 1: proof of prior deployment. Gate 2: clear ROI. Gate 3: speed versus internal alternatives.
Learning Deployment – Deployment in a novel environment, budgeted as capability expansion rather than revenue.
PMF (in deployment context) – Not just “customers will pay” but “customers will pay and the deployment makes the next deployment easier.”
POC-to-Production Gap – Where solutions that work in testing fail to generate ROI at production scale.
Problem Shape – The pattern of workflow, data sources, and success metrics that must stay consistent for deployments to compound.