Transforming Product Development with Behavioural Science (With Liz Immer)
Product AgilityMarch 21, 2024x
11
00:43:1329.71 MB

Transforming Product Development with Behavioural Science (With Liz Immer)

Send us a text

Liz Immer stands as a guiding light in the realms of product and experience design, utilising the principles of behavioural science to elevate both team dynamics and product offerings. Celebrated for her inspirational leadership and capability to nurture growth in others, Liz's approach, characterised by genuine, direct feedback, consistently pushes boundaries beyond the ordinary. Her commitment to exploring deeper insights and challenging norms has solidified her position as a pioneer in crafting environments where both users and colleagues thrive.

Liz on LinkedIn - https://www.linkedin.com/in/lizimmer/

In this episode, Liz reveals the impactful role of behavioural science in redefining product development, providing invaluable insights for those dedicated to creating resonant user experiences. By marrying the concepts of experimentation and evidence-based decision-making, Liz sheds light on how to apply behavioural economics effectively to forge strategies that are both innovative and focused on outcomes. This discussion offers rich perspectives for anyone keen on refining their product strategy, enhancing usability, and enriching the customer experience.

Embark on a journey that connects theoretical insights with practical applications, highlighting the critical importance of user research, strategic thinking, and the essential role of facilitation in creating spaces where creativity and innovation can flourish.

Key Highlights:

🔍 10:16 - Key Tips For Product Design Success

🔍 13:11 - The Power Of Room Dynamics In Facilitation

🔍 19:49 - Challenges Of Implementing Behavioural Changes

🔍 23:39 - Breaking Down Hierarchy

🔍 39:10 - Laws Of Systems Thinking

For enthusiasts eager to integrate human behaviour insights into product development, this conversation with Liz is a must-listen. Explore how behavioural science and design can merge, offering strategies to create products that surpass user expectations.

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility


Listen & Share On Spotify & iTunes


Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Speaker 1:

We run the workshop as a fake design sprint. We always have some sort of a nebulous business challenge or problem, and then the first question that we ask people to answer is what's the goal? And ask them to articulate the goal from a few different angles, including, in some cases, revenue-based KPIs. That is important, but then another part of the goal is what would people need to do in order for this goal to be achievable? And I've now done this exercise with 30 groups from 30 companies from different departments, with smart, experienced people, and it is rare to come across a group that is used to thinking in that frame.

Speaker 2:

Welcome to the Product Agility Podcast, the missing link between agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world-class thought leaders and practitioners. Why, I hear you ask. Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep-rooted belief that people and products evolving together can achieve mutual excellence. Hello and welcome once again to the Product Agility Podcast. My name is Ben Maynard and today I am joined by Liz Immer. Now, hello, Liz.

Speaker 1:

Hi, Ben nice to be here.

Speaker 2:

Yeah, nice to have you here, liz, nice to meet you at last. I say that like we haven't just spent the last 20 minutes chatting anyway, but no, it's nice to meet you because our paths almost crossed back in October. But before we go into too much detail on that, I want to tell you a little bit about Liz. If you look at her LinkedIn tagline, I think it's brilliant. She's about better products, better teams and a better world, which is a high bar to set. She is a product and experience design leader, an individual contributor that's highly sought after.

Speaker 2:

I'm really specializing in behavioral design and it's that behavioral design, behavioral science aspect that I've been really keen to delve a bit more deeply on, especially given my previous episode that came out with Judy Dirkson talking about behavioral science. Like I really want to get deeper on some of this with Liz. So I have spent I don't know an hour or so with Liz over the last month or so again in preparation for this, and I can say that I found Liz's company inspiring. I found her very forward thinking and she has a natural ability to help me relax and to ask good questions. I hope you find her very inspiring as well. Liz, welcome to the Product Agility podcast.

Speaker 1:

I'm looking very much forward to the conversation.

Speaker 2:

We could have had a conversation at Productized 2023, but we had a near miss because I was unable to attend your workshop because I was interviewing. It felt like the world.

