So You Want To Do Robots, Part 3: How to Escape Pilot Purgatory
About this series
I’ve been working on general purpose robots with Everyday Robots for 8 years, and was the engineering lead of the product/applications group until my whole team was impacted1 by the recent Alphabet layoffs. This series is an attempt to share almost a decade of lessons learned so you can get a head start making robots that live and work among us. Part 2 is here.
How you will fail
I mean, I hope you don’t fail, but building a robotics company is very hard.2 And it's useful to study the patterns of what doesn’t work. In this part, we’re going to dig into the most common death pattern for robotics startups: starving in pilot purgatory.
If you’ve been at a robot startup, this story is likely familiar. You talked to potential customers about what they would like and built that. They’ve been happy; excited even. The customers bought/leased/borrowed a few robots for a pilot. Everytime you talk to your contact (who probably works in something called the ‘innovation group’) they are enthusiastic and say things are going great. You’re pumped: you’ve done it. Now you just have to wait for them to buy more and turn that pilot into a full deployment. So you wait. You email. You ask what is stopping them from moving forward and get vague “oh we’re looking at budgeting” or “still evaluating” or “we love it but aren’t ready for more yet”. You are burning runway but it feels like you are getting nowhere. You are stuck in Pilot Purgatory.
The Process3
Doing competitive analysis of robotics startups is not scary because your competition is big and strong. It's scary because so many of them are failing to get a good enough product fit. And when you are in Pilot Purgatory, you don't know how much purgatory is left ahead of you, and you run the real risk of running out of time4 before you reach the promised land. And many of your failing competitors aren't trying to build a general purpose platform: they are trying to build specialized hardware and software to solve a narrow need. It should be easier for them. And it still isn't working.
Friendly Customers are Tricky
Your other problem is that your robot is going to be bad at stuff. Robots are bad at most things, especially in human spaces. So you probably are going to need a really friendly customer to put up with your robot bullshit. At Everyday Robots we used Google facilities, who have been super patient with our bullshit.
Oh, your robots can just wipe the crumbs on the floor and we’ll clean them up after.
But you want to escape pilot purgatory which means you need to know what to build. If your customer is too friendly you will get damning praise. “Oh we like it! If you just make it better/faster/more it will be great”. You have to build something they want, not just like. And with robots making the wrong thing better/faster/more is very expensive.
So what do you do? You know that if you sit in your lab and imagine a product and just build that for 5 years you’ll build the wrong thing. And an unfriendly customer would have fired you by now, so you’re stuck with friendly customers. So here’s my tip: ask them what they want, but don’t pay attention to what they say they’ll pay you.5 You need to understand their business better than them. You need to know exactly how their system works. You can’t get this info from the CEO or shift manager. You probably can’t get it in an interview. Shadowing people doing real work is the minimum and doing it yourself is better if you can pull it off.
Real Value, Not “Exposure”
There is one more trap to look out for. When you’re in Pilot Purgatory you are talking to customers and delivering value, but not the kind of value you think. Often the value you deliver is giving your customer a way to brag about how innovative they are. To impress shareholders/executives/press one pilot is all they need.
“I’m loving our pilot! Look at this great press release!”
“Does that mean you want to expand to all your locations?”
“No, why would I?”
Which means that, even more than for a conventional startup, a robotics startup needs to obsess about how they deliver actual value. If you can go to the customer with numbers and say “we’ve been running this pilot and we’ve timed everything and each robot is saving XXX off your bottom line” you have a fighting chance of escaping Pilot Purgatory.
“Our robots actually save you money? That's never happened before!”
Ask yourself how long does a human take to do the task and how often does it need doing? What else are they doing? Humans are often doing 2-3 things at a time (like wiping tables, pushing in chairs and checking for spills, on the chairs or floor). If you automate checking the floors for spills have you saved any time at all?
Set Uncomfortable Goals
This means your goals are going to be uncomfortable. Say you are automating an inspection service that checks carpets for stains. An easy goal would be:
“Our robots inspect for stains 3 times per day at 95% accuracy”
You can write specs to that goal, engineers can break it into parts and execute. You can’t be sure you’ll hit this goal, but it's all within your control. Very comfortable. This is not getting you out of pilot purgatory. Better would be
“We find 90% of stains within a day of them appearing”
This is better because you’ve stopped thinking about the robot and its capabilities and started talking about the customer goals, but what you really need is:
“The robot is able to save humans 1-2 hours per shift by sending the shift manager on spot-checks rather than full inspection routes”
If you have this, you can make a strong case for expanding your pilot. Of course I’ve never gotten that far,6 so who knows what hard problems lie after that. But if you have a robot that saves someone money, you are going to be in a better place than 95% of robot startups that have ever existed.
Next up: Part 4: Profit?
Thanks for Michael Quinlan and Darcy Grinolds for reading drafts of this.
[citation needed]
"The Process" graph shamelessly stolen and lightly modified from YCombinator partners Paul Graham and my old boss, Trevor Blackwell, who called the middle part the "Trough of Sorrow."
s/time/money
They don’t know anyway. And remember, what you charge and what it costs you to run us are unrelated things. When you are starting out, odds are you’ll be charging a friendly customer a small amount of money to keep their "skin in the game" but discounted all to heck because they are putting up with your janky shit. What it costs you to run is a bajillion dollars.
So, like what do I know? Jokes on you, though, you already read what I have to say, and now it's too late.
"You have to build something they want, not just like."
Or maybe don't like at all. It reminds me of the early automotive industry. When engines started to be small enough to fit on a vehicle like a delivery truck or bus, people absolutely hated them for being so loud, shaky, smelly, etc. But the value was so much better in terms of time and capacity than the horse-driven equivalents of the time, that people just had to live with it. And then, the down-sides were improved over time as makers competed to put out the most polished products.
Maybe too much efforts are spoiled in the pilot purgatory by false hopes that if you make it likable enough they'll want it even if it doesn't save them that much money, if any, rather than the opposite. If it brings them enough value, they'll live with the rough edges and you'll have plenty of time to smooth them out as you grow.
The "Real Value, Not Exposure” hits home. I had a great conversation at a manufacturing trade show once with someone who sold collaborative robot arms and system integration services. He kept selling 1 arm or workcell to a large well-funded company and not more. Eventually he realized he was often selling to the "Innovation Team" or "Advanced Applications Team" within a large company, which was an R&D cost center and did not have a good relationship the larger revenue-driving divisions of the company. It was sometimes hard from the team name and title to realize that's what was happening.
The Innovation Team would tell him exactly what they wanted and needed (sounds like great customer input!), and he thought he'd solve their problem... but it was a problem that was mostly good for a demo and helping demonstrate "vision" (how they were evaluated internally)... while not solving real manufacturing problems of the bulk of the company in a viable way. In some of these orgs, the fact that the "Innovation Team" was the one internally demonstrating an application to their manufacturing teams probably made it _less_ likely for the manufacturing teams to buy in (due to some past failure to take concept to reality) vs. if he'd just worked directly with the manufacturing user, though in theory a good advanced applications team would do feasibility filtering and tech transfer...
Maybe one lesson is "if you want to scale a business, it's not enough to ask a customer to tell you what they want... have them prove the need and value to you (and try to arrange follow-up meetings and LOIs at high enough executive levels that you're confident there's broad support to spend $$$ if successful)"