132 – Leveraging Behavioral Science to Increase Data Product Adoption with Klara Lindner

Experiencing Data with Brian O'Neill (Designing for Analytics)
Experiencing Data with Brian T. O'Neill
132 - Leveraging Behavioral Science to Increase Data Product Adoption with Klara Lindner
Loading
/

In this conversation with Klara Lindner, Service Designer at diconium data, we explore how behavioral science and UX can be used to increase adoption of data products. Klara describes how she went from having a highly technical career as an electrical engineer and being the founder of a solar startup to her current role in service design for data products. Klara shares powerful insights into the value of user research and human-centered design, including one which stopped me in my tracks during this episode: how the people making data products and evangelizing data-driven decision making aren’t actually following their own advice when it comes to designing their data products.

Klara and I also explore some easy user research techniques that data professionals can use, and discuss who should ultimately be responsible for user adoption of data products. Lastly, Klara gives us a peek at her upcoming December 19th, 2023 webinar with the The Data Product Leadership Community (DPLC) where she will be going deeper on two frameworks from psychology and behavioral science that teams can use to increase adoption of data products. Klara is also a founding member of the DPLC and was one of—if not the very first—design/UX professionals to join.

Highlights/Skip To:

  • I introduce Klara, and she explains the role of Service Design to our audience (00:49)
  • Klara explains how she realized she’s been doing design work longer than she thought by reflecting on the company she founded, Mobisol (02:09)
  • How Klara balances the desire to design great dashboards with the mission of helping end users (06:15)
  • Klara describes the psychology behind user research and her upcoming talk on December 19th at The Data Product Leadership Community (08:32)
  • What data product teams can do as a starting point to begin implementing user research principles (10:52)
  • Klara gives a powerful example of the type of insight and value even basic user research can provide (12:49)
  • I had a huge revelation about something Klara pointed out: the irony of how many data teams are largely using non-data-informed ways of designing data products (16:43)
  • What adjustments Klara had to make in her thinking when moving from a highly technical background to doing human-centered design (21:08)
  • Klara describes the two frameworks for driving adoption that she’ll be sharing in her talk at the DPLC on December 19th (24:23)
  • An example of how understanding and addressing adoption blockers is important for product and design teams (30:44)
  • How Klara has seen her teams adopt a new way of thinking about product & service design (32:55)
  • Klara gives her take on the Jobs to be Done framework, which she will also be sharing in her talk at the DPLC on December 19th (35:26)
  • Klara’s advice to teams that are looking to build products around generative AI (39:28)
  • Where listeners can connect with Klara to learn more (41:37)

Quotes from Today’s Episode

  • “People ... want to move forward. And you need to understand where people want to go. Not where they are right now, but where they want to be, how they want to be, who they want to be. And if you get that, then so many opportunities pop up for you and you get so much inspiration and you have such a clearer potential focus for your data progress." — Klara Lindner (35:41)
  • “What I always tell people is that whenever you build something, you're not just placing it in the void. So it's not like a timeless void and there was nothing before you placed your dashboard into it. There was always something that people used before to get that job done.” — Klara Lindner (09:46)
  • “When we think about our future users of our products, they are humans too. And they are not a ‘homo economus’ who's just making analytical decisions. They are making their decisions based on all kinds of stuff.” — Klara Lindner (39:05)
  • “I hear sometimes from executives who are reluctant to do user research, that they think ‘if we don’t do [user research] quantitatively, it won’t count—because we really need to get down the numbers to change features.” [The irony is that] whatever the developers are building right now is also based on their intuition—not quantitative assessments!” — Klara Lindner (19:25)
  • “I hear sometimes from executives who are reluctant to do user research, that they think ‘if we don’t do [user research] quantitatively, it won’t count—because we really need to get down the numbers to change features.” [The irony is that] whatever the developers are building right now is also based on their intuition—not quantitative assessments!” — Klara Lindner (19:25)
  • “I think what you might have let go of as an engineer is [the instinct] to stay in your own bubble, because I think you can build a great Lego car for yourself, if that's all what you accomplish. But if you want to build a product or a solution that is ultimately not for you, but for someone else, you need to get their understanding because you're not going to build anything just for yourself.” — Klara Lindner (22:30)
  •  “When you are designing a product, you really need to understand what situation your user is in, [how we can make sure they will want] to use the product, and that they are  able to [use it].” — Klara Lindner (30:33)

Links

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have Klara Lindner on the line. She is a service designer at diconium data in Europe, and she’s also one of the founding members of the Data Product Leadership Community. Klara, what is the service designer? Because I think you’re the first service designer we’ve had on the show, so why don’t you tell our audience, what is that?

 

