Lessons learned the hard way: Robotics

Carving out a path to scale robotics quickly

We’re robotics nerds. We envision an abundant future in which robots augment human capabilities and effort — think about this as AI for real-world tasks. Autonomous package delivery, full assembly of your Peloton bike, or even automated construction of a home.

In some ways, robots are all around us. There is automation in almost everything we use and touch, from your car to the plates off which you eat. However, automation is largely prevalent in repetitive, high-volume tasks. We call this ‘industrial automation,’ where the value of automating the task is so large that we invest in customized, tailored hardware and mechanical approaches to tackling a specific problem. These solutions are typically not generalizable to any other task and involve little to no ‘intelligence.’

When we talk about robotics, we are typically referring to automation solutions that involve some intelligence: computer vision, prediction, and path planning. As a result, these solutions can be nimble in response to less structured environments and a higher diversity of tasks. Think of a fully autonomous forklift vs. one that follows magnetic strips, or a pick-and-pack solution that can grasp any object at a retailer vs. a machine that is purpose-built to package fruit snacks.

We are proud backers of numerous robotics and autonomy companies: Blue River Technology (agriculture and weeding; acquired by John Deere), Fabric (fulfillment), Canvas (construction drywall), Third Wave Automation (warehouse forklifts), Gatik (trucking), and Machina Labs (manufacturing, sheet metal forming). After working with these companies for years and even huddling to share learnings at our “Innovation Endeavors Robotics Club,” let me tell you that it is hard to build robotics companies. Given the blood, sweat, and tears poured into bringing robotics into reality, we thought we’d take a step back to share some learnings from our experience. Our hope is that shared learnings help clear the path a bit, making it a little easier for emerging founders in the space. As our partner Scott Brady likes to say, aim to only make “original mistakes.”

1. Be enabled, not driven, by emerging technological capabilities (said differently: customer-focused) → Robotics is a space in which we often see founders driven by technology. They may have demonstrated something novel in a lab and are looking for a way to commercialize it. While this may work occasionally, it often doesn’t, usually due to a lack of product-market fit. Like in any market, we encourage founders to be customer-driven. Ideally, companies are built at the intersection of a strong need on the customer side married with a solution that is only newly possible based on emerging technical approaches.

2. Pragmatism in what is feasible now (and ambition for what can be down the road) → In our experience, getting robotics to required performance levels (more on that below) is often more challenging and time and resource-intensive than teams think. For example, we were all hoping we’d be riding autonomously everywhere by 2020. To that end, the right place to start building is often with a slightly more structured problem and environment than you might think, even if the long-term ambition is to build towards a fully autonomous future.

3. Don’t let hardware be the bottleneck → Building startups is hard enough. When you’re dealing with hardware, the reality of supply chain timing can become burdensome. Practically, if you only have 18 months to deliver on key milestones between financing rounds, a 6-month delay can be meaningful. As a result, we’ve seen companies be most successful when they are thoughtful and prescient around managing build vs. buy decisions. Typically, this means taking advantage of off-the-shelf, commoditized, predictable components and equipment wherever you can and, at least in the early days, bringing everything else fully in-house and under your own control. You want to minimize exogenous risks here and control your own destiny as much as possible. Note: one additional advantage to off-the-shelf hardware is that it is often far easier to finance.

4. Think deeply and creatively about your business model → While there are certainly some known categories of business models here — hardware, technology licensing, services, and full-stack — I find that, in practice, there are many shades of gray. Think creatively about what makes sense for your customers, your business profile and financials, and what is feasible in terms of technical readiness. There is no one right answer here.

• Match your business model to customer preferences → Said differently, sell the way your customers want to buy. There was a time when RaaS (robotics-as-a-service) was seen as the primary way to build robotics businesses. The reality is that different customer segments have wildly different ways of purchasing here. Some may be comfortable consuming and implementing technology themselves while others would require a fully outsourced service; some may have a preference toward investing in capex, while others want to substitute existing opex spend. I would not bet on customer behavioral changes, so how does your solution fit into existing customer workflows?
• Margins matter → This may be obvious, but cannot be understated. The higher margin your solution, the higher valuation multiple your company is likely to be able to command and the more capital will be available to you. The business model you choose is likely to play a role in defining margin.
• Recurring revenue helps → While certainly not required — and, again, potentially in conflict for customer purchasing preferences — recurring, technology businesses (vs. services or hardware ones) tend to be rewarded better and more scalable.
• Operations are hard → Coming back to RaaS, the reality of providing services is that you will need to build non-trivial operations. Running equipment for customers requires significant staffing and a very different type of expertise and culture to make such operations successful. While this may appear to be the ‘easy part’ on paper, in our experience, it can be incredibly distracting from your core competency of building technology.
• Transitions over time → Lastly, at least in the early days, your ideal business model may not be feasible technologically. For example, if you want to license technology for customers to operate, they will likely require a level of product robustness that takes time and resources to achieve. As a result, we often see companies consume their own technology in early customer work and pilots, moving toward customer licensing over time as the product hardens.

5. Be clear-eyed about PMF (production > pilot) → The robotics landscape is rich with pilots, but very few of those have converted to scaled contracts and operations with customers. Industrial customers are keen to try new solutions, but also have incredibly stringent requirements for deployment (see below). The end-markets and contract sizes can also be incredibly large, so pilot revenue can be quite high (e.g., >$1M) and deceiving. In this space in particular we see a strange phenomenon where revenue can outpace PMF, while usually it follows. To that end, we strongly recommend being brutally honest with yourself around whether you’ve found true, scalable PMF — you’ll typically know it when you see (1) product being used in a production environment (vs. just in pilot), and (2) customers using your solution repeatedly (without your involvement) and/or scaling and expanding use and contract sizes from the initial scope of work.

6. Understanding and building toward performance → In order to avoid getting stuck in pilot purgatory, we encourage teams to really understand customer performance requirements. The level of robustness (e.g., speed, uptime, accuracy, reliability) required on the customer side can be quite meaningful. The earlier you understand these requirements, the better — you can orient toward operational KPIs from day one and/or figure out ways to engineer whole systems around your performance (e.g., only route items that can be picked at a high reliability your way).

7. Getting the right team at the right time → The early days of robotics companies are, of course, very engineering heavy. During product development, the vast majority of the value will be created by engineers, from mechanical engineering to AI & computational software engineers. There may already be pretty significant team requirements relative to software peers due to both the scope of the problem and diversity of disciplines required. However, per the above, we also see (1) industry knowledge and experience, and (2) commercial, GTM functional expertise as extraordinarily valuable. Deep understanding of and relationships with customers can be incredibly useful, even in the early days, to ensure high PMF and clear product and performance requirements. While it may make sense to wait a bit longer than software companies to scale a sales team, we often see most success where there’s at least one industry-focused, product type person in the founding cohort.

Note that these lessons are largely relevant for companies working on solving a real-world problem with robotic automation, usually involving hardware to do so. Increasingly, we are seeing another breed of company: pure infrastructure or software plays to serve the space. The key questions for those companies probably look more similar to traditional software companies, especially those selling to the industrial sector. We believe there are exciting infrastructure companies to be built here in serving the incumbent customer aiming to accelerate automation and long-tail or high-mix use cases.

We are eager to hear what you think — let us know if you have other learnings to share from building in robotics! And we’re here to fund the next generation of robotics companies, hoping the load is a little lighter.