In this episode, we cover:

Featured Links: Follow Dominik on LinkedIn | Tado° | ‘How to Build an IoT Product Roadmap’ piece by Daniel Elizalde | Designing for Play – Melissa Pickering on The Product Experience podcast

Episode transcript

Randy Silver: 0:00

Hey Lily, do you like um, you know, do you like things?

Lily Smith: 0:06

Um, yeah, sure, Randy, I like all kinds of stuff, no not stuff.

Randy Silver: 0:11

I want to know if you like things.

Lily Smith: 0:15

Oh well, I love thing one and thing two. They’re so cute, but a little bit naughty. Are there other things?

Randy Silver: 0:23

Oh yeah, there’s loads of other things. There’s like an entire internet of them.

Lily Smith: 0:29

Oh, okay, I see where you’re going with this. Are we perchance going to be talking about IoT today, or are we going to stick with more Dr Zeus references?

Randy Silver: 0:40

Oh, I’d love if we could do an entire podcast about Dr Zeus. I wonder if there’s a product manager for Dr Zeus, or should I say things? If so, please get in touch. But yeah, today we’ve got someone who actually really knows their way around IoT. You know building hardware, building software and everything in between to make it all work.

Lily Smith: 1:02

And that someone is Dominic Bushing, head of product management at Tardo, and we’ll be back for our chat with him right after the music.

Randy Silver: 1:13

The product experience is brought to you by mind the product. Every week on the podcast we talk to the best product people from around the globe.

Lily Smith: 1:21

Visit mindtheproductcom to catch up on past episodes and discover loads of free resources to help you with your product practice. You can also find more information about mind, the products conferences and their great training opportunities happening around the world, and online.

Randy Silver: 1:37

Create a free account on the website for a fully personalized experience and to get access to the full library of awesome content and the weekly curated newsletter Mind. The product also offers free product tank meetups in more than 200 cities. There’s probably one near you, Dominic. Thank you so much for joining us this week. How are you doing?

Dominik Busching: 1:57

Thanks for having me, Randy and Ty Lilley as well. I’m excited to do that. How are you guys?

Randy Silver: 2:03

Excellent, we’re doing okay. We’re excited about this too, but let’s tell everyone why we’re excited. Can you just give us a quick introduction to yourself? What are you doing these days, and how did you get into products in the first place?

Dominik Busching: 2:18

Yeah, sure, I’m head of product management at a company called Tato. Tato is a Munich-based company founded in 2011. What we are doing is we are designing and building home energy management systems that help you reduce your energy costs at home. At the core, our business is an IoT business. You could say that’s kind of our legacy product is we manage your climate at home. To do that, we design and build hardware devices, so-called smart thermostats a consumer app, software as a service proposition that kind of run in this app. We do this both for B2C and B2B. So far, we’ve sold around 4 million devices. We are a European market leader. While there are some local champions in some countries, when you look at it from a pan-European view, we are the market leader.

Randy Silver: 3:19

How did you get into this stuff in the first place?

Dominik Busching: 3:22

Yeah, sure, personally. My personal background is in psychology. Actually that’s what I studied. What psychology is at its heart is finding out about human needs, drives and problems by applying experimentation. That is how psychological research actually works. If you change the human in this equation with customer, then you almost have the job description of a product manager. I didn’t know that back then, of course, but what I did know is I didn’t want to work clinically, I wanted to get into business, and that’s what I did after finishing university. What does a psychologist do who wants to go into business? He starts as a consulting firm. I did that for a couple of years and kind of learned the ropes there. At some point I realized I’m taking more and more product roles on in my consulting business. This is when my Tato’s path crossed and here I am.

Randy Silver: 4:31

Fantastic. I’m curious. This is something that’s come up for all of us, I suspect, multiple times over the years. We’ve actually done the episode on IoT before, but it was a long time ago. It’s worth revisiting this. When you bring people in in Tato, if they don’t have a hardware background, what’s the biggest thing that they need to learn or adapt to? What’s the biggest difference between someone who’s only done software in the past and now taking on hardware thinking as well? Mm-hmm.