Klara: The service designers, they’re there to take care of the ecosystem around your product. And that, more and more because we’re working with digital products, actually also touches your product. So, now I also call myself a product and service designer. And what we do is we try to understand how your product links with the outside world and the context your users are in, and make sure that this is a seamless connection, and there’s nothing that you are missing out when building your product for someone.

 

Brian: For the purposes of, like—sometimes I find that, like, in designer world, like, we have way too many job titles and all of this. So for, like, more the data and product folks out there, is it safe to think of them as basically user experience design, it just may touch non-digital components as well? Is it safe to think of it like that, or is that giving it short-sightedness [laugh] or something?

 

Klara: No, I think it’s totally valid. The only downside is that user experience sometimes has been downgraded to where should we place this button so that people find it, and I think from that point of view, it’s actually much more zoomed out. So, we’re not really thinking about buttons; we’re thinking about whole journey maps.

 

Brian: So, you founded a company called Mobisol, and you told me when you were thinking about coming onto the show that you kind of had dug back through your history, and you realized you had been doing this data product design work for a while. Tell us a little bit, what was Mobisol—just for context, what was the goal of that company? It was in the energy space I know. How does the data product thing fit into getting off of the grid? Like, connect those dots.

 

Klara: So, we started off as this, just a bunch of engineers who were good with renewable energy technologies, and we wanted to provide that to people who had no energy. And we wanted to make use of the modern world and all these other opportunities because for a long time, renewable energy technologies were considered too expensive for a large portion of the world. We said, “Hey, yeah, let’s use the mobile revolution and kind of build on that.” And then by accident, we created a data product because we placed solar systems on people’s roofs, and we placed SIM cards in these solar systems, so that we are connected to them 24/7, and we allowed our customers to pay off the system over three years. So basically, what they were saving up because they hadn’t—don’t have to rely on, like, buying kerosene or getting their phones charged in the village where they were saving, this is what they could give to us to pay off the system over time.

 

And only then we realized, hey, we now have this 24/7 connection to the users and their system, and we can make use of that in an intermediate step for, like, preventive maintenance because we realized people won’t pay for the system for three years if it stops working after one year, and we have to try to cater for that. And then over time, we found out that we can better understand what other services or products we can provide to them. If we really dig into this data, we can understand who else we can partner with, and then also, while we were building up a business on the ground that allowed us to distribute the systems, even more data came in our what we called the database [laugh], which was basically an ever-growing dashboard of potential information about users, how they use the system, sales agents, finance guys, I don’t know, maintenance people, and then we tried to find other ways how we can exploit this data and make use of it.

 

Brian: And were you in an engineering capacity at that time when you were a founder? I know you have—you have an engineering background, correct?

 

Klara: Yes. Yeah, so having a background in electrical engineering, and when we first started, there was a group of seven people, and I think six of them were engineers, and one of them was a business guy. And I also when I first started, I was really this engineer who just wanted to, like, work on a cool solution, and at the end of my studies, I realized hey, I need a problem to apply the solution to. And then I came across design thinking, and then I became this, we call it the ‘Design Thinking Architect’ of the whole solution. So, because we started really broad—all we wanted was to bring renewable energy technologies to places where there’s no energy, and that was, for us, mainly Sub-Saharan Africa, for different reasons—and then I gradually turned more away from engineering because we had other people who were really, really good with the engineering part, both on the hardware side and the software and firmware side, and I was more the translator and was involved in doing field research, and partnership development, and fueling that into the engineering.

 

Brian: It sounds like you, kind of, fell into this role where it’s like, oh, I didn’t know there was a job profession called this, and I’ve been doing this kind of work—

 

Klara: Exactly.

 

Brian: Is it one of those kinds of situations?

 

Klara: Yes. Yes, definitely like that.

 

Brian: I think product managers have—that’s a classic product management thing, I think, especially in the early days. It’s like, “Oh, I’m doing product management. That’s what it’s called.” [laugh].

 

Klara: [laugh] Yes, finally, I know how to tell my mom what I’m doing.

 

Brian: Yeah. I think there’s several—the digital spaces create a lot of these jobs where we’re still figuring out the right names for them, and that there’s actually these defined roles that have emerged. I’m curious about the difference between getting people off the grid into solar. I mean, that’s ultimately the business objective versus designing the dashboard to help us go do those things, and I think we can get lost, that… the team, especially if it’s like a digital team, that the goal is to make this great digital output, but in your case, like, it didn’t mean anything unless there is some action downstream from it, in this case, in the physical world.

 

Klara: Yes.

 

Brian: Was that ever a challenge that sometimes you get lost in? Like, oh, what kind of chart should it be? Or what kind of—I don’t know [laugh]… you know, and missing the de—who’s going to go use this? Is it salespeople, or the technician for maintenance purposes, or whatever? I’m curious about your thinking there.

 

