Launching fast with semi-autonomous MVPs
I'm trying to solve this with flywheel.
Funding of Robotics companies dropped to a new low this quarter, which means robotics startups need to start generating revenue as quickly as they can to stay alive. While it seems like common knowledge, it’s harder for robotics companies.
Key reasons why it's harder and slower:
- First, building the hardware takes time. Designing and getting parts takes time. Fabrication takes time. Assembly takes time.
- Hardware products are usually more complex. This makes it harder to troubleshoot, and there are more design decisions involved.
- Building requires tools and equipment, which needs money. Quality of build generally is proportionate to tools you have.
- Robots involve both hardware and software, and writing software for hardware is generally more difficult. Writing autonomous software is even more difficult once you go beyond a few common functionalities.
The general advice to keep building from scratch to minimum and use as many off-the-shelf parts as possible is good but not enough to move fast. It can still take forever to write its software.
I get it. It's an incredibly difficult process. I’ve dwelled deep into AgTech robots and experienced this firsthand. To begin with, there's a lack of annotated real world data for most industries. To deploy any version of usable autonomous software, companies would have to spend significant time collecting data and training their AI model. This kills a lot of time for many companies.
But startups don't need to do all of this before launching. More companies should explore the idea of launching their robot’s MVP with a remote teleoperation. Remote teleoperation is the process of manually controlling a robot from anywhere in the world. Since humans do the controlling, you can outsource most of the complex activity to humans who control the robot in the beginning.
How does this speed up deployment?
You focus your resources and efforts on quickly validating the problem, customer need and the user experience. You take as much off-the-shelf hardware as possible, combine it with minimal software required for tasks like hardware interface, reactive controller and data collection. The operator does the job of collecting and annotating data, creating real world dataset to better train the autonomous software, while imitating to be the autonomous software and giving the same user experience to customers from day 1. So instead of waiting indefinitely and building the product in vacuum, this approach allows you to give some version of the product within months.
And notice how in this case you are now already making money while collecting the dataset to train your software, as opposed to doing all of that while burning money when you don’t launch. This might make a real difference for some companies in staying alive, especially in these times. You have a lesser chance of running out of money before ever shipping something. And since shipping regularly helps keep up cadence and momentum, this is mentally much better place for the team to be in.
I once was explaining this approach to a friend and he asked, "what’s the point if a human is going to control the robot manually? You’d still need workers, right?". Right. However, these workers can now be anywhere in the world. Workers are unequally distributed, and the site of work might not overlap with where they are. Think of a strawberry farm, for example, which due to all the physical conditions required, is best suited to be in California or Spain. Although there are more workers available in Mexico and Ecuador, the farms can’t go there. What can be done instead is letting them work at your farms remotely with wages that’s higher than what they’d have made locally, while you the farmer pay them less than what an on-site worker demands. A win-win. So even if you were to indefinitely operate on a semi-autonomous setup, it won’t be the worst thing ever.
I was wondering why more companies haven't been using this approach? After all, this is not an original thought and others more experienced than me would have thought of this. After some reading I came to the conclusion that while there are some companies using this approach, the benefits have only become clear recently. First, teams tend to underestimate how long it’s going to take to develop a production-ready version, and when they do that, semi-autonomous doesn’t seem to give much of an upside and rather seems like a distraction. Second, streaming sensor and control data over the web in real-time have only gotten so seamless and usable recently. This is both due to faster internet connections and some really good engineering for development of relevant frameworks.
I believe over time more teams would realize the benefits of deploying with a remote-teleop version to ship and stay alive.