Dominik Busching: 5:04

So I should maybe say that typically when we are hiring for a product manager, who’s then who should do hardware? We are looking for somebody who has hardware experience. But let’s assume we wanted to to bring in a software person and have that person run a Product team that develops a hardware device. So I think there are quite some commonalities and maybe it makes sense to start with those. So Every pre-pm, regardless of whether it’s hardware or software, starts with a customer problem, looks at the market, analyzes that, tries to understand what the customer need is, models of business case, quantifies opportunities to prioritize them, both in hardware and software. There’s discovery phases, experimentation to find out what really solves the problem, and there’s some iteration, continuous iteration, to improve the product so that works on hardware and software side. But there are some, I think, important differences, and those would they need adapting to, I would say. So what’s important to mention, I think, is that an IOT device is a combination of hardware which also runs software, called firmware and application, and in combination these, these two parts, kind of form more than the sum of its parts and Exactly. So what are some of the differences? I think it’s actually it’s not super black and white and there are also ways to mitigate this and also I should probably say I have I’m taking on a very consumer electronics lens here, so that might be completely different for, let’s say, a product manager who, like, is responsible to build chairs or a desk, yeah. But what is certainly different is the timeline from idea to delivery. So on the software and App side of things, we are talking about weeks, maybe even days if it’s a small thing. On the hardware side of things, we are talking months, sometimes years, from the first value hypothesis until the device really hits the shelves and you can buy it on Amazon. Also. The planning horizon that’s kind of a consequence of this is much, much different. So that is, if you look at a software roadmap, it’s typically a couple of months long. If you look at a hardware roadmap, you’re probably looking at something between two and maybe even up to five years. That doesn’t mean that this will not get updated as time progresses and you learn new things. But so many more people are depending on you and their job and their planning depends on what products you are developing and shipping to market that you just need to provide a more long-term forecast. So that is certainly a big difference. Another difference is when we look at discovery and delivery. So on the software and app side of things, it’s continuous. You can open basically every digital product management book and read about continuous discovery and delivery. And this happens in super frequent cycles on a weekly basis, maybe even daily basis if the team is really fast and agile. Development is the absolute norm these days in this area. If you look at hardware, it’s a much more phased approach. Each phase can take several months. So discovery being one phase, delivery being another phase, maybe over simplifying it a little bit. So it’s not that clear cut, but in principle that’s how it works and it’s so a little bit more waterfall, by nature, I would say. And in the discovery and delivery phase you have much more clear milestones. You have a prototype at some point or different versions of prototypes. You have your design validation prototype, you have your engineering validation prototype, you have your production validation prototype. So these are really clear prototypes with lots of dependencies and they happen in the delivery phase and that’s much less continuous than on the software side. Also, when you look at the discovery itself, it’s, of course, super easy on the software side to, let’s say, roll something out to a thousand customers test it. If it is not working, you just roll it back. Try doing this with a physical prototype. That’s not so easy and it’s also super costly, which means the degrees of freedom in principle on the software side are much, much higher. On hardware they are lower, so you can roll back changes if necessary. If there is a mishap on the software side, it’s typically not that costly. So, yeah, you can dare to make mistakes. You can even try to try out really ballsy things and see if they work. So you don’t have to do everything with a paper prototype. You just, like Google, can test something and roll it out to a half a million customers and see if it sticks. And you have much lower dependencies, also on the software side. So you can work much more autonomous as a team in your cross-functional two-pizza-sized team. And on the hardware side there’s production, there’s supply chain, there are people really like planning months ahead your new feature launch, which also means the risk is much, much higher on the hardware side. So if you fail, if you do something wrong, it’s costly fast and on the software side that’s easy.

Lily Smith: 11:02

So you’ve kind of mentioned this a couple of times. What I find really interesting about your business is it’s neither a hardware business nor a software business by itself. It’s the two combined. So I guess that makes things very difficult or more challenging, so that simplification of one or the other is now combined into the two. What has been your kind of challenge of bringing those two different operating models together and what has really helped you work together really well?