Klara: Yeah, yeah. So, I think it was actually, for our situation, it was pretty great because we had this thing that we wanted to solve. We just wanted to provide energy to people who had no energy, and our dashboard was really a means to an end. And after that, I’ve also worked with other companies who built dashboards a bit as the end itself, and then it gets so complicated because you don’t really know who is looking at that. And I’m also, with—immediately understood, okay, so this is what we want, and we kind of need this decision helping tool, and that is our dashboard.

 

And it did help in the beginning to really stay sharp on what needs to be done by this kind of dashboard. But then I realized how tricky this becomes when more people joined the team, and they were really about creating great dashboards. And then this discrepancy started, and we realized, okay, huh, how can we explain people who are new to this what we want? And that was also where my skill set really grew in terms of translating this, and first—like, not saying, “Hey, this is my intuition,” because I’ve been meeting these people in their living rooms, and I’ve been running with sales agents to sell the systems, but really try to find out how can I argue for this, and how can I use my field insights to get developers understand what needs to be done.

 

Brian: And we’re going to jump into that because you’re giving one of our monthly webinars coming up. Our next one is December 19th, 2023, and this is going to be on some psychology principles, and I’m going to let you tell us about that. But the first thing—and so this kind of gets into this whole field of doing customer research, and I assume, observing users in the wild doing their thing. You told me during our screening call that you’ve heard that—strangely—that some people think user research isn’t relevant to people who are not working on B2C [laugh] products, and you had something to say about that.

 

So, what I wanted to do here is, since we’re both designers, is like, I’m going to play the devil’s advocate, the person that’s saying that to you, and you tell me why I’m wrong. So, I guess my perspective, like, I’m VP of Data at some company, or whatever. It’s like, “Well, yeah, but you know, that stuff is—we don’t have time. We don’t really have time to go out and talk to ten people about this because we have to get this out now, and frankly, there’s only, like, 10, or 50, 100 people who might ever even use this dashboard, so we can just train them if they don’t know how to use it. So, I really don’t see why we should spend another two months doing this big upfront project when there’s only that many people. Why don’t—we can just train them.”

 

Klara: Yes.

 

Brian: Like, what do you say to that?

 

Klara: What I always tell people is that whenever you build something, you’re not just placing it in the void. So, it’s not like a timeless void, and there was nothing before, and then all of a sudden, you can place your dashboard in there and people can finally work with it. There was always something that people used before to get the job done, and you need to understand this because if you don’t, the risk is there that people still won’t adopt your product because they’re better off with, either I don’t know, the Excel sheets they had, or their intuition, or I don’t know, notebooks, or hanging out in the bar, and making decisions [for 00:10:23] that end. Yeah. So, time and again, I see this, that people think, “Ah, yes. All this user research is only needed for the B2C space because that’s where you really need to understand customers,” et cetera, but I mean, there’s always people using your dashboard, or your [RP 00:10:41], or your website, and it’s time to get into their heads and understand what’s driving their behaviors and decisions to really assure that your product is being used.

 

Brian: Let’s say that I buy your argument. Okay, that makes sense; I’m not putting it in this void. So, I’m smart; I’m aware of biases, I’m aware of, like, switching costs pain, right? Like most people don’t want to give up the old. Like, it’s going to have to be quite a bit better to get them to change their behavior, and I’m smart enough to know that.

 

What’s the bare minimum that I have to do—if I don’t have any service designers, UX people, researchers, I don’t have all that stuff. I work at a, I don’t know, tire company, I don’t know… plants, we sell plants, global plant supplier. Where do I start? Like, I want some of that benefit, but I can’t just go out and hire someone. Like, how do I get started with my analysts, my architects, my data scientists, what could we do this week?

 

Klara: I mean, when you think of the bare minimum, I think you don’t even have to schedule a one-on-one interviews right away. Like, for me, what works quite well is that either you can do some online research of forums, for example, where you try to understand, okay, this is what I’m working on, and I now do an online research. And I, for example, go to Reddit or some other platforms where people share their opinions, and I’m just going to read through this for one or two hours, and then I get a feeling for either the product that I’m already having, or the competition that I want to be better with. And what I also like to look at is the observation of compensating behaviors. So, if I had one week, and I knew, okay, this is only a data product that’s going to be used by 50 accountants in our finance department, I would spend two hours next to one of the accountants and try to understand what does his daily job look like, what is he doing, and how do we actually intend to support him with the state of product that we’re building? And even if I have just one person, that could already provide inspiration for further development.

 

Brian: Is there, like, a concrete example of you doing that? Or maybe you and someone at diconium—maybe it’s a data scientist, or a data professional, or something—where you went out and did this and there was some revelation. Or even it’s not even a revelation’ that makes it sound like it’s—you’re always going to get this giant reward, but some piece of insight that changed the trajectory of what you were planning to do, just so someone can get an idea, what does it feel like when you get something back that’s useful, and it’s not just like, “Well, I don’t know. I went there, and I watched the accountant, and he used Excel for two hours.” Like, “Yes, and?” Like, “What do I do with that?” But tell me, what might we learn from something like that?

 

