Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / Why Hardware Startups Fail at Pilot Programs
Transcript
- Lucas: So here is a number that keeps me up at night when I talk to hardware founders: seventy percent of hardware startups fail during their pilot phase. Not before they build the prototype, and not after they launch. But right in that messy middle where they try to sell five hundred units to real customers. Luna: Seventy percent? That seems incredibly high. Most people think the hard part is getting the engineering to work. The rest is just logistics. Lucas: That is exactly the trap. Engineering teams spend eighteen months perfecting the device in a controlled lab environment. They control the temperature, the lighting, the network connectivity. Then they hand it to a customer who uses it in a warehouse with poor Wi-Fi, on a dusty table, while wearing gloves. Luna: Right. The environment changes everything. I remember reading about a smart thermostat company that failed because they didn't account for interference from HVAC systems in older homes. Lucas: Exactly. And it is not just about the physical environment. It is about the economic reality of the pilot itself. When you are selling your first hundred units, you are essentially doing free consulting work for your early adopters. You are debugging their business processes, not just your code. Luna: So the pilot becomes a service contract rather than a sales channel? Lucas: Precisely. Let me give you a concrete example. There was a robotics startup making automated inventory scanners for retail stores. They built a beautiful device. It scanned shelves ten times faster than humans. But they assumed store managers would integrate the data into their existing enterprise software. Luna: And did the software integrate? Lucas: It did not. The retailers were using legacy systems that could not accept the API format the startup used. So instead of a smooth sale, the startup had to send engineers to every single store to manually download data via USB drives. Their unit economics collapsed because the cost of deployment exceeded the margin on the hardware. Luna: That is a brutal lesson. They solved the hardware problem but ignored the integration friction. Lucas: They ignored the total cost of ownership. And this brings us to the core issue of Episode Two Hundred and Seven. We need to talk about how to structure pilot programs so they actually generate revenue and learnings, rather than burning cash and goodwill. Luna: Most founders treat the pilot as a test. But if it costs more to run than the product generates, it is a loss leader, not a test. Lucas: Spot on. The first mistake founders make is thinking that 'free trials' or 'heavily discounted pilots' are good ways to get feedback. They are not. When you give something away for free, you attract users who do not value it. They break it, lose it, or ignore it. You get no signal. Luna: I have seen this with SaaS companies too. Free users churn instantly. Paid users stick around. Lucas: Hardware is even worse because the sunk cost is higher. If you give away a thousand dollar sensor, and the customer returns it broken three weeks later, you have lost both the hardware cost and the shipping cost. You need to charge full price, or close to it, during the pilot. Luna: But charging full price sounds risky for a brand new company with no reputation. How do you convince anyone to buy? Lucas: You offer a guarantee. A ninety day money back guarantee with no questions asked. This filters out the tire kickers. Only serious buyers who expect to use the device will pay. And if they return it, you get the unit back, you inspect it, and you learn why it failed. Luna: That shifts the risk back to the seller, which is fair since the product is unproven. But it protects the quality of your feedback loop. Lucas: It does. Now let us talk about the second major pitfall: scope creep. During the pilot, customers will ask for small tweaks. Add a button. Change the color. Make the app darker. Founders say yes to everything because they want the sale. Luna: That derails the timeline immediately. Every change requires retooling or reprogramming. Lucas: It does. And soon you have a custom variant for each of your ten pilot customers. You cannot scale that. You need a strict change order process. If a customer wants a modification, it goes into a backlog. It does not ship until Version Two. You protect the core product integrity. Luna: So you treat the pilot units as identical to the future mass-produced units. Even if it means losing some early deals? Lucas: Yes. Because if you build a monster product that only works for your first ten customers, you have no path to scale. You need to find the common denominator across all pilot users. What feature did nine out of ten people love? What bug annoyed everyone? Focus on that. Luna: This feels like it requires a lot of discipline from the founder. It is easier to just say yes to the big client. Lucas: It is. But the third pitfall is even more dangerous: measuring the wrong metrics. Founders love to track engagement time, battery life, scan speed. Those are engineering metrics. Customers care about business outcomes. Did it save them labor hours? Did it reduce errors? Did it increase throughput? Luna: If the robot scans fast but breaks down every hour, the engineer is happy but the operations manager is furious. Lucas: Exactly. You need to tie your success criteria to the customer's P&L. If you can prove that your device saves them two thousand dollars a week in labor, then the hardware cost becomes irrelevant. That is how you justify the price and secure the renewal. Luna: So the pilot is really a validation of the value proposition, not just the technology. Lucas: Absolutely. Now, before we go deeper into the operational mechanics of running these pilots, I want to pause for a moment. If these conversations are useful for what you are building or running, please consider supporting the show directly. A couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo. It helps us keep the research deep and the ads out. Luna: Yeah, we appreciate it. It allows us to dig into these niche corners without rushing. Lucas: Thanks. Let us get back to the operational side. One specific tactic that works well is the 'shadow pilot'. Instead of handing over the device and hoping for the best, you embed one of your own engineers with the customer for the first week. Luna: That sounds expensive. Does the ROI justify having an engineer on site? Lucas: For the first five or ten deployments, absolutely. You are buying information. You see the installation failures, the user confusion, the environmental hazards. You document everything. Then you build those fixes into the next batch of units. After five iterations, you stop sending engineers. You have codified the knowledge. Luna: It turns implicit tribal knowledge into explicit documentation. Which is basically what scaling is. Lucas: It is. Another key element is the feedback cadence. Do not wait for the pilot to end to ask for feedback. Schedule weekly check-ins. Not sales calls. Technical debriefs. What broke this week? What surprised you? What did you wish it could do? Luna: Proactive outreach prevents the surprise churn at the end. People usually ghost you when things go wrong. Lucas: Right. Silence is the enemy. If a customer stops responding, call them. Ask if the device is still installed. Ask if they are still using it. Often, they stopped using it because of a minor inconvenience you could have fixed in minutes. Luna: So retention during the pilot is just as important as acquisition. Maybe more so. Lucas: It is. Because each successful pilot becomes a case study for the next ten pilots. You are building social proof in real time. But you must be honest in those case studies. Do not hide the bugs. Show how you fixed them. Buyers trust transparency. Luna: Admitting you struggled makes the final product feel more robust. Lucas: It does. Now, let us talk about the exit strategy. How do you transition from a pilot customer to a recurring revenue customer? Many startups leave this open-ended. The customer says 'let us extend the trial another month' indefinitely. Luna: That kills your pipeline. You never know if you have product market fit if you never close the deal. Lucas: Correct. Set a hard expiration date for the pilot. Sixty days or ninety days. At day forty-five, start the commercial negotiation. Present the data. Show the savings. Offer the warranty. Close the contract. If they do not convert, you retrieve the hardware. Do not let it linger. Luna: Retrieving the hardware is painful financially, but necessary strategically. Otherwise you have a graveyard of devices sitting in customer warehouses. Lucas: A graveyard of dead equity. And it confuses your sales forecast. You need clean data. Did the pilot convert or not? Yes or no. Binary outcomes teach you faster than ambiguous ones. Luna: I wonder if there is a psychological barrier for founders. They fear that closing the deal aggressively will scare off the early evangelists. Lucas: That is a valid fear, but it is misplaced. Serious businesses respect serious vendors. If you act like a consultant offering a solution, they will treat you like a partner. If you act like a hobbyist giving away toys, they will treat you like a vendor to be squeezed. Luna: Positioning matters. It frames the entire relationship. Lucas: It does. One last thing on pricing during pilots. Some founders try to bundle services with the hardware. Installation, training, support. All included in one price. Luna: That sounds generous. Why is it a problem? Lucas: Because it hides the true cost of the hardware. Later, when you want to raise prices or add a subscription model, you have no baseline. You need to separate the hardware cost from the service cost. Charge for the box. Charge separately for the setup. This clarifies the value of each component. Luna: Transparency in pricing builds trust. And it makes future negotiations easier. Lucas: Exactly. You can always discount services. You rarely discount hardware once the bill of materials is set. Keep the margins visible. Luna: So the pilot is not just a test of the product. It is a test of your business model. Lucas: It is. And if your business model breaks under the weight of five customers, it will definitely break under the weight of five thousand. The pilot exposes the structural weaknesses before they become fatal. Luna: That reframes the whole anxiety. The failure rate is high because most founders skip the hard work of designing the pilot itself. Lucas: They treat it as an afterthought. They should treat it as the first product launch. Rigorous, measured, and intentional. Luna: Do you think larger companies handle pilots better? They have more resources to spare. Lucas: They have more resources, but they have slower feedback loops. Startups win here because they can pivot overnight. A large corporation might take six months to approve a design change based on pilot feedback. A startup can do it by lunchtime. Luna: Agility is the startup advantage. Speed of learning beats scale of budget in the early stages. Lucas: Always. As long as you capture that learning in a way that scales. Documentation, standardized processes, clear contracts. That is how you turn chaos into a factory. Luna: So the goal is to make the pilot boring. Standardized, repeatable, predictable. Lucas: Boring is good. Boring means you have mastered the craft. Exciting means you are still guessing. Which question should founders ask themselves before starting their first pilot? Luna: What is the minimum viable outcome that proves the value? Not what features do they want, but what result do they need? Lucas: Perfect. Define the result, not the tool. Then build the pilot around delivering that result, regardless of how the device looks.