I’m Tanay Jaipuria, a partner at Wing and this is a weekly newsletter about the business of the technology industry. To receive Tanay’s Newsletter in your inbox, subscribe here for free:
Hi friends,
A few months ago I got a Matic, the home robot that vacuums and mops on its own. Last week they shipped voice and gestures, so you can now say “Hey Matic, clean the kitchen” or just point at a spill and Matic handles it. It was almost 8 years since they first demo’ed it internally and a reminder of the demo to deployment gap in robotics.
And with all the discussion around robotics and getting to deployment, Matic is a great company to learn from. They took on a market that already existed but had seen little innovation with a different spin on it and are now shipping American-made consumer home robots at real scale and are in over 10,000 homes.
I had the opportunity to sit down with Mehul Nariyawala, the co-founder and President of Matic, and talk through some of his hard-earned lessons from the Matic journey so far1. There are a lot of lessons for anyone building in robotics and frankly beyond it. I’ll cover 7:
Start from the customer problem
Pick the form factor from first principles
Absorb complexity in software
A great demo gets you 20% of the way
Deployment data is the moat
Manufacture for iteration
Customers adopt incrementally
1. Start from the customer problem
Mehul’s first company Flutter, which he co-founded with his co-founder at Matic Navneet, let you control iTunes and Spotify with hand gestures through a webcam. It hit #1 in 73 countries, but as he notes it was never going to be a business and was eventually acquired by Google.
“You quickly realize that no one wakes up in the morning and says, today I’m going to buy gestures. It’s a really cool app, but not necessarily a product or a problem.”
What he took from that, and sharpened at Nest, is a filter about which markets to enter. New markets make customers ask “why do I need this?” (GoPro, Fitbit, Vision Pro). Existing markets only make them ask “which one?” Nobody asks why they need a thermostat.
A corollary to that was that the best existing markets are the tedious ones. Nest’s cameras drew 20 competitors within 6 months of launch. Nest’s thermostat, which required compatibility with 50 to 60 years of HVAC systems, went arguably over 15 years without a serious challenger.
Robot vacuums looked the same way to him. 15% of homes owned one and iRobot generated $700M in revenue in 2024 without meaningfully innovating for two decades.
“Our thesis has always been that customers don’t want robots, they want solutions to their problems.”
The temptation in robotics is to lead with the capability, since the capability is the hard part. The filter at founding for Mehul and Navneet was to work backwards from a existing customer problem, and to go after an existing tedious market where the customer problem is established enough that people are already trying to solve it in some way.
2. Pick the form factor from first principles
Matic entered a category where hundreds of products looked identical and were all disc-shaped and relatively low profile, and shipped something that looks nothing like them. Matic has a squarish shape is double the height.
Mehul’s framing for why:
“Form factor is basically a function of what problem we are solving .. Disc robots were built as disc robots because they didn’t have any intelligence. They were literally like a blindfolded robot, bouncing around the room to cover everything.”
A blind robot needs a shape that resists getting stuck, and a circle can pivot on its own axis. Precise 3D vision removes that constraint, which is what let them shape the robot around the job instead. Matic has a square shape so it actually cleans corners and sides. Its cameras sit at the vantage point of a crawling child looking down.
I think this one is particularly apt to many robotics companies today. Many are picking theoretical embodiments without factoring in what is needed to do the job they are trying to accomplish. The form factor matters a lot and should be chosen with the task or tasks in mind, and the trade-offs considered. Questions about whether it should have wheels or legs or be stationary, the degrees of freedom in the arms, etc should not be taken for granted.
3. Absorb complexity in software
Matic made a big bet to approach the problem a la Tesla rather than Waymo. They bet that cameras plus algorithms should be enough. A Matic robot has 5 cameras and the cheapest NVIDIA GPU they could buy, roughly $150 of cost, in the black crown on top of the robot. They felt additional complexity in hardware would make things more challenging to scale:
“A single sensor you add in hardware, assume three software engineers on the flip side. More sensors, bigger the team. More sensors, more calibration. More sensors, more complex the supply chain, higher the BOM cost, more complex the manufacturing. Complexity rises exponentially with each sensor you add. So we made a bet that if you want to build a profitable, economically viable thing, we have to absorb complexity in software.”
This makes things at the start much harder but the scaling much easier. They grinded for a long-time to get the mapping algorithms better, but now benefit from a somewhat simpler hardware and have built up a strong software muscle with a product that continues to get better every few weeks through new features delivered entirely via software updates.
On architecture and approach they’re pragmatic rather than religious. They tried classical SLAM, neural approaches, and hybrids, and kept whatever hit the accuracy bar, which has drifted them steadily toward end-to-end:
“End to end sounds really cool, but you don’t get end to end on day one. You try a bunch of different things and then you figure out what it is, and over time it shrinks into end to end because now you know which techniques work. Otherwise it’s a bit of a mirage.”
4. A great demo gets you 20% of the way
Matic’s first “clean this” gesture demo ran in fall 2018. It shipped to customers last week, almost 8 years later. Mehul’s framing of that gap is a reminder of the gap between a cool demo and getting to production in robotics:
“In software, if you get to GPT-3, ChatGPT is maybe just 20% more. In hardware, if you have a great demo, you’ve basically got 20%. The rest productization takes 5x effort.”
Productization here means the platform, firmware, the operating system, edge observability, end-to-end testing infrastructure, data infrastructure, the app and doing it all reliably.
In Matic’s case, the bar is also high because consumers are far less tolerant of failure on tasks that seem trivial to them:
“We don’t really go to school to learn how to vacuum, or how to hold a glass, or how to fold clothes. These are trivial to us. So the more trivial the task to human beings, the less patience they have for robots to make a mistake. We get an email if a single popcorn is left behind, saying your robot doesn’t work.”
That bar for Matic is about 99% for alpha testing and 99.9% to ship to production. Every company will need to figure out their own bar given their use case but worth remembering that each each additional nine takes roughly the same amount of work as the last one.
If you don’t yet receive Tanay’s newsletter in your email inbox, please join the 10,000+ subscribers who do:
5. Deployment data is the moat
I’ve written in the past about the mix of data being used to train and improve robotics models and systems, and Matic also used a mix with now the focus being on their deployment data.
They started in simulation which was very useful while getting going but eventually they needed to get real data in a large number of homes. On sim and teleop, Mehul notes:
“They’re great to get to 80%, but you cannot cross the sim-to-real gap until you have real data. And real data is not about 20 homes or 30 homes.”
Matic took an interesting approach of doing everything-on-device first, and allowing users to opt in to share error clips or manually record certain error scenarios. Now, 60% of customers have opted-in to help Matic improve by sharing error clips, giving them the edge cases / failures they need to improve their systems.
Ultimately, its these edge cases that are most valuable today in improving the product and something you can realistically only get through deployments. In the case of Matic, it involved edge cases on how to handle homes with wall-to-wall mirrors, indoor water fountains, a fish pond set half a centimeter below the living room floor with live fish in it, indoor basketball courts, transparent plastic furniture, and other things that it may not have encountered before.
Those edge cases get labeled within about 3 weeks (sometimes they receive them well curated and labelled too) and go back out as improvements through over-the-air updates, which is how the robot keeps getting better.
6. Manufacture for iteration
Matic assembles every robot in Mountain View. The first reason is speed:
“The moment you have a CM somewhere outside, they are going to need two or three months of notice versus having everything inside in the same place, having mechanical design engineers right next to the manufacturing engineers. The communication and feedback loop is really fast and we can iterate really fast.”
The second is that scale surfaces problems that don’t exist at small volumes. A 1% issue is one robot when you’ve built 100, and a thousand robots when you’ve built 100,000. Owning the line means you find those and fix them in weeks rather than quarters, which is why the product keeps changing while looking identical:
“Externally it’s the exact same hardware but Internally we’re constantly improving the hardware, making it more reliable. We started shipping in November of 2024, and I think now we’re already on a fifth or sixth generation of internal hardware.”
In relation with last week’s launch, the microphones were in the robot from the first unit shipped a few years ago and were ready to be used when the software caught up.
7. Customers adopt incrementally
The obvious question for a home robotics company is why not build the general-purpose robot straight away. Matic’s answer is a very practical one around consumer adoption and feasibility given price.
Mehul quotes Tony Fadell, his old boss at Nest:
“Customers do things incrementally. You cannot get them to leapfrog.”
They felt that customer’s weren’t ready for a >$2000 robot in the home, given how few household purchases cost more than that. Matic knew from the start that the end game was Rosie the Robot from Jetsons or Alfred from Batman. But that wasn’t the right starting point. Instead, a better vacuum cleaner in the home which was an existing market and had customer adoption and could be priced under that $2000 mark was.
Mehul compares it to how JK Rowling wrote the first chapter of the first Harry Potter book and the last chapter of the last one before writing the rest. Matic knew the first chapter (Floor cleaner) and the last chapter (Alfred/Rosie), and will get there incrementally with products along the way.
From a technical perspective as well, they want to do things in sequence, almost modeled on how a child may learn. The goal of the initial Matic robot is to be best-in-class at perception, mapping, navigation and earn the right to be in customer’s homes.
Closing Thoughts
What strikes me most about the Matic story is how little any of this was shortcuts. They took six or seven years to ship, picked a category with very little new innovation and spent most of that time on problems that don’t demo well.
If you’re building in robotics or physical AI, feel free to reach out at tanay at wing.vc. And if you have any comments or thoughts, feel free to tweet at me.
Quotes have been lightly edited for clarity where applicable
Well written, looks like reading a human writing after long
Thank you, Tanay, these are very useful lessons.
What strikes me is how universal most of them are. And even for lessons that look more specific to robotics (such as the form factor and demo vs productization), it isn't too hard to find analogies in domains beyond robotics and tech when you think enough about it.