Klara: Sure, yeah. I think I have one example. It’s a simple data product, but maybe that makes it quicker to explain. So, at Mobisol, at one moment, we had a lot of customers, and we needed to deal with their requests and questions, et cetera, so we had a customer hotline that people could call for anything. And in the beginning, this was just someone’s cell phone, but then it got more and more, and we wanted to create this hotline where you can just dial 1-800, and then you get to talk to someone on this service stuff.

 

And then this, for some reason, was really inefficient. And I don’t know, first of all, we had this—like, there was bad feedback from customers and prospective customers, and I don’t know, there was this issue around the customer hotline that nobody really liked it. And then first, the developers thought, “Hey, okay, we need to just make this customer hotline really great.” And you have, like, “Dial one for this,” and, “Dial two for this,” and, “Dial three for this.” And over time, for all the common requests that we get, we put even more numbers.

 

Brian: A phone tree, yeah.

 

Klara: And so we’re, like—

 

Brian: So, this is automated? When you call this, you didn’t get a human right away? You got a—

 

Klara: Exactly.

 

Brian: A phone tree system or something?

 

Klara: Yes, yeah.

 

Brian: Okay.

 

Klara: Because—so, for example, lots of people called only because they wanted to understand what is their balance. So like, 30% of the people wanted to understand what’s the balance of the credit. And we’re like, “Hey, this is easy.” [laugh] And then they get these automated answers on their cell phones with these very—but it didn’t really help, and so we’re like, “Okay, we have to do something about this.” And so, we went to the customer care department and just observed them, we’re, like, sitting next to them when they were having these calls, and I remember there was this one moment where I was just looking around in the office, and there was one wall, filled with Post-It notes of individual phone numbers of people in the field. And I was like, “What’s going on? What is this?”

 

And then one of the customer care staff told me, “Hey, you know, like, actually, a lot of people, when they call us, they want to talk to their point of contact who, kind of, sold them the system because this is the person they trust, and they don’t trust me because they don’t know me, and I speak the language of the city, and they want to speak to someone with the language of a village. And then that’s why I, kind of, move this call over to that person. And because we have so many staff in the field, we have all these numbers here.” And yeah, I like, “Okay, so this is what’s happening.” And once we had this in place, we know, okay, maybe we have to find the more efficient way that these people in the field—who are maybe freelancing for us—can also be involved in this customer care, dealing with these requests.

 

And we did that, and for example, we introduced a very small thing, which is like, we had these analog flyers, and there was a space to put down the phone number of this person who was handing over the flier to that person. And then they had this person’s phone number, and they could call him. And that led to so—like, so much less calls in the customer care hotline that we thought, “Okay, great.” So, that was one case that we could argue for, hey, just spending time with people. And then we did much more, and yeah, I have more complicated examples that I can put somewhere else [laugh].

 

Brian: No, I understand. That’s a—I think it’s probably a fairly common thing these days in digital businesses is getting design research staff, product staff, to go and sit at the call center and take—especially anywhere that there is actually human beings taking calls, you can learn a lot just eavesdropping on calls. I think I might have even talked about this on the last episode I just recorded, a solo one, but you know, I used to work at JPMorgan Chase on—I was redesigning one of the trading systems for their Active Trader brand, and it was required on our product team to go spend, I think we had to do two hours a week just sitting with the traders at the trading desk because at that time, there were still a lot of people that didn’t trade online; they would call in the trades.

 

But you really got to feel the different personas that we had kind of identified when they would call in. And one of the findings that we got there’s, you know, designers, “Oh, we got to make everything easy to use,” and all this kind of stuff. And we had this persona, I think it was, like, Oliver Options, the options trader, and that was our persona for this options trader. But one of the findings there was that Oliver as a persona doesn’t want everything simplified. Oliver—and this gets into why the Bloomberg terminal looks the way it does—he doesn’t want help, information about what’s a butterfly spread, and like, how do you place these really complicated trades.

 

They don’t want that because for them, it’s the feeling of, like, “I like the complexity, I like the feeling that I’m in control here, and I don’t want a website helping me when I’m placing trades.” Like, it was a very interesting finding to let go of this feeling that we would need to provide help, or make it as easy to use, or try to, like, how can we make this really complicated trading—you know, options trading—easy to do. And there’s a fine line there, right? Like, do you don’t want it to be unnecessarily hard to use, but you also have to acknowledge the people who are your customers and what they’re looking to do. And you get this—and this is, like, to me, the design space where you’re in the gray area.

 

