Ira Renfrew (iRobot) on Agile & Hardware

Alex:
Welcome to the Interdisciplinarian. I’m your host Alex Cowan and I’m here today with Ira Renfrew, who is a senior manager at iRobot. Thanks for joining us, Ira.

Ira:
My pleasure, thanks for having me Alex.

Alex:
So, you make robots! Some of our listeners may not know what iRobot is. I have a Roomba, a robotic vacuum, and I love it, but not everybody knows about it. Can you tell us a little bit about what you guys do at iRobot?

Ira:
Yeah, sure. I think a lot of people have seen DJ Roomba or Roomba Beer Pong recently, which has been great publicity, but, iRobot is actually a pretty old company, we’ve been around over 25 years. We now have a focus entirely on consumer robotics. We’re best known for our Roomba, robotic vacuum cleaner. We also make other robots that help you take care of the home.

Alex:
One of the things that I thought would be most interesting for us to talk about is the use of innovation techniques, some of the kind of methods that we talk about a lot here on the Interdisciplinarian in the context of a hardware company and hardware and kind of low level software. It’s pretty complicated, I would think to make it work. Can you talk a little bit about how you guys make room to experiment with those kind of long lead times? And, what I would assume are relatively complicated components?

Ira:
Our product development cycles are quite a bit longer than I think what people are used to, certainly in the software world, even if you look at CPG or some of those other product related businesses. I think the first part of making room for innovation is just being patient, it takes some time. I think at the corporate level another thing is having the financial room to pay for innovation. Having the margins that can support innovation. Then I would kind of split it. There’s technical innovation and some of that low level software you’re talking about, we have a very large R&D team, who’s working very hard on improvements and advancements in the software and also the hardware that powers our robots.

Then, I think the other place where we make innovation is really more on the product side. In my mind, that comes down to having a really deep understanding of what people are going to do with these robots or what needs they have in their life that are unmet and then designing for that. It doesn’t always take some kind of advanced technology to meet their needs- a lot of times it’s more minor changes to the product itself… even, in some cases, the assortment of products that we have in a given market. I think a good example of that would be, for a long time in China we were really promoting our vacuum cleaners. After doing deep ethnographic research in homes to understand how Chinese families were cleaning their homes, we saw that actually there was a significant emphasis on mopping. That led us to change the balance of our portfolio to emphasize our mopping robots and that’s been very successful for us.

Alex:
What kind of teams do you send out to do that kind of research? Do you go do it yourself or do you have a dedicated design team? How does it work?

Ira:
It’s a mix of things. We do try to send out interdisciplinary teams to get out there and do the research. At least in the work that I do, I really try to maintain an emphasis on this overlap between engineering, design and product and have that well represented early in the development cycle. We’ll go out there, a lot of times our user experience team will lead the research. I’ll be there as well and then we try to bring engineers along. Then when we come back and we do the debrief or we do a brain storm around what ideas could help solve these problems. It’s really helpful for everyone who’s in the room to have been on site and actually had that context in person rather than just getting sort of the research synopsis after the fact.

Alex:
How do you guys decide what ideas to test?

Ira:
I think there’s some ideas that are just very difficult to test, so sometimes they don’t get tested. I say we sort of prioritize based on which ones feel like we could get to soonest in terms of technical hurdles and then, which ones seem like they would have a business case behind them. When we’re early in the process, this can be a really quick swag of getting a sense of what the business case might be by looking at adjacent categories or just doing some back of the envelope calculation. Then we prioritize if, OK, well of those ones that we think there’s actually a path to building it and there’s probably a promising business case. Which one’s might we be able to hack together in some kind of prototype as quickly as possible?

Then I think I mentioned about prototypes. A lot of people talk about 3D printing and how that enables prototyping and the hardware space. That has been an amazing tool, but I think sometimes it put too much emphasis on the hardware itself. At least in the case of robots, a lot of times what you’re prototyping for someone to learn about whether it’s a compelling product idea, is actually the experience, not necessarily the device. One way that we get out earlier to test, is by thinking about, how else can we create that experience for somebody rather than having to build it with a piece of hardware that we would create ourselves? That can really accelerate things.

