Global IoT Product Design
Full transcript below:
Adrienne Selko:
Good afternoon and welcome to today’s IndustryWeek webcast, “Global IoT Product Design: Increase Success with Products, Teams, and Customers.” It is sponsored by Arena. My name is Adrienne Selko and I’m a staff writer with IndustryWeek.
Before we begin, let me explain how you can participate in today’s presentation. First, if at any time you are having audio difficulties or slides are not advancing, simply hit your F5 key to refresh your webcast console. If you have any technical difficulties during today’s session, please press the Help button on your player console to receive assistance in solving common issues.
This webinar technology allows you to resize a presentation by clicking the maximize icon or dragging the lower right corner to enlarge the window. We welcome your questions during today’s event. In order to submit your questions to today’s presenters, simply type the question into the question window on the left-hand side of your screen and hit the Submit button. We’ll be answering as many questions as possible during the Q&A session that will follow the main presenter. But please, feel free to send in your questions at any time, and we’ll add them to the queue.
Please, also be aware that today’s session is being recorded and will be available on the IndustryWeek website within the next week for you to review. You’ll be notified by email when the archive is available. On your console, the Arena logo is hot linked. So if you want to visit their website during the webcast, you can click on the logo and a new window will open. This will not take you out of the webinar.
I’d like to introduce today’s speakers. Today we have two professionals of the product world joining us: Kathy Davies who is currently the Managing Director of the Life Science Lab at Stanford University and a long-time veteran of the Silicon Valley tech world. Kathy’s expertise lies in the application of design thinking to product innovation. Heatherly Bucher is currently a Senior Product Marketing Manager at Arena, the sponsor, which is a comprehensive product development platform providing … Sorry, Heatherly’s expertise is in working with teams to build business, process, and technical functionality to discover sane, sustainable solutions.
Today Kathy and Heatherly will be discussing how IoT product development is the same and yet different for more traditional product design efforts, considering both process and team aspects. For today’s session, we want to make the webinar an interesting, more natural experience for the speakers and you, our audience. So I’ll ask a few starter questions for the speakers and then I’ll have an interactive discussion.
We hope at the end of our time together you will have some takeaways on how you can increase your team’s chance of product success, whether your company produces only IoT products today, has a blended portfolio, or is just starting in your IoT product journey. How can you increase your team’s chances of product success? Let’s begin by talking about the landscape a bit.
Heatherly, the products we are designing today require new consideration than before because we’re living differently. How differently and what really has changed?
Heatherly Bucher:
Adrienne, thank you for the lovely introduction and for moderating today. I’m really delighted to be here with Kathy, whose work at Stanford I find fascinating. The variables we need to consider in product design today—views differ, even if our product is an IoT or IoT-enabled. Before we talk a little bit about that, let’s take a quick mental journey of the world 30 years ago to capture how much has changed.
30 years ago, what would a day in your life have looked like with the technologies and infrastructure at the time? Let’s say we’re taking a road trip across country. At that time, if you were going to take a trip across country, you bought a map, perhaps asked a friend with a AAA membership to have a triptych book made for your route, if you remember the triptychs. As you drove, if you were alone, you’d be pulling over or checking the map to figure out routes or turns.
But maybe you’re lucky enough to have some company on your road trip, who, that person gets to serve as the navigator. Also gets to probably manage the music selection by changing out the CDs. As you’re hungry, getting ready for a pit stop and some gas, you watch service-information signs as the exits come up and also the billboards. I think the billboards back then were maybe better than they are today. And you look to figure out what was at each exit, and you then decided—do I go with a chain or give the local cafe a try. You pull into the parking lot hoping that that local place is open, maybe at an odd time like a 10:00 a.m. on a Sunday. You get gas at the station. Maybe your Conoco or Sinclair with the green dinosaur, and you pay with your gas station card because most gas stations and a lot of stores didn’t accept credit cards 30 years ago.
On your trip, if it’s maybe around 1990 or later, and you’re one of the people who have a pager that then finally supported the wide area network, maybe you get a page. Calling to work you find a phone booth. And as you call in to work, you find out that the team is having problems with the word processing files maybe done in WordPerfect. They can’t print them off of the five-and-a-quarter [inch] floppy disks that you left. The computer is giving an error of noise from the operating system. Your team may be stuck either recreating the work or just suffer for the week, maybe lose some production downtime or a loss of the client that week until you get back.
We could continue kind of reminiscing about what life was only 30 years ago. Film, cameras, processing centers for film, video rental stores, and more. But hopefully we have the idea. Even if you’re a bit younger and you didn’t experience this time firsthand, many people say that the pace of technology itself is accelerating. But that’s actually debatable. It still takes approximately eight years for 50% of the U.S. population to adopt a new technology that requires a monetary investment. However, cellular Wi-Fi networks, the internet, smartphone saturation, and cloud data structures are now increasing the number of [inaudible] that technology impacts. So therefore, our lives, the way we work, live, and importantly, the way we create product has changed and continues to do so.
Think of a cross-country trip today. What would it look like? Most likely quite a bit different. You would need one physical product, the smartphone, and a myriad of apps and technologies using Wi-Fi and cellular networks would be all you would need to navigate all those activities and tasks on that road trip. Today we want to look at what holds true from before this latest wave of technology in product development and what needs to change.
Kathy Davies:
So, as Heatherly mentioned, times really have changed, and they keep on changing. If you listen to Moore’s Law, the idea that circuit density increases every two years, it really means that we have the opportunity to pack more computing power into every aspect of our life. And so IoT products can be anything.
So that then begs the question of where we really need connectivity and what makes a good IoT product. So we have to ask ourselves, do we want our refrigerator to tell us that we’re out of ice cream? Maybe we’re on a diet. Maybe we don’t want that information. Do we want our phone to ding when there’s a suitable mate nearby? Do we want to be tracked at all times? And where is connectivity useful and where is it frivolous? And where might it be an invasion of privacy? So this is now the designer’s job. The designer needs to understand user needs and values that are at the core of making those decisions.
So what makes IoT products great? IoT products at their best allow simplicity to hide the complexity of the machinery of all that computing power and connectivity. So let’s look at Nest here. Nest is a great example. It is famous for taking an old technology that’s thermostats and making them cooler and easier to use. And this is all in the service of decreasing energy use and increasing comfort. So that technology took something that folks considered onerous, adjusting and programming their thermostat, and maybe even not worth doing, low return on investment, and it made it simple and actually quite delightful.
We’re also at an age where the problem is rarely too little data. We’ve got infinite choices. I don’t know about you guys, but we’re getting ready for the start of school. And even just looking for a school backpack for my children yields thousands of search choices. So design is paramount because context becomes everything. When are users going to interact with products? What kinds of designs can you make that allow the user to feel that the product is made for them and specifically? A well-designed product feels like it fits seamlessly in the environment where it’ll be used and it expresses the user’s identity in that context, and the features highlighted fit that user. The product is really going to guide the user’s behavior and it’s going to enable the user to succeed in a way that might have been difficult or impossible before.
Think about, too, how connectivity enables new resources. At this point we have traffic information that is live. We’ve got resources and location and object information on our phones that was previously secret or only known to locals or insiders. As Heatherly was mentioning, when we’re on our road trip, now we can tell if that local café—not only is it open, but is it any good, how do people rate it?
In the future, smart cars are probably going to be able to send driving distances from one another and assist in traffic regulation, but even now we’re seeing traffic data change as a result of this new technology. People are able to actually plot their routes based on real-time traffic information. And what that means is traffic data is a new resource and people are willing to pay for it.
With the advent of self-driving cars, it may eventually even be more cost-effective to own a share in a car rather than a full car because, after all, why would we pay for time when our car is parked? It might be better, then, to let someone else use that car during that period and defray the cost.
So as designers we need to realize that our design goals may shift. We’re no longer designing for product use in a vacuum. We are now designing the product to enable users to utilize new resources, or own one, but more efficiently.
And we’re fundamentally changing the way that product providers can connect with their customers. Looking at Fitbit here, you’ll realize that designers now need to think not only about the point of purchase but how does the product interact with the user over the year, second year, even the fifth year of the product use? With Fitbit, are people using it right when they first buy it? What are they doing with it? Where are they using it? What opportunities are there to expand brand loyalty? And what kind of follow-on services could we have that result as [inaudible] of this connectivity? So designers are now thinking beyond the point of sale and building a vision for their full customer journey.
Heatherly Bucher:
Kathy, some great examples of IoT products and what they do best today. I have two teenagers at home, so I might be ready for the smart fridge because I seem to be perpetually out of certain products.
Looking ahead to the next several years at some growth projections for IoT, I find them pretty amazing, frankly. As I mentioned, the benchmark for adoption of a new technology platform that requires monetary investment is still eight years for 50% of the population to adopt it. But time is ticking in the IoT world. The clock has already started. Although it’s a nascent technology and spans many industries, the companies that figure out the design questions, navigate technological maturity curves, meet customer demands, will be the ones who grab the bigger part of the market in the future.
To better understand our audience today, we’d like to give you some opportunity to give us feedback in some polls. For this first poll, we want to see where the audience is in the race for the IoT market share. You’re going to see on your screen a question. Please select an option and submit. The question is what percentage of your products are IoT/IIoT-enabled today? None, up to 24%, 25-49%, 50-74%, or 75% or greater. And if you select an option and click Submit, we will then see the answer in a minute.
What I do find amazing going back to the last slide in those projections, industry is almost projecting 30 billion connected devices by 2020, just a short two-and-a-half years away now. What’s interesting to realize is, that is a 2x growth from where we are today. It was an estimated 10 billion connected devices.
So let’s take a look. So in our audience today, Kathy, we have a lot of companies joining us that aren’t yet IoT-enabled products, and then we have some that are. It’s good to hear. It’s good to see people who are interested in IoT products and joining the call.
Kathy Davies:
Absolutely.
Heatherly Bucher:
Indeed, we can look at a similar poll of Arena customers that we did recently to kind of compare with our audience today. Now Arena has over a thousand customers, and 25% of them are producing IoT/IIoT-enabled products in their portfolio. Now, we asked these customers what percent of their shipping products were IoT-enabled. And we found that 63% reported that half or more of their products were IoT-enabled. And we found this to hold true across all our customer industries, high tech, medical, energy, automotive, industrial, as more and more of our customers are entering the IoT world.
Another survey asked a different related question. This was a survey from last year by Gartner. And Gartner asked what percent of the organizations were using IoT in their business to produce their products, and found that only 28% were currently using IoT, indicating there is a lot of opportunity in the B2B IoT space as well.
Now Kathy, you’ve done a lot of work in setting product-designing direction. How are you seeing initial product definition change with the advent of IoT and what tools continue to best capture IoT product requirements?
Kathy Davies:
That’s a great question. Regardless of what kind of product you’re building, whether it’s IoT or otherwise, it’s really critical to capture product requirements and communicate them clearly with your design team because there’s nothing so disheartening as to miss a critical ship date based on bad team communication and a lack of understanding of what the product’s goals are.
So, it really all starts with user story. And when I say user story here, what I’m really talking about is not just user stories in the agile scrum methodology, but as you’re thinking about design thinking, the first step in design thinking is empathy and need finding. So really understanding what the stories of users are. And by stories, I mean their needs, their values, what they think and feel about how they interact with your product.
Some need stories that you can gather, and I’m going to talk in a minute about how you can gather user stories well. That then yields your functional requirements and it also allows you to generate pictures and mock-ups of what your product will look like. And those pictures and mock-ups are critical—not only in communicating to your team what the product is going to be like so that they engage their own creativity and are able to really build the product to the nuance that you are expressing, but also to create an idea in the mind of the people of what the future with this product in it would look like.
IoT gives us the opportunity to capture additional requirements over time. So with IoT products we start thinking about, hey, it’s not just a single purchase event, did they buy it or not, but now we can look at data as the products are being used. So the product requirement document now needs to include the full life of the product in a new way. So we start asking ourselves these questions: What data is worth collecting? Because, as you know, writing code and installing sensors can really increase the product cycle so it can increase your time to market. And so the question is what to include? Where does data allow you to drive the product road map so that you can support additional products and services and new features? And maybe this even extends to platforms—what kinds of platforms might you support? Are you going to be supporting Allegra? Are you going to be supporting Apple HomeKit, Google Home?
And then, when and how will data be used to drive your product’s evolution, because sharing this with the engineering team is critical. Often some basic foundational work is needed in the initial product design to make or break your future capability. So, engineers are the ones who are going to build those structures that allow seamless data collection and use of that data. And they’re also going to be the ones who are going to be able to create the basic functionality that can allow you to easily integrate new functions without huge rework.
And then finally, we need to be thinking about data security. It’s an increasingly important issue. So designers are now responsible for considering not only if they can collect the data, but whether they should. And if they do, how they will protect it from misuse. Designers must also consider what safeguards need to be in place to enable safe communication to distributed devices. We’ve all maybe seen that movie “I, Robot,” so we might be thinking about the concern about rogue robots and hacking. But less sexy than that, we need to be thinking, too, about how will we store our data responsibly and how will we protect individual privacy.
IoT products enable us to have a different kind of product development. It’s more rapid, we have a more rapid product evolution and we have this ongoing contact with customers that needs to change the way we define our requirements.
So I want to double down on this need-finding piece, this creation of the initial user story. Some of you may use surveys. And surveys are a great way for you to aggregate data and allow you to group your users by lead or intent, maybe binning. Some of you might create user profiles. In addition, I really recommend that you use interviews. At the Stanford d.school, we say that 10 user interviews can give you more actionable insight than hundreds of survey data points. And I really believe that’s true.
Neurological research by Chip and Dan Heath, who’ve written the books “Switch” and “Made to Stick,” shows that our forebrain isn’t always in charge. Often our emotional hindbrain is key in driving our decisions. So interviews are a critical part in understanding your user. It lets you get at what their emotional drivers are and what the pain points are that your product can address.
There are some other methods of user-need finding too. Shadowing and observing your users is often very helpful. If you’re able to follow your user around and observe them in the context where they’re going to use your product, you might notice work-arounds or behaviors or unusual things that they do that your users themselves might not be aware of. And those observations can allow you to ask more interesting questions in your interviews and really understand why your user does what they do.
There may also be extreme users that you want to contact or that you want to look at. These are the people who are your real product advocate, people who use your product more than anybody else. So you want to ask, “Hey, what are these outliers doing that’s different than a casual user?” And there might also be true product extractors. So, understanding what it is that they object to and whether or not you want to address those objections is important.
Let’s say you do all this and you have great user data. It all comes down, then, to synthesis of data into user stories. And frankly, this is where the magic lies. The synthesis is probably the hardest part of the designer’s job. The what’s important about what you heard and what are the critical needs that you want to design around.
In the IoT context, there’s a particular tool that I like to use to visualize and consolidate these findings. And I want to tell you a little bit about it because I think this is really important as you look at the product lifecycle over time. This tool is called the user journey map. The user journey map is a useful tool because it illustrates the user stories over the timeline of the product. It combines the user profile with a detailed timeline. So it allows you to map the user experience prior to interacting with the product, through the purchase of the product, through engagement with the product, and all the way through the lifecycle of the product with the user.
And it really allows you to visualize, hey, what’s this user thinking, what are they doing, what’s happening, what are they feeling at moments along this timeline. It gives you touchpoints throughout the product journey for you to think about where you might interact with the product and with the user. So what happens, where would data collection augment that product experience, and what does connectivity buy you in terms of support, prevention of issues, and perhaps even product line extension?
IoT data collection then allows you to validate your assumptions and to add data to this map. So this becomes a living document. You can ask yourself, where are people doing these things that they’re doing on their product journey map? Where are they consuming power? What are the failure modes? What function calls are happening? Are there particular events that always precede customer service calls? Are there periods of time that lead to increased power consumption or even failures? And what function calls are being most used most heavily when the user first buys the product and then as they use the product over time, perhaps becoming an expert user? And all of that is then synthesized in a way that your team can rock.
So you’ve got this aggregation of data and you can start drawing analysis and drawing some inferences about what it means towards your product roadmap. And then that might enable you to run some prototype tests because one of the beautiful things about IoT is it allows you to communicate with products real-time. And that means that you can run A/B tests or test chunks of functionality with subsets with your user by pushing some small pieces of code and then analyzing the result. And then you can plot that on your user journey map so that this becomes a living communications tool with your team.
Now user stories are the thing that drives the PRD, the product requirements document, and it’s really by boiling down the user journey map, and all the data that you collected during the need-signing, into functional requirements and prioritizing the scope and development effort of your team so that you can orient them to action.
So, this is kind of the critical piece, getting this all down into a document that people can use. And these IoT PRDs may evolve. So documentation of the change in these PRDs is critical to keep those teams aligned.
Heatherly Bucher:
Kathy, I love the discussion on capturing product [inaudible] and particularly around user stories. I’m very passionate about user stories and the power of these stories to convey across the whole team, the design effort. For me of course, the team’s using methods in the next challenge might be what to do once you get to PRD stage. And I’d love to share some thoughts on that as it hits on my background, of course, in systems, as well as where I work now.
Kathy Davies:
Oh, please do. It’s always a challenge to connect design with implementation, and I think we both have some horror stories where people didn’t think up.
Heatherly Bucher:
Oh, we do. Now, it probably comes as no surprise to anyone on this webinar to see a slide like this. And of course, I’m going to use Arena’s platform as an example, as Arena’s sponsoring the webinar. But in all seriousness, I’ve worked in the product management industry for almost 20 years now, and I’ve been working with product teams and have been through transitions from filing cabinets full of paper and CM2 certifications to the digital product record now, various engineering methodologies, as Kathy talked about, going from vertical to horizontal supply chains, and yes, PLM systems from legacy, unfriendly systems that required coding to meet business needs, to now the new cloud platforms designed to support product team use right out of the box.
Here’s the most important point about a system from my perspective. A great product-record platform will aggregate the entire product records into a single, unified system, a single source of truth. And this definition hasn’t changed in 15 years, but the difference really was that 15 years ago it was a far-off goal. The technologies to build the systems, as well as the business understanding itself of producing product, just wasn’t ready. Now using Arena’s platform as an example, with the product record, all in one place, you can provide the structure, the habit-forming support, we’re going to talk a little bit about later, of key processes including product intent, user stories, NPD releases, defect tracking, formal change management, but also all these other product-related processes—so quality and CAPA, compliance, product projects, requirements management, training management, and so much more.
As I stated, good systems allow companies to manage the product process more effectively from those first steps with PRD all the way to the end of life of the product. Of course, this applies to product companies of all types, from more simple mechanical-only products to mechatronic products now to arguably the more complex IoT-enabled products. Of the 250+ IoT product companies in Arena’s customer community, some pretty big names are there, companies that I believe, that do believe, in a single platform for the full product record—many of which are in the Bay Area and have been influenced actually by Stanford Design Labs and teaching some product ideation, development, and delivery, I believe.
Now, I’d like to talk a bit about why having a product development system leads to more successful product efforts, particularly in this complex fast-moving IoT space, by sharing with you the story of one company. Now, Latch, Latch is a young company providing smart access for offices and managed apartment buildings. They’re currently focused on major metropolitan areas, not surprisingly, including New York City. Customers can range from a four-unit East Village walk-up to a 430-unit luxury doorman rental in Chelsea.
Now, they have what I think is a stunning physical mechanical door lock with smart-technology features. As a company, they’re working to balance what most in the IoT product space need to, which is form and function, industry requirements—in this case, construction codes and market demand. They’re fast-moving with less than four years between foundation to shipped products. In fact, today, I saw in LinkedIn, timely enough, that they just announced the release of their third product which is a lock with support of Apple HomeKit, as well as supporting a deadbolt physical environment that they haven’t supported previously.
Now, I’m talking with Jim at Latch. He shared with me that Latch began first with parts lists and building materials, supplier report information using the tool that was already available on almost everyone’s laptop: Excel. But the product information became a jumble of data spread across the laptop with the potential missteps looming and cost of risks escalating the further they went in the NPD. It wasn’t sustainable and they implemented Arena during the prototyping stage with their first product. The process of determining how to use the product development system also forced the team, according to Jim, to have conversations around processes, which was a good thing.
Latch’s success comes partly from the commitment to map out their processes and to collaborate iteratively from design to production across the global different teams. For example, they didn’t exist for the Arena [inaudible] still early in design. Now often, when companies are understandably so busy they don’t go too deep into discussions of how they want to operate as a product company, much less spend the money and the time to put in place a product development system when Excel and Google Docs are right there. But this is a discipline that will make a difference in the company’s success.
Product development systems, or platforms, provide discipline because as teams and individuals, we do need the structure at some level to create habits, good product development habits. Somebody needs to capture all this and associate it with the product so it becomes part of the greater product records, becomes part of the history of the product that’s available to the extended team, not just the design team, from NPD into sustaining, as well as for future product efforts.
Charles Eames, a designer I love, correctly emphasized the details of what matters—and how you handle the details is the difference between success in companies. Innovative ideas in themselves are one step, the first step in a process of execution.
Kathy Davies:
So Heatherly, as you mentioned, it’s really easy for teams, especially young teams, to use what’s right there, it’s some things that are free, it’s easy access, some like Excel to manage their product processes. But there’s perhaps a substantial hidden cost to long-term effectiveness. So I’d like to hear from our audience about what you are using. And I would like to get your answer in the next minute or so to the following question: How do your product teams manage and collaborate around a product record? So, from user stories like I was talking about to PRDs to bonds and quality records? Please select all that apply and then click Submit at the bottom right.
All right. So looking at this data, it looks like we’ve got a bunch of folks using enterprise platforms. We’ve got a lot of people using online systems of spreadsheets or docs. Some people are using design-specific apps. I’m actually a big fan of InVision myself, I love it. And now a lot of people are still using homegrown or legacy systems. By legacy systems we might mean email because if you think about way back in the day, people were just emailing information back and forth.
What I find really interesting here is that there’s nobody here who’s using Slack or WeChat or kind of these little burst technologies in managing their data. I’m kind of glad to see that because a lot of this data is fairly complex. And so using the more structured systems that hold more complex data seems like it makes sense. I feel like in a lot of my student projects people want to use, you’ve got 24 characters or less.
Kathy Davies:
So Heatherly, even when a system is in place, it doesn’t mean that everything’s going to be smooth. Latch is, I think, really showing maturity as a young company because they have included a team and defined the processes and they’ve worked out how they’re going to use these processes to work together for a common goal. But when you and I were preparing for this webinar, we were trading stories. And you shared with me an experience where you learned that it’s not all in the system, that in fact there’s more to it in terms of teamwork and understanding people’s motivations. Would you share that story?
Heatherly Bucher:
Oh yes. You’re right. Collaboration is hard work in my opinion. It’s probably one of the hardest things about doing work. And I know the story you mean. And it may sound dated, but I’m going to argue that it is absolutely not dated, that this happens all the time.
In the mid ‘90s I worked as a business analyst at a company, a removable storage disk drive company for those who remember, and it was at this company, Vena. They had gone from producing 100,000 drives of the old technology, the previous technology the year before, to over 1 million in the first half of that year. And I was embedded in R&D, and my job was to figure out what engineering teams needed from systems to support their processes and then make it happen with an IT team.
Now, we had a PLM system. It was a heavy enterprise toolkit beast. It doesn’t exist anymore. Well, the company doesn’t exist anymore. The technology of the time, so it was considered leading technology at the time, but it required lots of custom coding which is a danger, in my opinion, that opens Pandora’s box to the idea that technology can solve any problem, including human or cultural problems.
Now, the engineering director came to me one day and asked me if we could place a watermark automatically on all printed drawings from the system that listed the state of the revision whether released or unreleased. Now, we already had headers and footers that we had written code for that would include things like item number, revision, state of revision, all those kinds of stuff when they printed the drawings. And being a newbie at the time in my career, I didn’t really ask why, and we just went and did it.
Now, a few weeks later the same director came back and said, “The watermark’s great, but can we make it darker?” And now, even being a newbie, this was just getting to be an odd scenario or conversation and so I asked and investigated a little more. And the short version was that engineering managers under pressure to deliver on time were jumping the process and had been faxing their contacts with the contract manufacturers that they knew to get them to start work early, even before the changes were finalized, although the engineering managers in good conscience felt like the changes were done.
Now, they originally were cutting off headers and footers before they faxed, and then with the watermark, they actually had been copying the print with grayscale adjustments to fade out the watermark. All of this, of course, meant they were circumnavigating the process, but what it really meant was they hadn’t thought into the process. They didn’t understand the why, didn’t have to deal with the scrap and rework issue or the time lag a few steps down in the process, as well as their management and other parts of the team didn’t understand the engineering managers’ pressures. Minimal communication and no collaboration, a big expensive enterprise system with no discussions about process, and no buy-in.
So, my biggest lesson at the time was understanding the motivation of team members—and understanding their motivation and getting them to participate in the process is critical and it is something that we miss. And while this is a story from the ‘90s when we all had fax machines and people might say, “Oh, it surely doesn’t happen anymore,” but oh, it does. Companies like Latch and other Arena customers that I’ve talked to can tell you about the cost of all the little communication hiccups that can happen. And they can happen very fast in these shortened lifecycles in high-tech and IoT product development.
Now, Kathy, when you and I were talking, you teach at Stanford about team collaboration. So what can you share with product teams in this area that will help them?
Kathy Davies:
Yeah, absolutely. I teach at Stanford a class called Designing Your Life, as you know, and that class is all about how to make work and life work for you. We use design methodologies to do that. And we look at what makes work meaningful for people and how to design jobs and manage teams for greatest happiness and impact. And one of the key things, as you mentioned, is what motivates people. If you are motivated in a certain way, then that will drive your behavior. And how do you motivate people to do great work?
One of the things that our students, and really people in this IoT age are interested in, is how they can have meaningful work, because work is becoming a larger and larger part of our lives. So Dan Pink in his book, “Drive,” starts looking at what really motivates us. What he’s talking about here, he talks about three main things that motivate us: autonomy, mastery, and purpose. Autonomy means that we have the authority to make individual independent decisions, and mastery means we have the expertise to do that with confidence. And then purpose—we know why we’re doing the work and we find that reason compelling. And it turns out that these three factors have a much bigger impact on job satisfaction even than money. And so really understanding the motivations of the people that you’re working with are key to having great teamwork and good productivity.
We also can look at the job market as is changing, right? The job market is more fluid than ever. And that means that you’re going to be seeing your workers coming and going. So over the span of their careers, the people who are graduating from college right now are expected to have more than 10 jobs spanning multiple industries, and they’re going to move geographic location more frequently than previous generations. So what that means is your teams are likely to be in flux, and that means that you might have people leaving during their product cycles or between product cycles and having structures in place to integrate new team members is critical. This company in Australia did a study and they said that college graduates today might even change and have 15 homes during the course of their lives.
Now, diverse teams—in fact, Heatherly, you and I were talking about how we’ve got great team diversity in IoT products, in particular, anecdotally, seem to be having folks living all over the world. So people are having these global teams and they’re willing to have people work perhaps without even a central office. So these diverse teams require greater awareness of the individual team members. I’ve included these infographics here by an artist called Yang Lu, and they’ve created these infographics that really show there are different cultural drivers depending on where you are in the world. You can see here we’ve got a German sunbather in the blue here, and then we’ve got a Chinese sunbather who’s covering up. We’ve got this bottom one, here, is about the sound in a restaurant—quiet for the Germans, a little bit louder for the Chinese.
So you can see that no matter where you are, there are cultural drivers that might impact your behavior. And in addition, we might see folks behaving differently in different parts of their company. So there might even be groups in a single company that have different opinions about things.
Now, we can also think about: What are the individual strengths and motivations of our team members? In our class, we use the StrengthsFinder from Don Clifton, but there are lots of tools out there that can get us this information. And really, the crux of all of them is understanding that pairing people with work that aligns with their strengths and their areas of interest where they want to grow yields increased happiness and productivity. So you can be thinking about that, too, as you’re trying to control for the turnover like earlier mentioned.
And then, finally, I want to mention work styles because we’re moving towards an era of open work plans. Everywhere there are open work plans. And I have to say, as someone who’s a little bit introverted, I hate them. It’s busy and I can’t concentrate. There’s a really great book about introverts and how to get the most from introverts by Susan Cain. It’s called “Quiet.” And I encourage you to read it if you’re somebody who has introverts on your team. Really understanding what works for those people will allow you to get the most from them. If your team needs more quiet to do their best work, that’s useful to know to have a successful team dynamic.
So here are a few tips. First of all, having a shared understanding of goals is critical in the IoT age. You’ve got distributed teams. People need to understand what it is you’re trying to build and why. This comes back to the PRD and really being able to document what it is you’re about. Then you can do some early trust-building. By understanding the motivations and strengths of your team members, you can create a collaborative environment that works for everyone. And ask about the preferred work style, how do people work fast so that you can create that environment that allows them to succeed.
Have communication protocols. Understand how are you checking in, when are meetings going to take place, what are the gates, what are the checkpoints, so that people know what they’re working for and they know exactly how they’re going to communicate with the other members of the team. And that includes feedback procedures because people need to hear positive feedback. So, think to yourself where are the points in your process that you can really highlight product success, team product success. And how do people receive constructive criticism best, so that if things are going off the rails, you know exactly how to let them know in a way that they can then act on.
So those are some good tips. In addition, of course, we need processes. This comes back to things like Arena, places where you can store the data and communicate around it, especially as things are evolving, because as we talked about before, IoT products allow an unprecedented pace of evolution.
Heatherly Bucher:
Kathy, I love your sharing and talking about cross-cultural engineering environments. I certainly have experienced my share of challenges in cross-cultural engineering environments, and I suspect many of our listeners today have similar stories because we are global. We’re global in our design efforts. We’re global in our engineering efforts, as well as in our operations, manufacturing, distribution, and with our supply chain of partners and contract manufacturers. And Arena’s customer base looks a lot like probably many of the people on our call today—highly dispersed.
So if you’re producing IoT products and you have this increased complexity of your product, the type of data to be controlled and managed within those processes and the team, internal and external, how do you get everyone on the same page? And for IoT product companies, regardless of size, flexibility and collaboration are essential to success. I’m going to return to Latch for just a few short minutes to share a little bit more about why they put a framework in place.
They are perhaps on the extreme into virtual dispersed teams with internal team members spanning several continents and multiple time zones and they’re not even that big of a team. Jim shared with me a hiring philosophy. That is a lot like, I think, a lot of companies today, that they hire the right person for the position, they worry about where they’re located later. So they have people spread out everywhere and they have key supply chain partners, of course, including the process with cultural differences and work styles and communications.
Latch sees Arena as a critical part of keeping discussions about processes going, reaching their goal of being hive minded. And I think hive minded is an interesting goal to consider. I mean, you don’t want a team of automatons or identical thought, but to have everyone in the team know what everyone else is doing and working on is critical and to know the why—why does my part matter to the product—and then how can I as a team member leverage what everyone else is doing or stay in sync with my work to make sure that my part is in the mix? This is invaluable and it avoids the misses that become expensive in time and money later. If you can accomplish this, you can avoid the messes of scrap and rework, lost time, failed product that might mean complete failure in the developing market like IoT products.
Now obviously starting earlier rather than later is one thing that we have seen as key to success with companies. Companies like Latch as a new startup took the time to put the system in place and, most importantly, define processes and have those conversations earlier rather than later. But many, many companies do put processes and systems in place after product is released because you feel like you don’t have time during those early moments of the company’s life. But I would say that the nature of the company changes once product isn’t sustaining. Customers need support, brands protection, sales obtained. And so you have additional competition to get people’s attention, as well as budgets to credit systems and processes in place.
But regardless you need to find your processes or implement a product platform that will provide you that discipline.
Now, we’re close to the end of our hour and going shortly into Q&A, but in conclusion we wanted to give you a quick summary of what we hope you can apply in your work. First takeaway is that the product landscape is changing, and our lives are changing the way we work and the products that are produced and impact our lives. And your team’s processes and tools may also need to change to support. Many people say the one constant is change. And as painful as change is, remember that you need to take a look periodically at your team processes and tools to make sure they are in sync with the product landscape.
Kathy Davies:
As I mentioned, IoT products have different and additional requirements. And you have opportunities from collecting the data over time and how your user interacts with your product to then change your product lifecycle. And we hope that this gave you a little bit of visibility into some tools that can allow you to capture the user stories and really get at what matters to users, and how to integrate those requirements and data collected into the work of your team.
Heatherly Bucher:
And finally, align the tools and processes of teams as early as possible, and then keep the discussions happening. Don’t be static. Reevaluate your processes. Adjust as needed. Implement new functionalities of your systems. I’ve seen over the years people, you put a system in place. It was working really well for what it’s doing. And you don’t then go take the time to find out what is the new functionality or the modules that my vendor has released that I could then put back into our business processes and gain additional value.
So these are our takeaways that we hope you find useful. I’d like to turn control back over to Adrienne, our moderator for the Q&A portion, where we hope to get to hear from you.
Adrienne Selko:
Okay, thank you very much. While we’re doing the Q&A, I’ve asked our audience to please take a moment to complete that feedback form that appears on the left side of your screen. The first question we will start with Kathy, and then Heatherly if you wanted to answer as well. The question is: How are product teams changing with the event of IoT?
Kathy Davies:
Yeah, I actually really see this a lot with my students at Stanford. What we see is, as IoT products are becoming more and more prevalent, is the rise of data scientists. So folks are collecting all of this data and the question now is what do we do with that data, how do we actually parse it, how do we understand what it means, and then how do we use that to drive our product roadmap?
We’re seeing an increase in the data scientist roles on the teams. And we’re also seeing an increase in integration between teams because now we’re talking about design over a longer period of time, so continuation engineering becomes a larger role; engineers are really thinking about the product roadmap as they’re building foundational functionality. So, the teams are becoming more diverse both in terms of their functions and they’re also becoming more diverse, as Heatherly mentioned earlier in the webinar, geographically—because people are hiring folks regardless of their geographic location. We’re all very connected now, and so we can work from anywhere and collaborate.
Heatherly Bucher:
Yeah. I mean, I agree with Kathy. What I have seen in talking with IoT product companies is not only data scientists and statisticians and data analysts and, of course, big data concepts, we hear that, and those are certainly exploding career paths and are becoming more and more to have on our teams. But also, I talked with teams that have sociologists and anthropologists and who really are looking at how people live. Particularly if your product is a consumer product, what do people really need, even that they can’t express what they need. I mean, certainly that’s always been part of capturing user stories, but I think we’re seeing soft sciences come more into these teams.
And then the other part I would add is that regulations are interesting depending on your industry. If you’re a medical device right now, when I talk with medical device companies that are IoT enabled products, it becomes a very interesting conversation because the regulatory bodies in some industries haven’t kept pace with the technology and they haven’t really weighed in yet or adjusted the regulation for how does it apply to the IoT portion of your product. So it leaves these companies in a bit of an interesting dilemma as they’re trying to push forward products and get to market early, but they also have to be very careful and as they step into the regulatory issues that govern their industry as well.
Adrienne Selko:
Okay, thank you. The next question …
Kathy Davies:
Yeah, Heatherly, I’m going to chime in here.
Adrienne Selko:
Oh. Go ahead.
Kathy Davies:
Sorry. I was just going to just say that I saw a question here from Tom that asked, do you see IoT and Cloud more in medical devices? And sort of building on what Heatherly just said, one of the things that is super critical and that I see in med-device startups is the question of how to handle that patient data. So HIPAA requirements require great security around patient data, and so IoT devices are really interesting in this space, because when data is collected, the storage and use of that data is very highly regulated too. And so we’re really looking at an evolving industry in terms of those regulations.
I don’t think that we actually understand yet how those regulations will finally play out, given that we soon will be able to collect real-time data from your body from implanted devices. And so how is that communication regulated and how do we make sure that not only are those devices operating correctly and not misused, but how is any data that’s collected from them protected?
Heatherly Bucher:
Yeah, I think the uncertainty in that industry, particularly going to Tom’s question on medical device, what I have seen in talking with companies is one business strategy, high-level strategy, is of course to wade into that area going first with a consumer-level product and with the intent, of course, to then go to a clinical-level product in the future, because there’s a certain level of case-study requirements involved with medical device and certification and an efficacy of the product, these sorts of things.
So I think actually fitness wearables, health or fitness wearables, is a “light” medical device area that you see first it was its consumer-only focus, but I do believe that you get down the road, I don’t know if it’s three years, five years, or 10 years, but we may see health wearable devices provided by our clinicians, by the doctor, to say a health patient, a cardiac patient that is collecting that information you talked about, Kathy, and sending it back to the clinician and opposed to …
Kathy Davies:
It’s already happening in the diabetes industry with diabetic pumps.
Heatherly Bucher:
Exactly.
Kathy Davies:
Is already happening with, yeah, mm-hmm (affirmative).
Adrienne Selko:
Okay, we have time for one last question ,so I’ll start with Heatherly on this. How do we get our company to prioritize purchase of product development platform, PLM, and who should lead that charge?
Heatherly Bucher:
Oh, that’s a great question. Unfortunately, the best answer varies depending on the company you’re at, your industry, your stage as a company, how your team’s structured, how much design you do, how much manufacturing you do. But I think in the perfect world every product company would have a chief product officer or a product strategy role, a role that recognizes that managing the product from ideation to end of life requires bringing together all these teams and disciplines and processes we’ve talked to over an extended period of time. But where most of us are not in a perfect world, and with the budgets and resources we’d like to have, so we don’t have that role.
I did work at companies, not just the vendor, so I know that that struggle is there. So I think the answer is to look for which role or roles of the company are responsible for the overall product from execution on design to quality and delivery because that effort to properly … to view the product at a holistic level, that role is going to care the most and they’re going to be your kind of internal champion, if you will, to try to make a space not just in the budget but also the people in time to get attention on, hey, we need to prioritize fixing some of our processes or bringing a system in to support our processes. So look for who might be that internal champion. And it may be more than one person. It may be a couple of people that you can have discussions with about your pain points and your needs.
Adrienne Selko:
Thank you very much. I’m afraid we’ve run out of time. I’d like to thank our speakers, Kathy Davis and Heather Butcher, and our sponsor, Arena. As a reminder, if you’re registered as a group, please add the names and emails of all in attendance on the exit survey. And on behalf of IndustryWeek, have a productive remainder of the day. Thank you.