Product Hero is our bi-weekly series that highlights outstanding members of the product management community. These industry leaders share tips on processes, team building, how to be a better product manager, and who they are outside of their careers. This week our product hero is Daniel Elizalde, Founder at TechProductManagement.

For years there have been a lot of technical and policy-related conversations about The Internet of Things (IoT). But what does this mean for product leaders in the IoT space? More specifically, how will product and design leaders provide a consistent user experience across the entire IoT technology stack? TechProductManagement specializes in providing training for IoT product managers focused on solving these challenges.

Listen to the Show:

• Download the MP3
• Subscribe through RSS
• Subscribe on iTunes
• Subscribe on SoundCloud
• Subscribe by E-mail

Show notes:

• Connect with Daniel on LinkedIn.
• Follow Daniel on Twitter.
• Enroll in The IoT Product Manager Certificate Program.
• How to Build an IoT Product Roadmap
• A Product Management Framework for the Internet of Things

Podcast Transcript:

C. Todd: Welcome to The Dirt, ladies and gentlemen. I am C. Todd your host here at Fresh Sold Soil. Thanks for joining us today. We have a really interesting guest with us. He is the founder of Tech Product Management. Daniel, welcome to the show.

Daniel: Thank you so much, C. Todd, I’m really happy to be here today.

C. Todd: Can you just give us a little bit of your background to tell the rest of the rest of the audience what you’ve been up to.

Daniel: Definitely. I’ve been in technology for about 18 years, and my focus has been on product management. I specifically focus on connected devices, what we call today Internet of things, but I’ve been doing it for 18 years. My focus is always to work with the multiple teams involved in developing products. Today I lead a practice focused on training IoT product managers. I teach my method online. I teach at Stanford continued studies. I teach product management for IoT.

Working with designers is very important for me because it’s a big part of my framework in what I teach. In fact, I spent several years as the head of programs for a UX agency, so I am very familiar with working with designers, and it has influenced a lot about how I look into building products where the relationship between product design and development is key to success.

C. Todd: Yeah. I’m sure a lot of our audience has at least a general idea of what that is, but maybe could you give a little bit more detailed description with maybe a couple of examples that you’ve worked on?

Daniel: Definitely. IoT really is an umbrella term. It really means devices that are connected to the Internet. The way I define it is that it’s a product that has a hardware component, that has some sensors to acquire data from the real world … And it can either hard data or interact with the environment, has the ability to process that data, send it to the cloud for more analysis or other functions, then it presents the users with an interface that they can interact with. But that’s just the technology definition. In reality, it’s a set of connected devices that can sense the environment to provide some value for customers. The fact that we can connect devices to the Internet by themselves, first of all, is not new, and it’s also not valuable in itself. But the way I see if from a product management perspective, it’s another tool that we have to solve problems that we were not able to solve before.

Some of the most common examples, we can see the consumer world, things like the Amazon Echo story with Alexa, right? It’s a device that you can talk to and connects to Amazon. The Nest Thermostat, it’s a smart thermostat. But I think in my opinion, some of the more interesting applications are in the industrial side. Connected vehicles, the smart grid for energy distribution, health care devices that can sense patient information and connect it to the web. Things like that.

The thing that makes it a little bit confusing is this umbrella that touches pretty much anything that can be connected to the internet. But in reality, there’s a lot of verticals. There’s the smart homes, smart buildings, wearables, transportation, healthcare, energy, etc. And they all have their different ramifications. The building blocks are the same, but when you get into industries is when it starts getting interesting.

C. Todd: What is it that drives people to buy an IoT product? Why is this such a big thing these days?

Daniel: That’s a great question. To be honest, there’s two answers to that. The consumer world, it’s still trying to find its adoption, because the fact that you can have a connected thermostat or a connected lamp or things like that, they’re interesting, they’re cool, but they are still trying to figure out where is the true value that would make the general public buy into it, because they are more expensive, they have a lot of complexities, etc. They are struggling to pass the early adopter stages of the life cycle. Where we’re seeing a lot more traction is on industrial applications. And the reason is because with IoT, you can target the same problems that industries have been trying to figure out for a long time, it’s just that now you have this new tool to fix it.