Dominik Busching: 11:41

Yeah, that’s, I think, a very good question. So I think in principle, the challenge is that things work at different speeds and at different planning horizons and you need a different, sometimes also org organizational setup to account for these differences. And most of it, kind of most of the challenges really introduced because of the hardware component. And what I find also interesting is, when you like open any book these days about product management, it’s mostly about digital product management. So actually we’ve, we’ve asked, like the gurus at the conferences, hey, how, how, how would you apply this to hardware? And they are shockingly muted about this. So we are really also to some extent figuring this out by ourselves, and I think your question was how do we kind of sink these two worlds, how can we integrate them with each other? And maybe I should first point out or like deep dive a little bit more into kind of also things that we tried and that didn’t work so well and that taught us an important lesson, and then I can talk about how we hopefully do a little bit better these days. So let’s talk about goal setting, for example. So one might apply an OKR framework to set goals for teams, to align them. You can do this on a quarterly basis. That works, for example, super well on software products because the delivery discovery and delivery is so continuous that you can just you can define meaningful end states after three months on a hardware product that has like a two year, let’s say discovery and delivery cycle until it hits the shelves. That’s not so easy because there might just be not a meaningful end state after the next three months. So we learned that this was kind of arbitrary for the teams to think of something that just fits the end of the month. So how we improved that, or how we do these days, is we still use quarterly OKRs on the software side of things on the app, but we added more longer term OKRs that define kind of relevant outcome driven milestones on the hardware side of things and they are transparent for the entire organization. So also the software teams see those and they take cues from them. So they would, for example, know hey, in I don’t know, like in nine months there’s a new version of our smart radiator thermostat I’m just inventing this hitting the shelves. So we need to take care of this and reflect this in our app and we can now plan for this.

Lily Smith: 14:43

And does that kind of filter on down to the roadmap as well? So we talk about roadmaps not having release dates on, but then presumably, as you said, the hardware plan would have dates on and would be a lot more fixed, and then the software team can then work around the new features and stuff that are coming from the hardware side.

Dominik Busching: 15:06

Yeah, that is absolutely correct, that notion. So if you would ask Marty Kagan, he would call almost every item on the hardware roadmap a high integrity commitment, because that’s what it takes actually. You need to commit to these milestones because so many people depend on it and plan for it and plan their own work around it, be it the supply chain team, when they have to order components in time, be it the marketing team, who are planning the big launch, or the sales team, because they have to brief their retail partners. So on the hardware side, by definition, every delivery shipment is a big bang moment and that’s not how it works. On the software side, we have much smaller increments.

Lily Smith: 15:57

And does the, I guess, kind of. Conversely, at the other end of the process do you have a much kind of chunkier, if you like, discovery process, so that you feel like the things that you’re delivering on the hardware side are less of a gamble and more of a definite? This is definitely going to deliver customer value.

Dominik Busching: 16:20

Yes, I would say so. So I think on the software roadmap we are a little bit more daring to put things on there, because if it doesn’t work we will find out quickly and then we can adjust. Things that go on. The hardware roadmap have to be validated a lot more meticulously and this is also how the discovery maybe differs a little bit from the software side of things. So it’s much more front loaded before you start developing, like before the mechanical engineer and the hardware engineer pick up their pen and start to do their work.

Randy Silver: 17:02

So yeah, All right, I’m curious. I’ve got a question for you. You mentioned a moment ago about how every hardware delivery, if it’s a delivery cycle, is it big bang? You have to have sales, you have to have marketing, you have to have support, you have to have all the other teams involved. I have a different definition of a product team than most people. My definition is a group of people that can ask a question, get an answer, understand the answer and make a decision based on it. So it’s, by definition, a cross-functional team and I’m wondering if, from the hardware side, everything has to be cross-functional and get everyone involved, have you managed to replicate that and take lessons from that into into software as well? Do you? Do you have true cross-functional teams with the involvement across the organization for on the on the SAS side, on?

Dominik Busching: 17:52

