Close

What’s a Wizard of Oz Prototype? iRobot’s CTO Explains

By Alex Slawsby |  December 29, 2021
LinkedInTwitterFacebookEmail

How do you keep improving on the world’s most successful robot sold to consumers?

As the makers of the Roomba robotic vaccuum — more than 35 million of which have been sold — iRobot knows it can’t rest on its laurels. Since the Roomba was first introduced in 2002, other players like Samsung, Dyson, and SharkNinja have begun marketing their own robo-cleaners. (iRobot also sells a coding robot, Root, and a wet mopping robot, Braava.)

We spoke to iRobot Chief Technology Officer Chris Jones about how the company keeps tabs on important technologies emerging from academia and the startup world — and the role that “minimum viable products” play, even if they’re held together with duct tape and controlled by a Wizard of Oz in the next room.

iRobot CTO Chris Jones

How is iRobot organized around emerging technology scouting?

As CTO, I spend my time thinking about our technology strategy and roadmap, and how that relates to our broader strategy and product roadmap. I consider what’s going on outside of our walls, and how that might support what we’re trying to do and where we’re trying to go. There are also a variety of technology leaders throughout the organization that I lean on, who are on top of what’s going on in academia, and who are participating in technical reading groups and attending conferences. Then there’s strategic investing. We’re always looking for early-stage companies that might be of interest to us, so I work with the iRobot Ventures team to scout startups and to stay close to what the investor community is doing and thinking.

We have three to five key technology areas that are critical to our long-term strategy — and that may have nothing to do with robotics.

How do you figure out which emerging technologies to prioritize?

We prioritize technologies that will create benefits for the consumer when we integrate them into our products. They also need to be technically feasible to implement, and viable from a business value standpoint. Currently, we have three to five key technology areas that are critical to our long-term strategy — and that may have nothing to do with robotics. Computer vision and machine learning are of interest, for example. These are areas in which we are — or intend to be — world-class. Our technology leaders within our organization — as well as those leading iRobot Ventures — know those areas are priorities and keep them front-of-mind as they organize their thinking and our scouting activities. We also scout for new technologies adjacent to those areas that might help us further extend our competitive advantages in those areas, or protect us from disruption. 

I always prefer to test MVPs with consumers. We may or may not have taken products that include duct tape into a home.

After you decide to explore a technology further, how do you track the progress of that exploration to figure out if you’re on the right path or not?

Outside of some strategic investments that we make to learn more about a technology’s potential, we’re focused on tracking how, where, and when a given technology will impact the value or differentiation of our product to the consumer. For those technologies, we tell our teams to try to answer the hardest, most impactful questions first. We tell them to focus on the “elephants in the room” — the things that will ultimately determine if the technology will make it into a product — not the easiest things, or the 10 things they’ll want to do to polish the product, for example. 

This interview is part of our December 2021 research project, “Delivering Value Through Emerging Tech and Innovation.”

If and when they get past those big rocks, then we think about how to create and test MVPs [minimum viable products.] And I always prefer to test MVPs with consumers. We may or may not have taken products that include duct tape into a home. Sometimes, the MVPs are partially functioning and sometimes they’re fake. Sometimes, it could be a “Wizard of Oz” MVP, where someone is in another room driving the thing around with a joystick.

Naturally, the exploration process is different for hardware and software. For hardware, the bar is pretty high, as the technology has to be mature and risk-reduced before we put it into a product. For software, we can be much more agile and release things as private alphas, full betas, or full releases. My bar for software testing like that is lower — ultimately, “Thou shalt not brick the robot.”

I want [our technologiest] to listen and hear what consumers are saying, to make sure that we’re prioritizing those things that will generate that consumer benefit.

How do you make sure that you don’t spend too much time exploring a technology that ultimately won’t pan out?

There are a few things we do. We tackle technical feasibility as an internal exercise, and try to develop the belief that any feasibility problems are solvable, even if [they’re not solved] yet. If we don’t develop that belief, we don’t move forward. 

I also make sure that our technologists are part of discovery research. I want them to listen and hear what consumers are saying to make sure that we’re prioritizing those things that will generate that consumer benefit. If we don’t believe the benefit will be there, we don’t move forward. Now, sometimes consumers can’t fully understand the vision, and so they may say “No, I don’t want that” even though they’ll “want that” eventually. In those cases, we “tune the knob” a bit, so the technologists hear what the consumers say, but keep what they say in perspective. 

Then, if a team has been working for some time and they’ve not been able to satisfactorily answer a key question or deal with one of those “elephants,” we’ll draw a line in the sand and say, “Hey, if you can get the data or achieve the metric we’re seeking, maybe we’ll keep going, but if not, we’ll need to focus on other things.”

Finally, I’m distinctly not a fan of “throwing things over a wall”; there’s just so much difficulty in that. So our digital teams frequently take what they build all the way to release. On the hardware side, I make sure that product development folks are involved early in the process with the expectation that they will be part of the broadly built-out team. In my 15 years at iRobot, we’ve tried many different incarnations of how to transition things, and “having walls up in order to throw stuff over those walls” is not a great recipe.

LinkedInTwitterFacebookEmail