For example, here in a manufacturing facility, you always care about having up time, and reducing failures in your manufacturing line because that affects yields and that affects the bottom line. Now, if you’re able to add sensors and add remote control and 24/7 monitoring, you can improve those numbers. It’s not trying to invent a new type of problem to solve with technology. It’s focusing on the same problems, just doing them faster, better, cheaper. So I think that in the areas where this technology can improve some of the existing problems is where we’re seeing a lot more traction and where the money is. The consumer part and smart home and all that, it’s still in the novelty phase, and we’re trying still to figure out … The companies are struggling with the value proposition.

C. Todd: Yeah. Like any good product thinking, you’ve got to have a solid value proposition in order for anyone to buy your product, regardless of what the technology is that drives it.

Daniel: One of the things I teach in my courses is that building an IoT product, it’s a lot more complex than just building a cloud or mobile application. It takes a lot more effort and a lot more money, so if you are struggling with the value proposition and what problem you’re solving, then you’re gonna run out of money fairly quickly, and you can crash and burn a lot faster. A lot of what I teach is this method on how you reduce those risks. Because yeah, you can build the technology, but it’s gonna be very expensive and you’re gonna hit a hard wall very quickly.

C. Todd: You can probably build almost anything you could imagine these days. It’ll cost you some money, but you can probably build it. The big question is, is there demand for it? Do people have a need for it? But tell us about this decision framework. How did you come up with it? Why are these elements important? And specifically highlight the aspects of how does designing UX play into it?

Daniel: The IoT decision framework was born out of my own need of trying to explain to my teams and executives and customers, what is it that we’re doing with IoT products. In my last company, I was head of product for a company doing IoT for the smart grid energy storage. There were all these components, and it’s so nebulous, and it’s really hard to put your finger on what is it that you’re talking about when you say IoT. So I started breaking things into building blocks, and I realized that there are five technology building blocks that every IoT product has, whether it’s consumer, industrial, enterprise. And those are device hardware, the device software, the software that runs inside the hardware, then a communications layer, the cloud platform that stores all the data and does analytics, etc., then the cloud applications on top of that.

Now that you have those building blocks, you can point to different things to see where you are. But then, what I realized is that there are what I call decision areas. These other things that the product managers need to think about. And I identify six areas. The first one is UX, then you have data, business, technology, security, and standards and regulations. And the idea is, when you see the diagram in the link that you’re gonna share, it’s a matrix. So you have to evaluate each layer against each of the building blocks of the IoT technology stack.

For example, in UX, you have to evaluate what user experience and what needs are you solving at the hardware level, at the device software level, at the communications level, cloud platform level, and cloud applications. And the reason why I decided to put UX as a first decision area is because I am very passionate about the value that UX brings to the table. It’s not, as you know, only about aesthetics. It’s about the deep understanding of the customer needs. So if you can’t articulate that, which a lot of the companies that I work with have trouble with articulating what is a need and who are the users and what is the value proposition, then nothing else works. You can’t really plan for the data layer, and you can’t build a business model around it, and you can’t select a technology. So the first layer of the framework is answering the question, who are my users and what problems am I solving for them?

Then, as the products get more complex, like industrial products, you can’t guarantee that you’ll only have on user. These products in general tend to be very complex, so you will have a lot of different users. And you might have different users at the hardware level versus at the embedded software level versus the cloud applications level. So the framework from the UX perspective not only helps you understand where the building blocks are, but also identify all the possible users that you might have in your system, and therefore, start planning and building personas and prioritizing the use cases, etc. It’s a way to wrap your head around all of this complexity of IoT. And really the simplicity of the framework is that it breaks it into consumable chunks that then you can work with different teams to create your product strategy.

C. Todd: Yeah. Daniel, it sounds like one of the things here that would be really valuable would be to really understand the experience … What is the design experience with all of these components in it, but then also, what’s their experience today without this technology, without this IoT device in their world? How are they currently experiencing the world without this technology in place?

Daniel: Definitely. I think that it goes even farther from the product because once you develop a product, one of the things that IoT enables is the ability to have recurring revenue because of how you can turn hardware into a SaaS model, because you are able to be in touch with the hardware all the time and do metrics, etc. But then that affects other departments in your company. Now building is affected by that, and sales now has to sell something different, and marketing has to position something different. And that’s also service that you have to define and have to figure out how your product is going to affect all these other departments internally and externally.