the SAS side we do. Yes, absolutely so, and I think it’s good that you mention kind of give a definition of what you mean when you say cross-functional teams, because I think I always realized this when I’m recruiting that when I ask candidates, hey, have you worked cross-functionally before? The answer is always yes, because just talking to UX and talking to engineering, that also kind of they can’t as is working cross-functionally. What I mean when I say cross-functionally I mean kind of these typical two pizza sized team that can work fairly autonomously with not a lot of dependencies in the decisions that they are taking. They typically have PM UX and engineering. They are relatively stable. They kind of work together quote unquote all the time they are sitting around a virtual or an actual desk and this is how we, how we are doing it basically on the on the software side of things that doesn’t work so well on on the hardware side.

Randy Silver: 18:58

Why not? What? What doesn’t work?

Dominik Busching: 19:01

So when you look at how a hardware product gets kind of delivered from idea to shelf, then, as I mentioned before, you have these long phases and different development stages and along these stages the focus shifts both from kind of the different functions in a team. So, as I said, the development is, or the discovery is, super front loaded. So you do a lot of analysis up front. Then delivery starts. So, as I said, it’s not that black and white, but kind of by. In principle the PM and the UX person are much more involved and engaged in the beginning and then they kind of phase out a bit and engineering takes over more. And in principle this is also how it works on the software side. But it happens during one week. So while the product team, while engineering is kind of still finishing up the feature that was discovered last week, let’s say, the PM and the UX designer are discovering the next, and you have this continuous cycle. And on the hardware side of things that would mean kind of that the team never really collaborates as a full team or very rarely. And then you either half of the team is kind of idle or starts to pick up the next hardware product or project and the engineering team is focusing on their work for a couple of months. But then it doesn’t need to be one team. You can rather have kind of a more pooled resource type of approach, where product management and UX continuously work together to do discovery, also with involvement and support from engineering, but you then have more kind of more these defined handover states where then engineering takes over. So this is what we also learned over time that this is probably a more pragmatic and realistic approach here. But it actually does not only work that way, on the kind of when you look at the functions in the team, it actually also kind of you will find the same challenge when you look just at engineering, because the different engineering disciplines also come in at different phases. So if you have in a cross-function team you have mechanical engineering, electronic engineering, you have data science, you have embedded software, you have cloud all these different disciplines kick into gear at different stages along the development phase, and this can span several months. And if you then don’t want them to be idle, then they should. They can already focus their attention elsewhere after they finished their their first project. And also the last comment on this they an engineer wants to work with other engineers of the same discipline and if you don’t want this team to kind of blow up in size like crazy and have, like I don’t know, 10 pizza or super big paella type of team, then you just cannot staff every engineering role with like two or three times in one product team. You have to move more towards a kind of a pool approach.

Lily Smith: 22:22

And it sounds like you’ve spent you know, I think you’ve been at Taro for five years ish, but it sounds like you spent a lot of time kind of optimizing the way that the teams are worked together and I imagine that is the timeline on that optimization is driven by the slowest moving part of the organization, so that the hardware delivery cycle Like how has that worked in terms of like, if you identifying problems with the processes or the way people are working and then, you know, doing a bit of a retrospective and deciding that you want to make changes have you been able to accelerate that at all, or has it literally just had to move as fast as the sort of slowest part of the organization?

Dominik Busching: 23:08

You mean kind of our discovery process for the organization itself, how quickly we manage to adapt or update the organization.

Lily Smith: 23:17

Yeah, exactly, so you know if you decide. For example, you said about OKRs that you tried OKRs and it didn’t quite work. Like did you have to try it for a whole year before you realized that it wasn’t going to work for the hardware team, or were you able to discover that that wasn’t going to work a bit more quickly?

Dominik Busching: 23:36