Alex:
That’s great. Do you have any examples of that?

Ira:
One way to do that is to look at competitive or similar products and see if we can modify it or hack it to get to the experience that we want. Another way is to think about simulating it. A little while ago I was doing some research on different user needs in outdoor home care. We had gone out and we had spoken to people, asked them- What are the jobs to be done? What are the things that you guys do outside? We were looking at, not just rake the leaves or pick up sticks that have fallen down- these are very task oriented things. We were also looking at, you know, enjoy it with my family, play a volleyball game, those kinds of jobs to be done as well. Then we came back, did that kind of prioritizing that I talked about and put together prototypes. For one of the prototypes we took a dolly, a cardboard box, a big plastic bin and a remote controlled car and nailed it all together, put some duct tape around it to clean up the appearance of it and put a remote controlled car underneath it. Then used the remote controlled car to drive that contraption around to create the experience of a outdoor yard helper, without having do any sort of robotics work. It was probably a four hour job and a trip to Home Depot to get it up and running.

Alex:
What would be an example of something you were trying to observe there?

Ira:
What were trying to observe was- how does that prototype interact with the environment and how do people interact with the prototype? We took it to, there was one guy who did a lot of gardening, so we thought ‘This product might be great for him’, to just kind of help him out and follow him behind and he could throw the dead headed flowers in there. What we found that the pathways between his flowerbeds were really narrow, so this contraption that we had put together actually couldn’t navigate alongside him or behind him to help him out. We very quickly got this feedback of, no, wrong size, maybe we need to go back and think about downsizing it for people who have these sort of flowerbeds that are closer together. Obviously, that’s a sample size of one and we’re always careful about how much do we draw from that, but we’re able to extrapolate the people who might find this useful also might be the people who have raised beds that might be close together, so maybe we need to take another look at that idea itself.

Alex:
I think you mentioned, when we talked in the past, the importance of Wizard of Oz prototypes with robotics. Can you talk a little bit about, what you use it test? How you use it? And, what it is?

Ira:
Wizard of Oz, that’s the term, you got a guy behind the curtain who’s running the show, but everyone who’s viewing it, it looks and feels real. The example that I just gave didn’t really look and feel real, because it was covered in duct tape and pretty much hacked together- that was much earlier. One of the nice things about using the Wizard of Oz approach is that you can get to meaningful feedback from consumers even before a robot is ready to do the type of thing that you want it to do. Actually, one of the lowest fidelity versions of that is to make a concept video. In the concept video, show the robot doing what you intend it to do, whether that’s an animation or in some kind of modified live video. In showing, it in video you start to make it real for people, so I’d say that’s sort of the first level of Wizard of Oz.

The next level, when you’re in the home, I could give you an example. We recently launched our first WiFi connected robot and it also has a camera that helps it navigate. One of the benefits of having the camera to help navigate is the robot is now able to move in straight lines instead of doing the random bounce navigation that Roombas had done in the past.

Alex:
I’ve noticed that, between my old and my new Roomba.

Ira:
Okay, cool.

One of the ways that we could’ve Wizard of Oz’d that before writing all the software that would, and it’s a pretty complex set of software that grab these visual markers and then turn that into navigation guidance. One of the ways that you can Wizard of Oz that is to use a remote control and be in the consumer’s home, have the robot on the floor and drive it back and forth in straight lines just using a remote control. What we find is that people very quickly will lend you their imagination and go along with that. Sometimes they don’t even notice someone’s remote controlling it and they think the robot’s doing it themselves. Sometimes they notice, but they get caught up in that moment of, Oh, cool here’s the robot driving straight lines, and then give a reaction to that whether it’s, Ah, I love it, it’s going in straight lines. Or, Well, you know maybe I prefer the random bounce. That’s another example of how you can Wizard of Oz something and drastically reduce the time to get feedback and also drastically reduce the amount of effort you put in to validate that it’s a good idea.