The other aspect that I think is interesting is that when you start getting, let’s say, into industrial products, one of the characteristics of IoT products is because they have a physical component, you have stages in the customer life cycle that you don’t have in a pure software play. For example, you have installation, deployment, provision. And when you’re talking about industrial applications, the person that’s gonna be installing the device might be different than the end user might be different from the people doing the analytics might be difficult than others. So all of a sudden, you have all these personas that might not interact with each other, and they all have their own journey, and then you have to figure out how they fit in the process.

As a product person, you have to prioritize a return investment on how much development you do for each of your personas. You might not have enough budget to create the best experience for all the different players, but I think what I always highlight by using the framework is, if you at least identify them and understand their needs, then you can actually make the decisions of whether you want to invest in them, when is the right time, when is the right return investment. But this gets you the overarching perspective of who all are you serving.

C. Todd: How does this affect decisions from a practical perspective on roadmapping. How does it affect this where you can’t just send an automatic update. Maybe to your device software you might be able to do an over-the-air update, but some of your hardware, once it’s shipped and out of the building, you’ve got a timeline. And once it’s going to deployment, how does it affect that kind of road mapping, and can you still get away with that kind of now-next-later roadmapping approach that a lot of software teams do?

Daniel: That’s an excellent questions, and that’s one of the things that companies jumping into IoT struggle with, because they’re either coming from hardware, which is very waterfall by design, and it has to be to some extent, then companies coming from the software perspective that want to be agile, so to speak. And IoT’s somewhere in the middle, because the first time you launch something out, when you have to match the length of time it’s gonna take to build the hardware with all the different components of the software. So the first time around, everybody needs to align, and you have to have … I know a lot of people don’t like this, but you need to have a project plan and you need to have some sort of timeline for when things are gonna be fixed. Then once you have the first unit out there, each of the teams, let’s say the app team, the cloud team, they can push new features and patches out there.

But everything has to be scheduled for two reasons. IoT products are really more like a system, so you gotta make sure that everything works together throughout the whole stack. So you have to do integrated testing. You have to make sure that everything flows correctly end to end. Because if you don’t, and one team, let’s say the cloud team, pushes something that breaks something in the embedded software, then the whole thing breaks. So that’s a big problem.

And the other problem that you need to figure out that has to do with timelines and road maps is the two last layers of the IoT decision framework, which are security and regulations. Security’s a big challenge today with IoT, mostly because people are not doing it. As a product person, you are responsible to make sure that happens, so that needs to be part of your plan. And that’s gonna slow down some things, and you have to make sure that you do penetration testing and you do all these different things. Then on top of that, you have the regulations decision area, where if you’re putting hardware out there, you might need compliance with the FCC, and you might need all these other permits and other things that you need to make sure they are in place before you release the nest thing. And if you are launching a new patch on the cloud, and you are in the medical industry, is that gonna be HEPA compliant? Does it need to be? How does it affect the timeline?

That’s why managing IoT products is so complex. Because there are all these different moving parts. What I always aim to do with my courses and my frameworks is show the ecosystem and make sure people understand all the different dependencies. After that, there’s no right or wrong way to do it, as long as people do it with the understanding that, okay, if we want to push software every day to our cloud-up, that’s okay, but understand the repercussions and understand how everything fits and understand how it affects the ecosystem.

C. Todd: You can’t be very point-based and only thinking about, for example, the design. You have to be thinking about a much broader context. When we think about product management, there’s that classic three-circle Venn diagram of there’s the technology, there’s the design, and user experience, then there’s the business outcomes, and those three things come together to make a good product. But it seems like IoT takes that to an extreme because there’s a lot of components in that technology side that are going beyond just software. There’s hardware, there’s firmware or device software as you said, there’s even a cloud platform beyond just the application itself. Then how do you get them all to talk to each other? How do you get this communication layer, especially if you got a meshed network of devices out in the field? How do they talk to each other so that you can actually get that data back and provide that data to a user?

Daniel: And there’s an aspect of design that I think is also very important by understanding your industry and the context of your customer. For example, let’s say that you are going to build an IoT product that’s gonna provide readings on the vibration of a train. And you’re gonna analyze all that data to provide certain value. The design of the product itself might just be a box that goes somewhere hidden in the train. But all of a sudden, it’s gonna be vibrating a lot, so you have to account for vibration, for noise. Let’s say you want to install a product that goes on a building, but it’s outdoors. All of a sudden you have to deal with outdoors and ruggedness and all those things.

