So You Want To Do Robots, Step 4: Profit?
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 me and my team was impactedby 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. You can go back to part 1, 2 and 3 if you like (though each part is standalone so you don’t have to).
Show me the money
When thinking about robots there are an overwhelming number of problems you will need to solve. There's autonomy, performance, speed, safety, human-robot-interaction, delightful UX etc. However if you work a little on all of them then everything will move along at a snail's pace. The trick is to figure out what you want to keep “good enough” and what you want to devote every ounce of effort to making it better. So how do you pick?
It doesn’t do anything, but it does it really fast
Someday you need people to pay you more than your cost, which is a nice way to divide your todo list.
To decrease cost you:
Reduce cost to perform the work:
Reduce remote interventions (autonomy)
Reduce robot wear and tear (gentler use or sturdier robots)
Remove your local safety human(safety)
Increase speed(to do the same work with fewer robots)
Reduce hardware cost (cheaper robots)
Reduce the liability
Don't break things
Don't whack people
I’m looking at our budget and rethinking ming-vase retail as our MVP
Decreasing Cost Makes Pivoting Harder
A general trend is that reducing cost comes from doing optimizations across your system, which makes things harder to change. Its things like:
Ordering steel injection molds.
Choosing a low power compute and optimizing all your algorithms to just barely fit inside it.
Doing extensive risk analysis on a particular set of capabilities in an application to remove the local safety human.
Designing the whole hardware system together for cost
In addition, discovering product-market fit makes a lot of the cost reduction possible because you have actual requirements to optimize. Making a general purpose robot that can do anything "safe" is really frikkin' hard. Making a robot doing exactly this one thing "safe" is still frikkin’ hard but maybe manageable.
All of which points to working on lowering cost after you figure out revenue. You can’t ignore cost completely because huge costs eat your runway and you need to be able to convince yourself (and your investors) that you can make the numbers work someday, but you want to remove just enough cost to do both of those things while spending most of your energy creating value. So let's talk about flavors of value you can create.
Kinds of Value
Qualitative Value (delight)
Speed (hurts to watch paint dry)
HRI and product/service design
Quantitative Value (work)
Value of labor performed
Speed (can unlock use cases where there is a minimum viable speed)
This robot will finish wiping down your table in just 23 minutes, sir.
Silicon Valley conventional wisdom tells you that delighting your customers is super important, but that advice is for mature, crowded markets, especially where the value received is minimal but the cost is low and switching is easy (think most websites and apps). If you are making a new photo sharing app, qualitative value is super important. But robots just ain’t there yet. Another way to look at it:
Qualitative value makes people want to buy your robots. Quantitative value lets them justify it.
You probably already have people who want to buy your robots. That's why it's easy to get people excited about pilots. But folks cannot justify buying your robots, which is why you are stuck in pilot purgatory.
What you should focus on
Being successful means being very choosy about where you put your effort. With that in mind, for general purpose robots, you probably want to allocate your effort:
Cost to operate (autonomy): Good enough you can afford to keep going.
Cost of liability (safety): Good enough not to hurt someone or break anything important.
Qualitative value (delight): Good enough so your customers don’t rage-quit.
Quantitative value (work done): All your effort, all day, every day, like your startup depends on it.
Shameless Self Promotion
If you liked this you should subscribe now so you don’t miss the rest of the series. If you didn’t like this you should still subscribe because the next few posts are going to leave product and business for awhile and talk about the current state of practical ML for robotics. So, like, either way, mash that button.
Thanks to Darcy Grinolds for reading a draft of this.
Or as I tell my wife, “promoted to unpaid blogger.”
Most robot projects have a person whose job it is to be ready to push a big red button that stops the robot if anything goes wrong. If you are trying to be cheaper than human labor, then obviously having a full time human as part of your solution is a non-starter, but guaranteeing nothing will go wrong is also super expensive. So the trick is deciding when to take on that work.
Usually by finding places where your robot is doing things (like running perception, doing motion planning, and moving the hardware) one-at-a-time and making them happen concurrently.
Also, the ever-popular startup plan of “hope nothing bad happens”. This was unavailable to us at Alphabet, an organization who has seen bad things happen and has people whose job it is to make sure that everyone has a real plan.
By default new robot applications run at a speed so slow it causes eyeballs to drip out of human faces. This is why so many robot videos are sped up to 4x, 8x or more. I think one of the best rules Boston Dynamics has is that all their videos have to run at real time, which means they can’t hide behind "(16x)" even to themselves.