Actually two years. So we really wanted to make it work and I think it’s also it’s not like it’s a complete failure, right. So there are some things are actually working quite well and also typical hardware folks they are more used to working with, like delivery milestones, just how many of them operate, and it’s also something to just you have to try and wrap your head around to think in outcomes and you can also also along a hardware delivery timeline. You can define outcomes along the way, right that it is possible, but in the end. So this is also why it took us quite some time to improve things here. It turned out that we would never be able to get it to the same level of effectiveness as we have on the software side. But that said, we treat our organization and our processes just the same as we treat our product development, so we make small iterative changes along the way. So we didn’t try to kind of hammer it in for two years and then made a big change. It’s more kind of an adapting along the way.

Lily Smith: 24:51

I think it’s like really interesting for other teams and businesses to know, because I think we all assume that we can kind of iterate our way to a perfect process or a perfect operational setup. But these things just really do take time, and I think two years to kind of work out what your goal setting process should be in that hardware setup actually sounds like quite a short amount of time to me.

Dominik Busching: 25:19

Yeah, and, to be honest, maybe two comments on this. First of all, if my colleagues are listening to this, they will be like what do you mean? We have figured it out now? We should certainly haven’t. There are things we can and must still improve, and it’s a continuous thing because also the context changes. Right, the way hardware gets developed actually changes. There are interesting companies out there that are trying pretty impressive things. So everybody knows the SpaceX or Tesla example maybe. So they are doing rapid prototyping on big rockets and this is, of course, extremely costly and we don’t have the funds to do that. But they are trying to kind of apply the same learnings to the most complex hardware space, like the learnings from the software world to the most complex hardware space there is. And as these things kind of emerge and these new tools and processes come out, yeah, then after two years there’s also a new reality you can learn from and keep adjusting.

Randy Silver: 26:28

Dominic, I’m curious. You mentioned earlier on that you, when you talk to product leaders, they go a bit mute when you ask for things about working with hardware. And you also mentioned when you’re hiring for hardware PMs, you look specifically for people with that type of experience. So I’m curious are there places that you recommend that people who are interested in working in IoT, working in hardware, working in devices that they reach out to and look for, or is this a place, something that’s still a challenge?

Dominik Busching: 27:05

You mean if they want to come work with us?

Randy Silver: 27:09

Well, not everyone is necessarily going to be available to working with a German company, depending on your hiring practices. So I’m not going to say only people working with you, but people who are interested in hardware in general. Are there any places you’d recommend?

Dominik Busching: 27:25

To be honest, randy, I’d love to give the question back to the audience, because that’s something that I also really struggle with. So when I’m at the big product conferences product tank, product at heart what I realize is that most talks as I said earlier, most books, most of the literature online is really focused on software and SAS, and we are always asking ourselves where are all the hardware people? There’s this Fermi paradox that this famous physician who once asked hey, where are all the aliens? The universe is full of planets, it should be teeming with life, but nobody has reached out yet. So there are so many great hardware companies out there, the universe is full of them. Where are all the hardware aliens? Why don’t they show up to product at heart in these conferences? So if you are these people and you’re listening to this, please get in touch. We want to talk to you.

Randy Silver: 28:28

We’ll issue you the challenge back. Maybe it’s just something that you all need to create as a community or a conference yourself. Yeah, maybe that’s true.

Dominik Busching: 28:39

We thought about it actually.

Lily Smith: 28:43

There you go. You heard it here first the birth of the hardware mind the product conference. Dominic, we are out of time, but it’s been really great listening to your story and hearing all about the Tado team and how you’re working. Thank you so much for sharing this with us.

Dominik Busching: 29:01

Thanks for having me, guys. What’s a pleasure.

Lily Smith: 29:13

The product experience is the first and the best podcast from Mind the Product. Our hosts are me, Lily Smith and me, Randy Silver. Lu Run Pratt is our producer and Luke Smith is our editor.

Randy Silver: 29:28

Our theme music is from Hamburg-based band POW. That’s PAU Thanks to Arnie Kittler, who curates both product tank and MTP Engage in Hamburg and who also plays bass in the band, for letting us use their music. You can connect with your local product community via product tank regular free meetups in over 200 cities worldwide.

Lily Smith: 29:49

If there’s not one near you, maybe you should think about starting one. To find out more, go to mindtheproductcom. Forward slash product tank.