Then there’s another component that has to do with size and weight. And sometimes we don’t think about those things, but if you’re installing something in a building that’s gonna go on the roof, and it turns out that the roof structure does not support it in the average building you want to install, that’s a design challenge.

Then there’s also the design for security. One of the big challenges with IoT security is that there is a cyber-physical component. The devices are at arm’s reach, so usually you can just grab them. An attacker could just grab your box or whatever you have. So the design has to account for that. Hide all the different ports, lock it, make sure that it can be installed higher so that somebody can not grab it. Things like that. So all of a sudden the design challenge is embedded within a lot more than just the experience to the end user.

I think ultimately, the experience to the end user is impacted by this. If your device is designed in a way that it can be tampered with, that’s gonna improve the experience of your user ultimately, but it’s a different way of thinking about it. That’s why I think the designers and the product managers need to work closely together to understand all these different variants. And usually it’s a multi-physical team. You have industrial designers, and you have UX designers for most of the software part and the research, and the hardware research is different. Embedded software design is different. Then, of course, understanding the end application. Are you gonna go into mobile or VR or voice? That’s just the tip of the iceberg.

C. Todd: When I was a PM, people were saying, Oh, yeah, we’ve got fine engineers, back engineers, and a classic web or mobile app. ‘Cause you’ve got your front end, your back end. But with IoT, that expands to firmware, hardware, maybe mobile specific, maybe even a cloud, Dev Ops kind of thing, so many other different layers. What are the things that a good product manager has to differently in IoT than say for a company like Slack or Facebook or Twitter? What are the differences there that a product manager has to think about?

Daniel: That’s a great question. I think that the key is to understand the overall stack. That you have a combination of software and hardware in these five building blocks that I mentioned. Depends on the size of the company, you might have one product manager looking at all of them, or you might have product managers specific for each of the layers. I think it’s part of understanding that you can’t be an expert in each of the components. Usually people are really experienced in hardware or in cloud software or in embedded. But the more important thing is that product managers need to understand how the system works, what are the components, what are the interfaces, and what are some of the challenges that happen across layers. Then work together with the subject matter experts in those other areas to make sure that they build a cohesive product.

The way I see it, you’ve heard the term T-shaped? The way I see it is that the product manager part, that’s a given. I even move it from the T. But in IoT’s, the horizontal part of the T is the understanding of this five layers of the IoT technology stack. Then the vertical part is one of them. You need to understand the whole stack, how it works, and from a UX perspective, from a security perspective, from a business perspective, etc. Then you need to be very deep in one. So you can be an expert in hardware, but you understand how the whole stack works form a product perspective, not from a technology perspective. That’s how I see the T happening in IoT. And as you see, being a good product manager, that’s a given. IoT are so complex that you’ve gotta have that down and try to think about these other things.

C. Todd: Exactly. Do you have an example of a project you worked on that maybe you can talk about, what’s your T and how did you interact with the rest of the team to bring this product to life from a product perspective?

Daniel: Yeah, definitely. I can tell a little bit about the company that I was working for before I launched Tech Product Management. I was head of products for a company doing smart batteries, these big batteries that you would install in a building and they would store energy when the energy was cheap, then release it when it was expensive. And they had all this functionality, and it was an end-to-end system. They had the batteries themselves, the embedded controllers, the embedded software, the cloud applications. Because I was head of product, I managed the end-to-end stack. I had a team of product managers that were handling each of the different areas, and the way that I organized my team is that I actually hired a PM for each of the layers of the technology stack. I had a hardware PM, I had an embedded PM, a cloud PM, and applications PM. That was when I had a full team, but if I didn’t have a full team, then I would work with subject matter experts that could act in a PM capacity to help cover those gaps.

That’s how I’d organize a team. Then we would work together to figure out a road map that was holistic for the product, always focusing on what is the value from a customer perspective, what is it that we’re gonna add to the customer in terms of value. Then using this framework, we would go, okay, in order for us to provide the ability for the customer to see the energy readings of their building on their smart phone, what does that mean? Then you walk the different layers of the stack, because it means that we need a mobile app. It means that in the cloud we need to have this data. It means that data needs to make it there. It means that we need to have these types of censors and we need to process the data this way. That way we would have a holistic theme of what is it that we’re gonna build, then each of the vertical teams can have their individual road maps and say, Okay, how do we actually make this happen? What are the interfaces to make sure that data flows? And off we go.