It’s not binary. It’s, well, it can’t be too complicated, or they won’t be able to use it, but they also don’t want it to feel like they’re being helped. And it’s about feelings. And [laugh] so I think that’s, like, the tough part about all this stuff. No matter what you’re designing, there’s always these feelings involved, and a lot of times it’s not going to be super cut-and-dry which way to go. I don’t know if your experience is the same, you know, in general [laugh].

 

Klara: Yeah. And definitely, I mean, I think what you said is also really wise. I mean, we are in the design phase at that moment, and I hear that sometimes from executives who are reluctant to do user research, that they think “Hey, but if we don’t do it quantitatively, it won’t count anyways because, like, we really need to get down the numbers to change features or something.” But I think “Hey, actually, it’s like, it’s in the design phase, and we look for inspiration. And whatever the developers are right now building is also based on their intuition, and it’s not based on quantitative assessments.”

 

Brian: Right.

 

Klara: And it’s so helpful to just witness a few people who are going to experience your data product. I promise, every person who was involved will learn from this. And then it also, in my experience, doesn’t slow down the design process, but rather speeds it up because all of a sudden, you understand as a team what you really need to focus on, and you stop ideating more and more features, and yeah, get into this feature creep, and you rather focus, really, on the user problem and solving that.

 

Brian: Sure, sure. I want to rewind something you just said, and I think people should really—and maybe this is more for the designers out there. I’ve never heard this articulated this way, but I think you were making the point that if a stakeholder needs data to back up a decision about why they’re going to change something, and you make the counterargument, it’s like, “We didn’t use any data to inform the current path that we’re on except feelings and intuition.” It’s such a—that is such a big point. I’ve never heard that said so clearly. Like, I really think [laugh] there’s so much there, so thank you for that. That was—this whole episode is now worth it for me, just right there. That’s, like, the money.

 

Klara: Cool. It’s even helpful for me because I haven’t articulated it that well to people I have worked with before, so say thanks for the ping-pong, Brian.

 

Brian: Yeah, no, that was fantastic. Wow, I got to sit with that for a second [laugh]. Geez, that was fantastic. [laugh] I’m now thinking of all these projects, and who should I—wow, I’m going to use that against this person.

 

Klara: [laugh].

 

Brian: Not against them, but with them [laugh]. Anyhow, let’s jump into the data space here and your technical background. One thing I like, I love it, when we meet technical people that either officially move into design work or kind of unofficially, they become design thinkers or design advocates because they got tired of doing it the old way. They saw the benefits, and they don’t want to keep building stuff that doesn’t get used. Since you have that technical background, are there things that someone with an engineering or a data background, in your experience, needs to let go of, or—I don’t know, any of your natural wiring, if that was kind of your natural state, you know, I don’t know, 10, 20 years ago, that was just maybe your studies, your schooling, that you’re just weighted to be an analytical thinker, whatever, anything that you had to let go of, or that, like, something that you might advise someone else that’s trying to do this to talk to a data or technical person, any unwiring that needs to happen?

 

Klara: I think it’s—like, when I think of engineers, the many other engineers that I know, I think actually they started to become engineers because of their creativity, right? I mean, it was those guys and girls who played Lego endlessly in the afternoons, and they just want to keep building stuff. And I think this whole analytical part comes, like, in school and university. And so, I think what you might have to a bit let go of as an engineer is to stay in your own bubble because I think you can build a great Lego car for yourself if that’s all what you accomplish. But if you want to build a product, or build a solution, that is ultimately not for you, but for someone else, you need to get their understanding because you’re not going to build anything just for yourself.

 

And there are ways for this, and don’t be afraid of this, I think we are also very trained in our modern world to be frustrated, about, like, feedback that something is not right, and so a lot of things that we do is just trying to prevent getting feedback that something is not working. And this is what you have to let go of because you have to embrace this feedback and say, “Hey, this is a learning journey, and I’m learning more and I built something and then I trashed it again, and then I build in a better way, and so ultimately, a product will be great based on this.” But there is, of course, some stumbling involved.

 

[midroll 00:23:39]

 

Brian: Yeah, I think the idea of right and wrong, you know, and it’s like my best advice for that, it’s like, well, then let’s be wrong in smaller increments because when you’re—you know, if you’re shipping smaller or you’re working in smaller increments, the pain is consequently significantly less. And it’s really about learning much more than it is about being right or wrong. And the wrongness stings, when you’ve sunk so much passion energy, you modeled it perfectly, it’s the best new tech, you got a full greenfield to work with, and it still doesn’t work. Like, that’s where the pain is coming from is the feeling that it doesn’t matter what you do. And I think that learning, so much that learning can happen earlier; it doesn’t need to happen so late in the project, you know?

 

Klara: Yes. Then it hurts less.

 