Speaker 1:

And then I didn't even swing by your booth because there was so much going on. It was an amazing vibe in that conference.

Speaker 2:

Wasn't it? When it ended, I felt like I just left a festival. I felt like this kind of hollowness inside.

Speaker 1:

And I felt it was interesting. I went to Productized, to be honest, feeling quite nervous. Covid is now behind us but still, going into these big events, I feel some social anxiety that I didn't have when I was younger and I didn't know really anyone there. But when I left three days later I felt like I had left a family reunion. It was such an amazing community that the team built. Yeah, I don't know how I did it.

Speaker 2:

I connect afterwards and keep it going?

Speaker 1:

Are you going to?

Speaker 2:

Productize this year. Oh, that's a good question.

Speaker 1:

That's a good question. I have not thought that far ahead. I've been so focused on the present.

Speaker 2:

Wow, yeah, absolutely. Me and Andre struck a deal at the end of Productize last year that I would be coming back with the team and we'd be doing the same again because we had such a blast. So, yes, we will be there. The podcast will be there. You'll save her an extra day this year as well, I think, and this year I hope to be running a workshop myself, but let's see if that transpires.

Speaker 1:

Very good. Yeah, I need to reach out to Andre as well.

Speaker 2:

Anyway, at Productize, what workshop did I miss?

Speaker 1:

Yeah, so at Productize I actually did two things. Initially, I was just going to be hosting this workshop session and ultimately I also had the pleasure of speaking on a panel led by Inej Liberato about the topic of responsibility in AI who's responsible for AI? But the workshop that I hosted is called Better Products through Behavioral Economics, and it is a training that I developed along with some colleagues over many years, because my background is in behavioral economics. I started out studying human cooperation in a laboratory and we studied how people behaved under certain conditions in the laboratory and then used the data that we had collected to tell some stories about the world.

Speaker 1:

And ever since that research experience at ETH, down the road from where I am in Zurich, I've been working with different kinds of organizations mostly companies, to consider what cooperation means in their context.

Speaker 1:

Usually it's about bringing their employees to cooperate with each other or bring their customers to cooperate with each other or with the company, and I've been working to design products and experiences that bring people to cooperate and bring people to make better decisions, behave better for their sake and for the sake of the world.

Speaker 1:

I've been doing this for quite a while and what I've recognized in the process is that a lot of Teams, a lot of people are spending a lot of time working to build products that bring people to do a certain thing or bring a certain value to people by bringing them to change their behavior, but they're also wasting quite a lot of their energy because they're missing some pretty simple foundations that I had. So we developed this training to give forward what we had learned from the decades of research in behavioral science and equip people with some tricks and tools to really multiply the value that they could bring with the time they were investing in product design. So it was a three hour workshop and we taught some fundamentals of behavioral economics and some tricks and tactics to move forward.

Speaker 2:

Behavioral economics sounds very complicated, but this does to me my simple mind. Can you perhaps for the listeners and actually not for the listeners for me explain really what we mean by behavioral economics? So what is this?

Speaker 1:

Sure One could describe traditional economics and maybe this is what you learned about when you were in a first semester econ class Maybe some of the listeners had this too, as did I when I was studying that economists assume that people are perfect they call them sometimes perfectly rational that we most of the time are able to pull in information, compute in our heads perfectly and make perfect decisions all of the time. And it's thanks to this that that markets clear, that demand meets supply at some price point in a graph and the world moves forward. And the assumption is that there might be some exceptions to this, but on the whole, people are rational actors and guided by self interest. I studied economics and in my bachelors I was going to the classes, I was doing the coursework, but as a 20 year old I was uncomfortable with a lot of the stuff that I was reading in the books because it didn't reflect what I was observing in the world. And that's the starting point of behavioral economics.

Speaker 1:

This is the intersection of psychology and economics, and by now there's been really decades of research happening in these fields also in sociology, anthropology, in finance that are complementing and building upon each other. But it's the study of why people behave that way that we actually do. It's not psychoanalysis. We're talking about big patterns across human behaviors. If we observe that people are not actually optimizing for their bank accounts consistently all of the time, what are people doing and why are we doing what we're doing? And the scientists, especially the applied scientists and the practitioners who are working in the field, are considering, with this knowledge of how people are really ticking, what could we tweak in our environments that would promote better behavior in people? Why do we do what we do? Why do we cooperate?

Speaker 2:

There's a huge thing, then. This is not something which is just then specifically for a very narrow field. What we're talking about is something which could be applied to many different contexts and I suppose then productize we're talking about how this can be applied from a product strategy, design perspective or UX perspective.

Speaker 1:

Yes, exactly that is the focus of the workshop that I was running there. It was focused on product design and to end product or experience design in a way that's really accessible. I hear, to product managers, designers, researchers, engineers and marketers, and that's really important to me because these are people who are crafting mostly digital experiences that are reaching millions and millions of people, and I tend to focus my energy on these people, the product crafters, because we have extreme influence on other people. But in the panel, we were talking more about the workplace and how to craft not the AI itself, but the workplace in which people are building code, in order to promote those people making more responsible decisions.

Speaker 2:

Let me say craft. Let me just take that workplace example. We're saying can't we craft the workplace? Are we talking about the physical things in the office? Are we talking about policies or processes? We say craft. What are we crafting?

Speaker 1:

Yeah, that's such a wonderful question. It can all matter. Before you pressed record, you and I were discussing OKRs. The goals that we have can be tremendous incentives that influence behavior. We were talking about a really difficult story in which a company was really hungry and really passionate about pursuing their objectives that had been defined. Unfortunately, later they realized that the two objectives they had set were critically in conflict with each other and actually crushed the business. In that case, the OKRs were leading teams to spam the target audience and really saturated the market and lost patience. Okrs can also do that when it comes to AI. If we have a goal, people tend to be running towards it, and this can be a part of the environment that matters a lot. I'm probably not going to spend a lot of time thinking about which pens or pencils to put in the mug on the side of the desk, but, on the other hand, we know that haptics do influence people.

Speaker 1:

Several years ago I was working with a company, sharepony, that was building a software to support executive meetings. What is a meeting? A meeting is a moment that in a huge way shapes the way that we and our teams think and act in our world. What's happening in that meeting has ripple effects after the meeting. Why does the meeting happen the way it does? Priya Parker wrote in her book I don't know, maybe she made the statistics to go, but she said the room does 80% of the facilitators work because it provides so many cues to the people. You imagine a really big board room with a long table and huge leather chairs.

Speaker 1:

You feel that there's a certain weight to everything and maybe the person at the head of the table feels that they should be talking a lot. Or compare that with a workshop room that has a lot of whiteboards. You feel that you're supposed to be thinking creatively and getting your hands dirty and collaborate. When the case of this software, we realized that we had a lot of imagery in it that was really pumping people up, but actually what they needed was exactly the opposite. They needed to be calmed down so that they would be better able to listen to others, think more deeply and get out of the frantic grind that they were otherwise in in their day to day. So in that case, the environment, the physical, the visual environment we ended up really calming down the imagery and the colors. If we come back to this behavioral science lens, it brought people out of the instinctive frantic. We sometimes call it system one you talk about this a lot on your podcast.

Speaker 1:

system one zone into the more reflective, more rational I'm saying this in quotation marks system two. So when I'm thinking about organizational design, of course people tend to be in this automatic zone. We're stuck in it 90 to 95% of the time. We can't do so much about it. But If I tied this together for a second.

Speaker 2:

You were saying at the beginning that economics assumes that people are perfect and so they're assuming that people are putting in that lovely conscious rational thought over time. That's more like system two than it is system one, but we live most of our lives in system one, which is Most of our lives in system one.

Speaker 2:

Yeah, sorry, go ahead, nice, we are putting thought into what we do, but it isn't the higher level for, which then means that we don't eat the extra doughnut or space Spend the extra five pounds that we could have gone to our bank account for saving for the holiday.

Speaker 1:

Yeah, exactly, and we can do things for ourselves and for others that cue us to activate our system. Two, to think a little bit more deeply or consider the counterfactual. But we can also make it very hard for ourselves to do those things. One example that I guess most of the folks listening to this podcast might relate to is a remote work setup in which colleagues are on Slack or Microsoft Teams and I can say, when I've been working in larger organizations it can feel like I have no second to breathe, much less have a reflective thinking time, because of the pings or the red dots or the bounces that are coming from the notifications in these programs. And the first things that I do when onboarding new employees is to get on Teams with them and shut down as many notifications as possible and to put blockers in their calendar of really carved out time where they have to sit quietly, because I know that when we get more frantic, when we get more stressed, we tend to get, indeed, more stupid.

Speaker 1:

And if we develop habits of being reflective, we can do more of that even when we're stuck in our system one. So we can build in some habits, some tricks that will help us even when we're in our 90% system one time by using our 5% to 10% system two budget to build in those structures that help us. And that's also what we do with the workshop, actually it's. We could talk more about the content. I don't need to keep it behind a curtain, but much like a design sprint. We took a lot of cues from the Google design sprint setup because that's what it does, right, it doesn't force people to spend their whole day in system two, but it does guide people through a series of exercises that help to ignite the parts of their brain and do various things to come up with a quite smart solution by the end of their process.

Speaker 2:

What you were saying about Slack and various other communication tools. When I ran a workshop a couple of weeks ago and we were doing some systemic improvement, modeling one group, their main focus was on reducing the noise that the teams were facing. And so when they built their hypothetical cause and effect model to say, okay, if we want to reduce noise, what are the things that contribute towards noise? And then why are they contributing? And then what sparks off those things? And then actually what they saw was that if they could reduce the noise that was coming from Slack and Teams, when they believe that help reduce the noise.

Speaker 2:

But what I was really interested in, which was I know that putting things on mute, turning off notifications, could help. There was a CTO that I used to coach and the biggest breakthrough for him was putting Slack on mute, so he didn't feel like I had to contribute all the time. But then I did begin to wonder if you go a step further back in the system and say, okay, yes, all these notifications are going off, why are people choosing to broadcast all of this? There's a bigger cultural system there and it's probably because they're not thinking about what they're putting out. They're just putting stuff out and you end up with a very vicious cycle that we end up in.

Speaker 1:

I'm curious to hear from your workshop cohort if they followed through and if it ended up helping them. I would be surprised if not.

Speaker 2:

Yeah, we are getting together actually and looking at their models and their experiments. Hopefully it's gonna be another couple of weeks. I met a couple of them with the training I delivered this week and my training from the back of the room course. But what's really interesting is because we get them to build a model and then an experiment based on the model. The two kind of work in coalescence. So I'm gonna be really intrigued to see, yeah, how have they been able to reduce some of the noise and has had the effect they wanted and were they able to do it in a way they thought they could do?

Speaker 1:

What I think is critical in this and it's something I've observed and makes sense it comes also in the behavioral science literature is the challenge in designing that solution so that it lands well.

Speaker 1:

What I mean is imagine you're the person who wants to reduce noise and so you put yourself on mute. Well, a that's probably something that might be quite hard for you to do, especially nobody else has done it. It can be costly to make yourself different from the rest of the folks around you, and it can also be difficult to send the right signal with that move. Maybe you're not actually silent quitting, but people think you are because you are not as active anymore on Slack. Or I've been in organizations where some individuals have dedicated their Friday to be a no meeting Friday. But if just one person does that and the rest of the folks are still in meetings, in big meetings maybe it's just one woman or one guy who's missing out and rejecting those meetings. Some people feel rejected and other people are actually missing out, and it's hard to do that. In a way, that's.

Speaker 2:

It's a similar example but it's a little bit different when I look at techniques and I've got to lean on the kind of the intersection here between products and agile a little bit. But you look at user story mapping, I really love it as a technique. Teams seem to quite enjoy it. But when you get a group of people who are just working their own technical tasks and then one of them turns on and says I think user story mapping could really help us, and then they try and put it into place and then maybe they have some training and try and use it, it never works.

Speaker 2:

Because user story mapping means you have to work as a team and as a team say this is how we would all work together to solve this user problem. But when you're a group and you're just working on your own little technical pieces, everyone turns over and says I can go and do the database work, I could do an API for these things, but they're not used to coming together and saying this is how we will solve the problem. So one person deciding oh, let's do user story mapping. There's actually one person deciding in this instance we're going to stop being a group and now become a team, and that isn't a single person's decision.

Speaker 1:

Or if it is a single person's initial decision, they have to have quite a lot of technique and charisma to turn it around, and I guess you're familiar with the book Switch by Chip and Dan Heath. Yes, exactly it is. If that's a change to not Some people say bring the team along with you. To form the team together and take a journey together is an exciting but can be really difficult. So difficult it's behavior, change it's behavior change Same much as behavior change.

Speaker 2:

I think we've been talking for 25 minutes. I feel that we've focused down on something, but specifically in a moment. So I've got a few questions. But you mentioned about the changing of the design of the set of meeting rooms. Yeah, and I spoke to a gentleman called Evan, a facilitation guru, and he said that actually the beginnings of cultural change can happen if people decide to change the way that they run the meetings, because that's where all of our behaviors manifest, all the echoes of all the decisions that have happened previously. That's where it all comes out. And they reminded me then, when you were talking about changing to the design of the rooms, of an architect called Norman Foster and his group of architects designed the Gherkin in London Wembley Stadium, the some amazing buildings, and there's a wonderful documentary many years ago on a very British, myosavis. I'll have a sip of my tea afterwards. It was on the BBC and on the BBC it was called the Architecture that Changed Great Britain. Notice this one little segment where I think it was Norman Foster.

Speaker 2:

At Spain They've left university with always amazing ideas of these buildings that they could create and will design. But when they gave them to the builders and the construction firms. It was awful. They were falling apart. They couldn't get things working in their way. They wanted them to work. They were shoving newspaper in and plastering over it and say what can we do about this? And they did.

Speaker 2:

One thing which changed the whole relationship and actually enabled them to build these amazing buildings Was that when they got to the point where they were sharing the initial designs with the construction companies, they went from having a boardroom table with the architects at the end and the construction teams leaders down the sides, listening to a round table where there was no hierarchy. And it was removing that physical hierarchy by having them sit around a round table that enabled the architects not to be seen as the leaders who couldn't be challenged and allowed the construction leaders to say if this isn't going to work, or what if we did this, or why have you done that? And it was that shift, he said it really may enable some of these amazing buildings to be constructed, not just designed.

Speaker 1:

Incredible story, wonderful, and how much we can take from that, even to something as maybe banal as thinking about a hybrid meeting, which I think most of us are having, what can we do to build the right dynamic?

Speaker 1:

in that space. I spoke with Gardner, the I think they call themselves the Research Institute, several years ago about spaces and the future of work and I asked what are enterprises who are really thinking and making great progress today? What are they working on and what are they afraid of? And the answer he gave me was they are petrified that they are in the midst or at the start of the anti democratization of the workplace Because of the way there was so much investment into agile and into democratization of many workplaces. Covid hit. Everybody went home. Then it was really democratic because everybody was in their own room, Then some people moved away, Then some people stayed at the office and it has ended up in many organizations that there are people in the office and there are people like in Kansas and their home office or wherever, and ultimately they're observing that a heck of a lot of decisions are not made in meetings anymore.

Speaker 1:

They invested in meetings but they don't matter that much anymore because things are decided before or after the G meet call starts at the coffee machine or something we talked about. What are the best companies doing? I said the best companies are investing in hardware for their offices especially, and software Big screens and Miro licenses, because Miro is a tool that's enabling really bringing people to make the decisions through voting, for example in the meeting. So it becomes much less attractive to do it before or after, because it's so fun to vote on those cute little post-its.

Speaker 1:

So that's a design aspect of environments that I can change behavior in a huge way through the features and the micro animations Micro animations. Yeah, I don't want to. So if anybody from LucidSpark is listening to this, you can call me and I will be very glad to discuss with you. But indeed, something I've noticed I've worked with Miro, I've worked with Fig JM and I've worked with LucidSpark. Have you worked with these various whiteboarding tools?

Speaker 2:

Yeah, so my right, I use LucidSpark. I used it briefly when I was doing some work with a UK broadcaster, channel 4, but I only briefly.

Speaker 1:

Yeah, so LucidSpark and Miro have almost the same features. If you make a list of the features, I think the only Big difference, at least when we looked at it a few months ago, is that there's no music and Lucid spark as a bonus.

Speaker 2:

I'd argue that's name music in my row one might say sorry.

Speaker 1:

That we switched from using me row or my row. I think it's me.

Speaker 2:

It's mirror like hero.

Speaker 1:

However, but you're calling it.

Speaker 2:

I quit it, my row, like by row, because if it had been in front of it, it says by row. So I'm sticking with by row, because I'm a grumpy old Englishman.

Speaker 1:

Okay, good, you do you so Running workshops running retros using, you know, running workshops running retros using Lucid spark. People get less creative, less brave, less vulnerable, less transparent, less open in Lucid spark, compared to me row really. There are more colors for the post-its. In Lucid spark they have that going for them beautiful colors. But the micro animations, the little things that make me row feel good, do matter a lot to the people who are touching it.

Speaker 1:

That's fascinating fake jam also does it. It's also much better experience in fig jam and people are behaving well again.

Speaker 2:

That's really fascinating. Let me say micro animation. Could you give me, is it possible to articulate what that's just like?

Speaker 1:

I'm thinking of just the way it feels when you move a post-it or Even the blinking cursor on a post-it type setting on a post-it. All of these things are so small and I most people do not notice them in a way to articulate these small differences, but they're there and and people subconscious notice and reacts to them fascinating, really fascinating, and I'm just still also reading from the over democratization anti anti. So, it's democratic. Yeah until it's at the coffee machine.

Speaker 2:

Because, yeah, it's really fascinating. I know I'm not gonna go down the rabbit hole too deeply, but I've always explained One of the issues that I see in. I spend a retract. I'll go back. My editing is Take so long because I start sentences, then stop and then start another one. I'm so annoying. I'm not the worst person to edit on a podcast, oh God, I exhaust myself. I Spend most of my time working in large tech organizations or medium-sized tech organizations that really want to get on the product bandwagon, really want a product mindset, but they weren't designed to do it.

Speaker 2:

So there are lots of things that need to change in order for them to be where, even close to where they'd love to be. They never be where they love to be, but they can get closer and there's a lot of value in moving along that pathway. But what many of these large tech organizations have done is what I've historically called over empowered, which I might now see if it's actually calling anti democratizing the prioritization process by virtue of how they've designed their products. They say. What many tech firms have done is that they've taken their technical architecture and then split up the technical architecture and called each of these technical components products and then put someone in charge of that product, when actually then they have lots of opportunity to really severely Locally optimize just their one part of the system and they have no need to really liaise with all the other product people to figure out how it's all going to come together as a whole.

Speaker 1:

You're Rewarded for optimizing your piece absolutely and penalized sometimes for doing something differently.

Speaker 2:

Yeah, and you are totally within your rights to say I've done my bit, I've done my bit, we're moving on to the next bit. And I actually remember conversations like this, particularly one bank I used to work at, where people would be saying I've done my bit and we're waiting on them, so we're moving on to the next piece now. And just so you know, when they do finish their piece, it's going to be six weeks before we can even think about picking up their piece to make it work with our piece, because now we're starting something else. There's no wonder we're wasting so much human effort, no wonder we're wasting so much human intelligence and creativity and energy, because we're just, it's anti-democratization, it's over empowerment, at the end of the wrong lens.

Speaker 1:

It's the wrong goal, isn't it? If the goal is to optimize, if the responsibility that a person or a team has is to optimize a feature set, is that over empowerment, or is it just wrong scope of empowerment?

Speaker 2:

Yeah, I'd say it's Probably the latter and then it's the CPO.

Speaker 1:

I would my opinion, like it's the. Pio's responsibility to consider what the scopes of empowerment should be.

Speaker 2:

Yeah, but I say that. Then there's a Bigger question, could you absolutely right? So I'm waving around my stupid little paintbrush. It's for dusting things. As a hobby, I fixed Nintendo switches for people.

Speaker 1:

Dusting out little things.

Speaker 2:

Yes, yes, no, I ended up out the Absolutely a lot of it. I think any companies that have got a good grasp on actually what their product is Then access. The role of a CPO is to bring together these feature sets. But the issue I find in technical organizations is they don't actually know what their product is and these little. I wish they were feature sets. Often they're not. They are just technical components which don't solve any customer problem once that work is complete.

Speaker 2:

Yeah and say with what you were saying about, is it the wrong goals? Yeah, if I think it's. All of it is. The system is optimized for trying to achieve one thing. When they're articulating, actually they want to try and achieve something different. They're not evolving the system, they just change the labels on the existing and it's so scary to change.

Speaker 1:

At least, this is what I've observed in the organizations I've worked with. The ones who get to this moment they realize it's not working. I had one. It was a wonderful experience. I came in and I was new in the team and and I asked to look at the the usage statistics and I got a whole readout of usage of individual features. You know, adoption, retention, blah, blah, blah.

Speaker 1:

But nobody had thought about the use of the whole software or when the whole software was being used and they were doing an excellent job of Empowering the product teams and getting them to optimize for their feature adoption and retention, hopefully, but they had totally forgotten that the bigger picture and Ultimately it turned out well. But it did take two years, in part because the teams were working so well and nobody wanted to break the teams and the features were being maintained and it felt like a big risk to let go of that the ownership of the components and the features. And it took a lot of courage and talk about and design of the environment. So you need to design an environment where people can have courage and also identifying the writer goal, which was usage of the whole software. But it.

Speaker 2:

Yeah, it was really scary, especially for the engineers and the technical leadership, the ones who were it's that, it's that holistic system awareness and I see, I see in an organizational sense or even in a product sense, and we talk about that, goals for the system, is it a goal for the organization, a goal for the product to go for the team? How complicated do you want to make things for people? We mentioned OKRs. It's a bit of a guide to saying have three to five OKRs, yeah, but if that happens two or three times for an organization, you've got hundreds Of different things which are trying to measure and understand where it is, and that there's nothing for focus. Sure, so strategy.

Speaker 1:

Yeah, I guess I'll use this as a segue to talk about this workshop which you didn't get to attend.

Speaker 1:

Yeah and maybe I can fill you in on a little bit more of it, because this is really one of the first hearts of the workshop which I find so moving. Almost every time I run it um, we, we run the workshop as a Fake design sprint. We always have some sort of a nebulous business Challenge or problem and then the first question that we ask people to answer is what's the goal? And ask them to Articulate the goal from a few different angles, in including, in some cases, revenue based KPIs, because that is important. But then another part of the goal is what would people need to do To do in order for this goal to be achievable, and I've now done this exercise with 30 groups from 30 companies from different departments, with start experienced people, and it is rare to come across a group that is used to thinking in that frame.

Speaker 1:

What would people need to do? Get a lot of answers like, oh, they need to. What would people need to do in order to renew their subscription or something they need to think about the service we're providing? Maybe it's necessary, but thinking is different from an action and I love the mental exercise, the energy that we see people then putting into taking on a different frame and, maybe for the first time considering customer behaviors that need to be shown, because when we observe that teams start to do this little thing, this can be the trigger that all of these great ripple effects come from. So once the team realizes that usage of the software if it's a meeting software, you might want it to be used before the meeting. That's really important to set the meeting up for success. Once you have that clarity, boom.

Speaker 1:

Product management, design, engineering, qa Everybody has what the Heath brothers call a destination postcard. They can feel the goal pretty vividly because they also have meetings and they might use a software before a meeting. They can think about that behavior and internalize it to a degree. How did I start on?

Speaker 2:

Yeah, by the way, I think it's great that you say that, because there's 11 laws of systems thinking which I am spending more and more of my time trying to get back in tune with, because I read them, I love them, I forgot about them, but one of them is small changes can have big results. I think, when we're thinking about systemic change, having users tune into the users and their behaviors can yield huge results, and what you explained there reminds me a lot of something called impact mapping, which have used a lot, because where you start of the goal but ultimately what you end up most of the conversations about as well who needs to do what differently?

Speaker 2:

What do they stop doing? What do they start doing? Because it's that, what do they need to continue doing or do more of? Because that's the missing link and so much of what we do Is that behavioral aspect.

Speaker 1:

And what I love about impact mapping is that it can act as a check for the design team and I'm going to use the label design team to describe the whole team of crafters who are involved in creating an experience and QA.

Speaker 1:

Can belong to this, of course, the rest of the Crest Functional team as well as the design team. They might start with a revenue KPI and then they might break it down into what we could call Josh Scheiden would call a desired outcome the thing that somebody needs to do, and then, if you look at it with an impact mapping lens, you get an extra push to consider Is this actually something that people want to do? Because it can't all be about getting people to do something that you want them to do. If it's not going to serve them, they're at some point going to stop doing it. Even if you're making a B2B product, people ignore things all the time. That's super important Because if yeah, I said I started my career study in cooperation and we know people feel like they're being tricked or pulled out of something that they want to do, they're going to start revolting at some point and they need it like that.

Speaker 2:

No, there's so many different things I want to talk to you about, and what I'm wondering is if we begin to draw this episode to a close and then we'll have a break and then we'll record another one, if that's OK.

Speaker 1:

Yes we can.

Speaker 2:

Bringing this episode to a close here maybe leaves a few loose ends that, honestly, I think we can pick up in the next episode, because there's been so much that you said my mind has been whirring with so many ideas, so much I'd love to quiz you on, so much I'd love to share with you, which obviously I would do in the podcast but there's just stuff that I really want to speak to you about that I think my listeners are finding interesting. So just to end this in the usual formal way if people want to find out more about you, where should they go?

Speaker 1:

It has been wonderful to speak with you and I look forward to the next part of our conversation. If people want to find me, I'm really easy to find on LinkedIn Liz Immer, I double M-E-R. Which fun fact. I guess not many people speak German who are listening to this. Immer means forever or always in German. Maybe that'll help you remember.

Speaker 2:

Love it. That's a good tip. I'll put the LinkedIn profile URL into the show notes as well, so it makes it nice and easy for people to find you. And thank you so much for coming on. I could listen to you talk for a lot longer and I look forward to doing that shortly. Thank you everyone for listening. Don't forget if you've enjoyed today's episode, please do leave us a review on your preferred podcasting platform. Your reviews do a huge amount to help us get more recognition and to bump us up the charts and help share some of the awesome stories that we have coming from our brilliant guests. So, liz, once again, thank you very much for coming on for this first episode of 2. Everybody, thank you very much for listening and we'll be back again next week.

Liz Immer,Behavioral Science in Product Design,Product Development Strategies,User Experience Design,Behavioral Economics in Technology,Innovation and Behavioral Insights,Evidence-Based Decision Making,User Research Techniques,Enhancing Team Dynam,