Part of the challenge was not only from the customer perspective, but also to align other departments that might not be as technical, including executives or marketing or sales, on what it takes to build this and why this is something that might looks simple. It’s gonna take six months and a full engineering team to do it, so by having this framework and being able to point to things, it really helped with the communication and get everybody aligned on why are we doing what we’re doing.

C. Todd: Right. If I do the math for a minute, there’s five layers to your technology stack and six decision areas. So it’s 30 points that are all consideration you gotta at least think about before you put something on your road map. Is it really 30? You really gotta go through all 30 of them as you’re starting to think about things on your road map? Or is it a classic case of it depends, there are certain things that are focused only on one area? Tell me more about that, ’cause when I think about that I was like, wow, this is a lot to do in terms of getting something on your road map. It’s certainly thorough, but I can imagine people looking at this and saying, Okay, we’re not gonna do all of this ’cause we don’t have all the time. Where am I gonna only focus on certain elements? How does that play out with your framework?

Daniel: Yeah, that’s a very good point. What I have to say about that is that the framework doesn’t have to be very time incisive. You should be able to get in a room with the necessary heads of the departments or stakeholders and go through the framework in half an hour and understand all these different things, and have a plan of action. So it’s not like it’s gonna take six months of planning. It’s just a tool for you to, have we think about this, have we thought about that, have we thought about that? And when people start telling me about cutting corners, We’re not gonna do this part, the reality is that whether you think about those things or not, they’re going to impact you. If you say, Well, we’re not gonna look at the security part for the cloud because we don’t have time. It’s gonna bite you.

So it’s up to you whether you want to take the time now and think about those things and have a conscious decision of what you’re gonna do or not going to do. Because if you ignore it, that doesn’t mean that those things are not still at play in this complex development of IoT products. So my approach has always been, better know what you’re dealing with. Whether you decide to tackle it or not is different, but go through the exercise, uncover all these things. I can give you some examples of some of my students that have gone through my course, and after going through the framework, they realized that their business plan wouldn’t hold up because they hadn’t considered the security parts. Or they were in breach of some regulations and that wouldn’t work. Or their customer was better served with a different thing. So by saying, I don’t have time, and launching into building something, you are short-circuiting your product strategy, and you’re gonna run into those problems later when you have invested time and money, when you could’ve avoided.

And I think that is a core role of the product manager, is to prevent those risks and get alignment. Whether you decide to do A or B doesn’t matter, but have you thought about it, and is the company behind you when you’re taking certain decisions because it’s well informed?

C. Todd: Yeah. I think that’s a good practice for any product or designers, is to think through things rather than trying to cut corners. Clearly, I think speed to market has definitely been something that’s been emphasized in recent years, and it’s certainly been proven value to a point. What I think some people are failing to realize is that, in the desire to get things out quickly to market, it’s like taking on some kind of debt. You’re basically putting stuff on a credit card, and at some point, that bill is gonna be due, and you’re gonna have to figure out how to pay that back because you’ve got something. Whether it be you cut a corner or you used a particular framework, there’s gonna be something that’s gonna come back and bite you if you don’t think it through up front.

Daniel: Yeah. I agree. And I think one of the challenges with IoT is that it’s actually way more expensive than other types of products, so that debt is gonna be significantly bigger. One thing that I also recommend is take advantage of all the technology tools that we have today. It is a lot easier to put things together to demonstrate the concept. For example, if you have gone through the framework and you have all your decisions, and you want to validate a certain idea with customers, some companies, instead of wanting to truly validate the prototyping, they jump directly into optimizing for cost and mass production. They start engaging contract manufacturers to have runs of tens of thousands of hardware devices because they can lower the cost to make sure their business model works. But in reality, you still don’t know if it’s gonna get that adoption. Right now, because there’s so much interest in IoT, there’s a lot of prototyping platforms for hardware as well that can give you a great kickstart and help you put something in the hands of customers and make sure that there’s willingness to pay and the adoption is gonna be there.

Then once you start getting the traction, and you’re moving out of the early adoption stages, then you can start optimizing for cost. At that point, you can start doing the miniaturization of components and the expensive piece of your layouts and runs of millions. Because you know that it’s gonna work.