Brian: Yeah, yeah. So, I get that feeling we have some kindred spirit here about, the monster in the room, which is low adoption of data product, low adoption of machine learning and analytics applications. You’re going to give a talk about this, like, tackling this problem using two frameworks from behavioral and cognitive science in our webinar coming up. So, what is that? Like, can you give us a little sneak peek behind the curtain? What are people going to learn? What are people in the community going to learn?

 

Klara: Yeah, the first framework is actually helpful for people who want to better understand what could user research exactly be useful for because I also am not an advocate for user research, per se. I mean, there’s this famous quote, “If I had asked people what they wanted, they would have wanted a faster horse,” by Henry Ford, I think. So yes, you shouldn’t ask people what they want [laugh]. So, user research means something different. And one framework that helps me preparing and digesting these sit-ins with potential users, is a tool called ‘Forces of Progress.’

 

And it’s basically a mental model that, for me, it’s very practical, and it deals with people who are at the moment of changing their behavior. And the tool is, of course, simplifying this moment, but for me, as a product design or service designer, it’s simplifying it in a helpful way that I can do something, and ultimately, I can better understand what features does my product need and what features does it not need. And the idea on the Forces of Progress is that there’s this person, and if we picture it, behind this person is the current solution that this person is using. That could be, I don’t know, an approach—

 

Brian: Excel. It’s an Excel. It’s always—

 

Klara: Yeah, it’s—

 

Brian: Excel.

 

Klara: —Excel—is behind them. And in front of them is this cool new dashboard solution that you are building for them. And then there are two forces pushing this person towards your [now 00:26:16] cool solution. The first one is that the old solution—Excel—is really frustrating, and it annoys them, and they just hate it, and they’re really frustrated by it. And the second force pushing them towards a solution is the attraction of your new solution because it’s shiny, and it looks very cool, and they want to use it.

 

And the problem is, that a lot of people overly think just about these two forces, and think, “Hey, how can we show that Excel is really bad? And how can we make sure that our product shines even more? What features can we do to make it even shinier?” When this Forces of Progress model—and it’s from Alan Klement and [Clay Christensen 00:26:58]—they say, “Hey, there’s two other forces who are less visible but more important, and these forces are keeping this person with the old solution.” The first one is anxiety about this potential new solution, they might not know, is there, like, this new tool, Will it still be there in two years’ time? Are they making the right decision right now or should they rather wait for another year when even a better solution comes up, and that stuff?

 

And the second force that is pulling them backwards is existing patterns of behavior and the system they are locked in. So, it might be that this Excel tool really integrates well with their email automation, or it’s just this, I don’t know, maybe all the computers run on Windows 98, and they never bought a new license, and it’s all stable, kind of, and if they now have to change to another solution, that means that they also need to buy all these, kinds of, new licenses for Windows, for example. And the real interesting part about this tool is if you map these four forces, and you do your research, and you better try to understand, okay, what potential anxieties does my person have, and what is the system they’re locked in, and then to each of these anxieties or system lock-ins, you develop features—or maybe it’s just a means of communication—then it’s much more likely that your user will actually make the switch. And it also helps to distribute your, like, developer resources in a wiser way because you stop working on adding more and more shiny features and start working on the stuff that is really necessary for adoption.

 

Brian: I want to play back the last two things that you talked about, the two forces, I think you’re saying. There is anxiety or fear about, basically, switching costs, right: is that the right time to do it? What could go wrong? These kinds of things. And then there was kind of the environmental situation: what’s the org structure I’m in, the power structure that I’m in, or my boss is still going to want a CSV at the end of the day.

 

Even if I use your thing, I got to put it into a PowerPoint, or whatever the—they have some organizational constraints, environmental constraints, whatever it may be. Is your advice for, like, this data product space is that part of the effort of the makers of the data product is to make stuff or create a solution to address those two things, not just the charts and the data and the model quality and all this, but to actually put effort into reducing the anxiety [laugh] and whatever—can we somehow change the environment that it’s in or address something about that, whether it’s in the communication of it or something, but that becomes part of the effort by the data team. Is that basically what you’re saying? Did I get that right?

 

Klara: Yes, and I think probably what my, kind of, basic understanding behind this understanding, is that for me when you build data products, your responsibility is actually to get users to adopt it. And because when you think this is your responsibility as a product designer, then you need to consider these things. Because I always get really suspicious when people say, “Hey, you know, users are not adopting the product because it’s too expensive, and the finance team needs to find ways to crunch the numbers in a better way.” Or, “Hey, they’re not adopting it because marketing is not effective, so [you’re not used to 00:30:28] put, like, more money on the marketing department, and then they will deal with it.” No, I think when you are designing the product, you really need to understand what situation is your user in, and how can we make sure that he really wants to use our product and is able to do it?

 