Alex:
We’ve talked about the use of agile and how does it work and not work with hardware. Can you talk a little bit about how you use agile and how you unpack things to make them soluble for working in that way?

Ira:
Definitely. Sort of going back to those long product cycles that we have, part of what drives that is in the hardware world, and I’d say probably even more in the robotics world where you have these integrated systems, there are somethings that just take a long time, and they take a long time to mature. As we’ve been thinking about adopting agile and where to make the most use of it, there are definitely some places where doing it a two or three week sprint can be helpful as kind of management tool, but you’re working on a task that’s like a four month task and that’s just sort of the way it is. There are a lot of other things that can be easily broken down into smaller bites and can be accelerated, so while there might be some elements of the robot that are moving at a slower pace, there are others that can kind of be in the fast track or the express lane and within two or three weeks you can do a really quick cycle.

An example would be wheels on a robot that I was working on recently. We wanted to improve the traction of the wheels, we were just generating different 3D prints of wheels, testing them and quickly iterating and being on that sort of agile framework fits nicely with that quick cycling on some of these modules.

I think the other thing I would say about adapting agile to the hardware world, it forces the product management team and the engineering leadership to take a really hard look at what can be chunked off, both in terms of the product development, but also in terms of the risk burn down. Particularly for me in product management, I think a lot about what’s the consumer risk burn down. What are the specific risk areas that we see related to this robot? How can we, within a sprint or two sprints quickly burn that down and move on from it with confidence.

Alex:
What I find a lot of the time is that it takes a bunch of work by teams and I’ll tell you, it’s surprising where this resistance to doing things that way comes from. It’s not overt resistance, I’ve never met really anyone who objects to doing these things in principle, but you’ll find people who just don’t believe that we can unpack things this way. If we unpack it, we’re gonna break … all these bad things are going to happen- probably because they’re used to doing things in a certain way. I wouldn’t pigeon hole that as a thing that I’ve observed particularly in engineering or product management or business. I mean, I’ve seen it come from all these different places. Have you experienced that to any degree? If so, what are the strategies that you’ve used to help show people how you might unpack those things?

Ira:
I think the thing that was most powerful, for the team that I’m working with now, a team that has fully adopted agile… One of the most powerful things at the beginning was to sit with another team, but then the first team within iRobot to adopt Agile in a hardware setting and to get their testimonial. It was engineering peers and sort of trusted colleagues saying, Yeah, this works and actually we love it. That melted away a lot of the skepticism and the resistance. I think the other part of it, which kind of the agile mindset is just do it, right?

Alex:
Mm-hmm (affirmative).

Ira:
Was to just, we set it up with a team of, Okay, we’re going to do this for several iterations and then we’re going to have a touchpoint and see how it’s going. We intentionally did several iterations, because we knew the first couple iterations there’d be some learning pains and it wouldn’t go so smoothly. We wanted to get it to where it felt more like a cadence. Then we did a checkpoint with the team and people wanted to continue. That’s kind of unlocked in the team, also this willingness to experiment. An example related to agile is we started with two week iterations and then at some point there was some comments, Well, we wish we had one more week. That would allow us to fit some of these things in more nicely. Then we had a bunch of people saying, No, no, no, two weeks is great. So we said, Fine, let’s do two iterations of three weeks each and see what we think. In that case what we found is at the end of the two iterations, they were three weeks each, the team wanted to go back to the two weeks. We took that decision and back we were to the way that we were. It’s really opened up the ability to experiment, which has been great.

Alex:
That’s fantastic.

Well it’s some fantastic perspective from a product that is not the obvious place to iterate quickly. Ira thank you so much for joining us and giving us your perspective.

Ira:
My pleasure, thank you.

Alex:
Thank you again for joining us. If you’d like to check out some material on how to do some of these things, feel free to visit us on Coursera and our Agile development specialization, which is Bit.ly/hiagile, or if you’re interested in product management specifically check out our digital product management course on Coursera, which is Bit.ly/digi-prod.

Thanks again for joining us.