C. Todd: Yeah. Let’s talk about it. That’s a good topic. We didn’t necessarily put it on the agenda, but what are some of those ways to prototype IoT concepts, and what are some of those platforms? We’ll certainly put links into the show notes. But what ones that you’ve had experience with or seen success maybe with your students in using in getting out to market? If you have any specific stories, we’d certainly love to hear them.

Daniel: The same concepts that you can use in software, you can use in hardware. You can do a lot of prototyping through sketches in paper, wireframes, so you should be able to do the same with some of your hardware. You can have cardboard prototypes, you can have clay models, you can have wooden prototypes and just see how it feels. Then, as you continue to move on, there’s a lot of cheap platforms that you can use like the Arduinos of the world. Those kind of computer in a board platform that you can still put in a box and it’s not gonna be industrial grade. It might be bigger, it might be clunkier, but it takes you through those stages.

I think for industrial applications, it’s very important to model it. The cheapest way possible, I used to do cardboard prototypes, because if you’re selling something to a building, and you’re thinking you’re gonna install it in their basement, then it turns out that the thing that your engineering team comes up with doesn’t fit through the door … And it has happened to me, that’s why I’m telling you. You’re in trouble, right? So try to prototype those things.

I think there’s always a little bit of a fear of, what are my customers going to say? I can’t come in with a cardboard box. In reality, early in the process, you are doing product and research work. You find your champions, people that are interested in working with you through it, and you work with them with the understanding of we’re working on this together. That’s kind of my approach.

C. Todd: That’s good. And that’s very much a good practice overall for designer practice. If you’re in discovery mode, the discovery mode is different than the execute mode. Discovery mode, you’re testing and prototyping and experimenting with different concepts of things, but once you’ve validated that these are the right things to build, you go into execute mode, that’s when you could have the, alright, we know this is the right thing. We valued it, it’s useful, we can definitely see demand. Now let’s go into execute mode and either ship the code, or actually design the actual form factor, miniaturize the sensors, etc. That’s a very different skill set you need from that upfront, prototyping, dare I say lean startup mentality of making ugly prototypes that we heard at Mind the Product. Make an ugly prototype. It’s okay. It’s not about the prettiness of the prototype. It’s about does it satisfy the need that the user has.

Daniel: And I think the other component that I’d like to add is, when you decide to go with a prototype or even a first launch production, it’s different with hardware and software in that sense. The hardware has to be a little bit more forward thinking, because if you need to update the hardware once it’s in the field, it might not be possible or it might be really expensive. Just to give an example, in some of the industrial applications, let’s talk manufacturing, energy, you usually have contracts that are 10 years, so you bring your device and it’s gonna be sitting there for 10 years. If you were thinking of upgrading it with new sensors or you realize that all of a sudden the processor is obsolete to your user software etc., you’re stuck. So you need to have a plan for a maintenance plan, or just to over design the hardware for future proofing it, even though you might not enable it immediately. I’ve done that with my products.

Tesla is a good example. They put the self-driving capacity in the hardware way before the software was ready, ’cause they knew that they couldn’t re-deploy the cars. So they had that foresight, and when the software was ready, they started doing over-the-air updates and that functionality was ready. That’s kind of the forward-looking thing that the product team needs to work together with designers and engineers to figure out the things that can be changed quickly, yes you do that, but once you have a prototype and some adoption and you’re gonna start running your first units even if they’re not final, what’s the path of longevity? I think it’s an important thing to think about.

C. Todd: Yeah. I remember talking to a colleague who used to work at Sonos, and he was talking about, Okay, you’ve got the hardware, you’ve got the firmware, and the web and desktop apps. When it came to the hardware, you have to make this trade off of how far in the future is this thing going to go? Because once it’s shipped, you can only do firmware updates and updates to your software. You can’t go change the chip in the box. So there has to be this trade off of how fast of a chip do you need today? How fast of a chip do you need in three to five years, assuming that the life of a product is going to be five years? And how much does that cost and how to weigh out that spec the right way so that they can make the right decision for components was really critical.