Brian: Is there, like, a recent example of this diconium or somewhere else where you used this? Or maybe you can make it concrete. Like, what was an example of the effort you put into anxiety reduction or environmental change. Like, tactically, what did that look like if you’ve had that experience?

 

Klara: Yes. Yeah, let me think a second… a good example. Hmm… yeah, maybe I can share an example, again, from back in my days at Mobisol. There, we had a moment where we’re trying to understand, okay, we have lots of leads, like, many potential customers want to kind of buy our system, but then in the end, they’re not converting, so how can we deal with that? And the initial approach was exactly this.

 

So yes, marketing needs to go out there and keep on marketing the product. The finance team needs to find better supplier agreements that we can build the product even in a cheaper way so that we can also sell it in a cheaper way. And then what we did, we were really trying to understand, okay, exactly what are people’s anxieties, what are the systems they’re locked in, and how can we deal with that? And we understood that the purchase journey takes much longer as anticipated with our potential clients. They need to hear about this once from one person, and—because especially in the Global South, there’s what’s called a high-context culture, so it really depends on who you talk to, and they have much more of a community understanding.

 

And for them, like, the buyer journey was always stopping the moment they were talking to a new person. And what we then understood is, we need to equip the team who is doing the sales with ways so that they continue to reach out to people several times, and have several touchpoints on that. And we need to—because at that time, we were also working with—like, we were building several data products to help that, so we had a customer app, and we also had an app for our sales reps, and we needed to include different features in these apps to cater for that.

 

Brian: Is it hard to get the rest of the team on board with this, or do they get expo—like, your especially your technical counterparts, did they start to see this model, and they start to understand when we talked about, you know, environment, anxiety, that those are maybe strongly correlated with low adoption potentially, or is it still kind of like, you kind of own that designer-y stuff, and—like, I’m just curious about how much everybody else sees it, or doesn’t.

 

Klara: Well, I think I’ve partially—I now think, hey, let me still do much of the research, and then I tried to get better at filling you in on what is happening, so that you get a feel of what’s happening. And the cool part is, many of the tech people are initially scared to even observe potential people or talk to them because, I don’t know, maybe they don’t want to hear that their product is bad, or maybe they don’t want to, kind of, be intriguing [laugh] for the potential customer. But as soon as I come back with some information, and you can immediately tell that this is, like, valid, interesting stuff, they get really excited about this. So, we had other examples where we—I mean, this is now not so much digital products, but we were thinking about how to increase our variety of appliances that we could also provide to our customers so that they can make use of electricity. I mean, we started with phone chargers, and then it went to TVs, and stereos, et cetera, and we understand, okay, what kind of stereo system do people need?

 

And based on our research, we understood there’s actually totally different ways how people would use stereo systems that are really different, and it needs kind of special stereo systems for the use cases out there because they also differ a lot from what this, I don’t know, 26-year-old Berlin guy would use a [laugh] stereo for, and just providing them with, I don’t know, two pictures of people and some information that hey, they use this on Saturday for 12 hours because they want to listen to the whole church ceremony thing with their stereo, or they have this party on Sundays, and they invite all the other neighbors who don’t have electricity. And that was so helpful. And they immediately caught it, and then this moment kicked in with the Lego playing thing, that engineers were like, “Okay, now I’m going to build this other stereo system that is even more useful.” And then you—it gets easier.

 

Brian: I’m really looking forward to this session. Is there anything else you wanted to share about what you’re going to be talking about in the webinar? Without giving it all away, but—

 

Klara: Yes. Yeah, I don’t want to give it all away, but I’m also like, I mean, you might have heard it, but I’m a big fan of this whole Job-To-Be-Done Framework where they say, “Hey, people are actually—they don’t just want something for itself, or they just don’t want to get something done, but actually, they want to move forward.”

 

Brian: Right.

 

Klara: And you need to understand where people want to go to. So, not what they are right now, but where they want to be, how they want to be, who they want to be. And if you get that, then so many opportunities pop up for you, and you get so much inspiration, and you have such a clearer potential focus for your data progress. And that is either B2C or B2B because it’s the same with people who are deciding to buy a product for their business. There’s, in the end, also people [laugh] who are doing this. We forget that. And so, I also, in my webinar, want to talk more about how you can get to understanding your job to be done that your product is doing, and then find the solution that is much better to all the other potential competition that you identified.

 

Brian: The language I like for that, that I’ve heard that I learned, you know, running my business on the sales side, they call it ‘desired future state,’ and I think that’s a really powerful framing because it implies it’s in the future, there’s some timeline, it’s going to take time to get there, but there is a future state people want to be at. So, the more we can uncover that, whether you’re—and we’re kind of always selling even if you know we’re not exchanging [laugh]—it’s your teammate. You sort of are selling if you’re trying to push an idea forward, or why we need to do X, Y, and Z. You’re always selling even if there’s no money being exchanged, so I think there’s things we can take from that vocabulary as well. But I’m—you know, jobs to be done is another great framework as well.

 