Daniel: It is. And I think that a key role of the product team is to have the conversations with multiple departments to decide on that. For example, if you are saying that you have a device that needs to be on the field for 10 years, but you think that it’s gonna be technologically obsolete in five, that’s okay. But then you need to have an agreement with marketing that they’re gonna position that correctly with a customer and they expect that. Then you have to work with probably your field services team, like how are you gonna go and replace it in five years, and how does that fit in your business model. You have to plan for all those things in advance to at least have an idea of, when you do that and you have that strategy, is it gonna work. The last thing you want is that, Oh, this thing was supposed to be there 10 years. It’s obsoleted in three. Now we have to figure out how to get them back. That’s where the lack of planning can bite you.

C. Todd: Yeah, and it speaks to the different kind of mindset that a product manager in IoT has to have, is you still need to have that agile, flexible mindset, but you do have to have a much more rigorous, thoughtful plan for where you’re going with your product.

Daniel: Yeah. And one of the things that is interesting here is that one of the things that is characterizing IoT is the different models. I mentioned before the ability to do a subscription model. A lot of companies are going away with a CapX model, and instead of charging big for the hardware, the hardware is free and all you charge for is a recurring payment. That means that you are obligated, so to speak, to keep providing value through the life of the product. Otherwise you don’t get your recurring payment. That means that you have to think about all those things in advance.

Before, hardware companies just said, Well, it’s a one time transaction. They buy it, throw it over the door, we don’t care about it. But now, not only do you have the ability to monitor that device, and the ability to create a closer relationship with your customer, but you’re changing the business model to depend on the satisfaction of your customer through a longer period of time. So all of that needs to be baked in, in all aspects of your product.

C. Todd: Is there anything that we haven’t covered that you want to cover in the next few minutes?

Daniel: That’s one thing, and this is me getting a little bit philosophical, I think that the IoT revolution is more than just hype. We’re seeing a lot of adoption and it’s just inevitably where the technology is going. Just like today, when we hear about somebody doing some software as a service, we automatically assume that it’s cloud-based and it’s probably gonna have a mobile app, and now they’re probably gonna be using some sort of voice interface. Those are becoming table stakes. So I believe that five, 10 years from now, if not all, a lot more products are gonna be connected products. That puts a lot of burden on product managers to understand what it takes to handle an IoT product. And that’s gonna have effect not only on the products we’ve built, but also our careers. Because if we are not ready to tackle this next level of evolution of not only the industry, but our careers themselves, I think we’re gonna be in trouble.

My charter is to help with the knowledge that I’ve gathered so far, provide a way for the product manager profession to inch into what I’m seeing as an inevitability of … This is where we’re going. This is where the industry’s going, and I want us to be prepared so that all the ground we’ve gained to show how much value the profession can bring continues to accelerate as the technology trends move forward.

C. Todd: Fabulous. Daniel, thank you so much for spending some time with us today. This has been a really cool conversation. Can you just tell us a quick little bit about your course? Let’s at least talk a little bit about that. If somebody wants to learn more, we’ll put a link in the show notes, but just give us the quick overview of what that offers.

Daniel: Great, I appreciate that. I have an online course. It’s called The IoT Product Manager. You can finish it in seven weeks, and it really walks you through all the different decision areas that every product manager needs to do. It comes with a workbook that you’re gonna be working on throughout the course, and after that, you’ll have all the decisions that you need so that you can start driving your road map, your strategy, working with teams. It’s a combination of 18 years of work that I’ve put into structure and approach, a step-by-step approach, if you may, on how to tackle this. And it has the US component and the business component, and I talk about business models, and I break down the technology implications, and security, etc. It’s the same material that I teach at Stanford, and now you can have it online as well. It’s a great next step if people are thinking about either going into IoT product management. Or most of my students are finding themselves that their company is going into IoT, and they were seasoned PMs, and all of a sudden they feel like there’s a gap. So I look forward to working with those people and seeing if we can accelerate your transition into IoT.

C. Todd: Cool. And they can get to that through techproductmanagement.com. We’ll put a link in the show notes. Looks like you got a couple of free lessons that somebody can sign up for as well.

Daniel: Correct.

C. Todd: So if you’re not at Stanford University, you can access this expertise material right online at that website. Daniel, founder of techproductmanagement.com, thanks so much for your time today. It’s been a real pleasure.

Daniel: C. Todd, thank you so much for having me. It’s been great.

The post Product Hero: Daniel Elizalde, Founder at TechProductManagement appeared first on Fresh Tilled Soil.