And I liked your earlier comment about the void. Like, we don’t drop these—a machine learning model into a void. You drop it into replace something else. In theory. And it may not be replaced because they may ignore it. So, what is it replacing? And how stuck are people to keeping that old thing that they’re attached to right now? Maybe they’re not. Maybe they’re ready to accept some—anything would be better than what I have now. Maybe. I think a lot of the time, that’s not the [laugh] situation.

 

It’s, “I don’t have time for this.” Like, everything’s a tax, anything that’s going to slow me down, everyone’s busy, no one wants to relearn. I mean, we see this all the time, right? Like crappy software, you know, people just—“I know how to do it. Yeah, Microsoft Word, it’s terrible, but I know all the keyboard shortcuts. Don’t make it better.”

 

Klara: Yes.

 

Brian: You know? And then they, you know, that’s that famous story of them redesigning all the ribbon navigation and all this kind of stuff, they had to take the hit because they had created this Frankenstein, and at some point, they had to take the hit. And it was very disruptive to people who had learned all the shortcuts and all the crazy—the model—the mental model of how that thing was designed. They had learned all of that, and it’s tough. So, again, shorter iterations help us not go so far on the wrong track that we have to then introduce a giant change. Because change is so hard. It’s so hard getting people to change behavior. So difficult [laugh].

 

Klara: Yes, it’s true. And I mean, in the end, what I think when I talk about, like, behavioral science, what I actually want to infuse is just a more humane approach to things. Because we are humans, so on the one-hand side, we are humans when we design stuff and we can exploit this. So, we have this abductive thinking, so we can create stuff, and we can make new connections, and it is helpful for us to be inspired, as humans, to work on stuff. And then also, when we think about our future users of our products, they are humans too, and they are not a homo economicus, who’s just making analytical decisions; they’re making their decisions based on all kinds of stuff, and it will only be helpful for us, as designers, to understand what is actually driving their behaviors to make sure that our products our being used.

 

Brian: I want to give you the last word, just any kind of closing advice, and I also want to figure out how people can follow you. I don’t know if you’re on LinkedIn, or Twitter, or any of that. But last words, any words of advice for, kind of, the data product leadership audience that’s out there? Any big takeaways that—or messages that you want them to hear?

 

Klara: Yeah, I think I have one piece of advice for people. I think, at this moment right now, we have—one thing that we haven’t talked about right now which is generative AI and all these other machine learning artificial intelligence tools out there, and everybody’s asking me, “Okay, so what can we do with this? What is the next use case for this and how should we work with it?” And then the immediate next thing is, “Hey, let our data analysts and scientists and engineers build stuff and find out what data is now available and what language models are now available, and then they will come up with these awesome solutions.” And I would advocate for a different approach because when you look at, back in the days, like, maybe, for example, around the time when the telephone was invented, I think there was this guy called Bell, and he did invent the telephone, and then there were all these ideas: “Okay, what could we do with this?”

 

And there’s actually a guy called Akio Morita—he’s the founder of Sony—and he understood, okay, so we have, now, this opportunity to make electronics much smaller, and we want to do something valuable with it. What do we do? And what he actually did was, he went exactly to people’s places of work in their home, and wasn’t relying on any kind of market data or quantitative analysis. And he just watched people do what they try to do, and based on that, he came up with all these great tools, like the Walkman, who then made millions of people happy. And I hope this is also the approach that people could now take with generative AI, to just try to understand, okay, what are people trying to get done, and then how can AI or machine learning or language models help them? And not the other way around.

 

Brian: I think that’s a great place to leave this. Thank you so much for coming on the show. Where can people check you out? Are you LinkedIn, Twitter, where do you—anywhere out there on the social media?

 

Klara: Yes, I think probably the best place to find me is on LinkedIn. So, I’m there. And I have a private website, but as with every website, it’s not updated on a monthly basis. So yeah, just find me on LinkedIn.

 

Brian: [laugh] Okay, that sounds good. And again, if you’re listening in real time to these episodes, December 19th, 2023, for DPLC members. It’s at 10 a.m. Eastern, so it’s a little bit earlier, just because Klara’s in Europe, and we’re experimenting with different times. So, the talk is titled “Tackling Low Adoption of Data Products Using Two Frameworks from Behavioral and Cognitive Science.” So, Klara Lindner from diconium data, thank you so much. I’ve been looking forward to doing this for quite some time, so it’s great to finally get this on tape.

 

Klara: Cool. Thank you so much, Brian [laugh].

 

Brian: You’re welcome. Take care.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.