About this podcast episode

🎙️ How well do you know your users and the problems you can solve for them?

We are excited to have Debbie Levitt, Founder of Delta CX and author of Customers Know You Suck, as a guest on today’s podcast.

Bill and Debbie share relatable stories highlighting the challenges of maintaining a customer-centric focus, the need for early research and testing, and the importance of accountability in delivering high-quality products.

Here is what you will learn:

✅ The importance of tying work to real customer problems and pain points

✅ The need for early research and testing to ensure you are building the right solutions

✅ The role of accountability in driving better outcomes for customers

🎉 How to ensure your teams remain customer-focused!

Transcript

(transcripts are auto-generated, so please excuse the brevity)

[00:00:00] Podcast clip

[00:00:00] Bill Raymond: There’s a product that I used very frequently and it had one of the greatest features that if you will, beat out all the other competing products in that market space.

I got a very close relationship with the developers, and they kept talking about how difficult it was to maintain that feature, which I totally understand.

And what they did was they buried the feature.

[00:00:23] Debbie Levitt: And then said, no one’s using it!

[00:00:24] Bill Raymond: And then said, no one’s using it, exactly.

[00:00:26] Debbie Levitt: I’ve seen that. I’ve seen that as well from a company I won’t name. And it was like, oh, you’re just trying to kill this and you’re using the metrics as the reason to kill it. And, but it’s completely unfair and not customer centric.

[00:00:39] Intro

[00:00:39] Speaker: Welcome to the Agile in Action Podcast with Bill Raymond. Bill will explore how business disruptors are adopting agile techniques to gain a competitive advantage in this fast-paced technology driven market.

[00:00:52] Bill Raymond: Hi, and welcome to the podcast. Today I’m joined by Debbie Levitt, author of Customers Know You Suck: Actionable CX Strategies to Better Understand, Attract, and Retain Customers.

Debbie is also the founder and principal at Delta CX. Hi Debbie. How are you?

[00:01:09] Debbie Levitt: Hey, I’m okay. How are you doing?

[00:01:11] Bill Raymond: Great. Thank you. I’m looking forward to our conversation. We talk a lot about Agile on this podcast and we cover lots of topics like psychological safety and teams, but we also talk a lot about things like frameworks like Scrum or safe or what have you.

And sometimes we might. Start to get a little bit too focused on the frameworks and the actions that we need to perform and we forget a little bit about the customer So we’re going to talk about returning to agility by leading with the customer. And before we get started, could you introduce yourself a little bit?

[00:01:44] Debbie Levitt: Yeah, absolutely. And thanks again for having me on. I’m Debbie Levitt. My company is Delta cx. I’ve been working in CX and UX for decades, and, I’m a researcher, a, an information architect, a designer, a strategist. I am not an artist. I’m really that person who comes at the customer experience from the from, from the angle of, behavior and customer needs and making sure we’re doing the right things for them while balancing that with what the business is trying to accomplish.

So typically I’m doing, research projects or sometimes consulting with companies to help them improve some of this customer centricity stuff, especially when people feel like it’s working against Agile or agile works against it. It’s not playing nicely, teams aren’t playing nicely. So that’s, some of the stuff I do.

And thank you for mentioning my new book. Customers Know You Suck, which is a, how to manual for customer centricity.

[00:02:41] Bill Raymond: It’s a catchy title.

[00:02:42] Debbie Levitt: Thank you.

[00:02:43] Bill Raymond: I like to start the podcast with this general question: could you share what Agile means to you?

[00:02:49] Debbie Levitt: Yeah, that’s a wonderful question and something I have been thinking about lately, in fact. I think about. agile being a few different things. I think about it being a system or paradigm or framework, to help usually engineers or people in en engineering roles, improve their efficiency, improve their velocity, make sure they’re delivering more value to users and customers and partners and everybody in our ecosystem.

I’m old enough to remember the waterfall days. I remember the project that took a year and a half and we hope someone likes it. I think of Agile as being a way to work more efficiently in those smaller pieces and hopefully being more about testing and learning and doing the right thing, as we go.

I always have the Agile manifesto principles swimming around my head, so I think about our highest priority being to satisfy the customer. and it can be through continuous delivery of working software, but I think we might not all agree on what working means.

To me it has to go far beyond does it somewhat function. It’s got to be the right thing to solve the right problem for the right set of users. I think about all the Agile manifesto principles. I know some people feel like they’re outdated or old or oh, that’s decades ago, but I think there’s a lot of good intentions in there that a lot of companies aren’t really following through on that. I think the core of Agile, has a lot of great ideas and approaches, and then the implementation to me, always makes me want to, I don’t know, drown my sorrows in some decaf coffee.

[00:04:28] Bill Raymond: Let’s talk about that then. We are going to be building products at this rapid pace and we’re going to get our product out there to the customer as quickly as possible, but what are some of the challenges that we see with that?

[00:04:40] Debbie Levitt: Yeah, it’s so funny. You know, when I think about all the things we hear growing up, we hear slow and steady wins the race, and we have all of these, parables and things that we say to ourselves and children and society, and families about, take your time. Do it right. I think about songs we heard on, children’s TV shows, and then we get to our modern day and Agile and it’s no faster.

Or you’re going that fast. Go even faster. You what you estimated a five, make it a three. and I think we’ve turned into what I call speed over quality because it, I have, I’m certainly not against, moving quickly. I’m certainly not against, trying to do things more efficiently. But I do feel like the pursuit of that has made us lose focus on the quality as perceived by the customer.

We very often justify quality with, engineering or development terms or QA terms. Like, Hey, is this code, documented, deployable,does it meet our definitions of ready or done or wherever we are in the process? Well, then it’s quality must. Be good, but nobody, or I don’t wanna say nobody, that’s a little harsh, but I feel like the vast majority of people are not asking enough questions about did we build the right thing for the real target audience?

Was this a stakeholder ego project? Are we chasing the wrong metrics or KPIs? Are we doing things that are deceptive or possibly unethical? Did we make someone’s life better today? Or is this just another product that we’re going to want to uninstall or throw out the window? Because I think we’ve all, we all know what it feels like to be on the receiving end of a poor product or software or experience.

We all know what that feels like. We hate when it’s done to us, we can tell we, oh, this company didn’t care, this company didn’t, whatever, and then we go to work and then we do the same things. And so I think we have to. Cut the cycle of mediocrity and I can’t find anything in Agile that says, and maybe I just missed something, but I can’t find anything that says, whatever you do, don’t spend a little more time to be better.

Just go as fast as you can. We talk about lean, and Lean is about, it’s not about going as fast as you can. Traditional Lean was about removing defects and being more efficient because we have better internal processes and we’re creating more quality for customers and users with fewer defects.

And so I’m maybe a bit too traditional or too purist, but these are the things I believe in.

[00:07:09] Bill Raymond: I think those are great beliefs to stand by because I was just thinking about, a customer that I was recently talking to and they were bringing up an issue where they were saying that the developers were moving quickly, but the customer was not testing as much as they needed them to. So therefore to give them feedback and say whether or not this was a good product. And it turned out that the customer, this is all internal, right? This is a company building software,their internal IT department building software for their customer. And one of the interesting things was I went back to the customer and they said they’re asking for too much of our time.

We’re we, we’ve a, we’ve appointed this person gets to spend about 20% of their time reviewing the code, and so we can’t provide you anymore. And so I’m saying, this person, you have an organization of over 150 people. That are gonna be using this tool when it’s done and you have a person spending 20% of their time using it, this should be going out to almost everyone and you should be getting more feedback and you need to have that feedback loop in place.

And it just really rang true what you just said. I mean it, even if we as engineers want the customer feedback, if we’re not all working together as a team to do the best that we can, then maybe the work that we’re doing just shouldn’t even be done.

[00:08:30] Debbie Levitt: And of course that’s Agile Manifesto. Principle number 10. I think, one of my favorites and I just made a couple of notes. While you’re talking and I was thinking, for a client like that, I would be asking them, how do you measure success? Because when this product gets deployed, in that enterprise environment, how will we know that we were successful?

Were we looking for people to get more done in a day or do a certain task in a shorter amount of time? Or are we looking for fewer errors because maybe the old way of doing it was riddled with mistakes. How are we going to measure success? Because then we would be able to say to that person, then what’s the risk?

What’s the risk that we don’t test this enough now? And when we deploy this ends up not meeting your standards or metrics or goals for success. And someone declares this project a failure or, a mini disaster or not successful, will this have been worth it? So I think that these are some tough conversations that we have to have with people, especially about how we’re gonna measure success and all the risk.

And, and one of my favorite things from Lean Six Sigma, the costs of poor quality.

[00:09:36] Bill Raymond: I just shared a story about the customer not being as focused on the results as they need to be, but we have the reverse as well. Sometimes there are teams that are doing the software development, building the product or whatever that product might be, and they say they’re customer focused, but Curious, what are some signs that maybe you’re, you’re saying you’re customer focused, but

it may not be, the way you might define it?

[00:10:04] Debbie Levitt: Yeah, there’s definitely some things that you can see while you’re either in that concept phase or in the development phase. If it makes it that far. One thing that we can take a look at is,what is the problem we’re solving? Let’s start with is there a problem statement? Is there a known user or customer pain point?

Are we really solving something for the customer? Very often we’re not. Very often we’re in feature factory mode and we say, wouldn’t it be cool if everybody got a pink fly swatter, Hey, just make them a pink fly swatter. They’ll, they’ll use it. they’ve got flies and so we wanna make sure that we have identified real user or customer pain points or problems that are either opportunities for us to improve a current product or rethink it, reinvent it, invent something new, innovate where possible. So that’s one thing. Can we tie our work to a customer problem and not something that was reverse engineered later? I sometimes see these user stories where it was very clear that there really wasn’t a use case for whatever this feature is, and it’s somebody’s pet project, and so somebody’s writing these user stories that make it sound somebody will want it. I always like to joke, as a user I need a giant cup the size of my head, so that I can insert user story ending there a nd. You know that might not be the right solution and there might not be a real problem there. Maybe every customer has a cup that they already like.

So I know these are kind of silly examples, but I think one thing is, can we even tie our work to something that is a real problem or opportunity from the customer’s perspective, not just from the business’s perspective. So some tough questions to ask ourselves and our teammates.

[00:11:50] Bill Raymond: Yeah, and I have a great example of that because I’m a little frustrated with the product that I’m using right now. I’m not going to say the name of it, but. I do write frequently and in order to,do my writing, I like to make sure that everything is grammatically correct. And of course, we always misspell words, don’t put the comma in the right place and things like that.

And so I have this tool that I’ve been using, since I can remember that just continues to add all these capabilities to help me make sure that I’m speaking in the right voice and things like that. And it’s a great product. They decided that, because of this whole AI ChatGPT thing, they were just gonna throw that tool in there.

One of the things that’s important to me is when I write, it’s in my voice. people like the way I write, people read my articles because of the style that I have, I like to think, and what I did was I was writing this thing and I said, I could. I could use some help. I could use some, like some something, someone to bounce some ideas off of.

And of course, what do you do? You just copy and paste a little of text, throw it into something like ChatGPT, and it says, here’s another way that you might think about it. Perfect. And then I can go back and, I’ve just bounced my idea off an AI. That’s cool. But now what they’ve done is they incorporated that right into the tool.

And so when I selected the text and said, now give me a recommendation for how I could improve this, I. It replaced all the stuff I wrote with its own AI generated text. It doesn’t look or sound like me, and I’m going, you just did this because you have to put AI on everything now. You didn’t do this to actually help me with my writing.

You’re doing this as a way to replace my content, which is not anything that I would ever purchase that product for.

[00:13:35] Debbie Levitt: Gosh, I’m so with you on that. I feel like we’re so bombarded with all of these fake AI, machine learning types of features, and it’s definitely the feature factory in effect. And I’ve seen this as well, I posted on LinkedIn recently about, the App I used to email on my Android phone, decided, oh, we’re gonna add, an AI capability, write a prompt, we’ll write your email for you. Now, I am not a big lover of the whole ChatGPT, write stuff for you right now. I feel like it’s not giving me what I want, so it doesn’t, it’s not a match for me, but I figured try it, be surprised.

So just for fun, for the prompt. And again, you’re gonna say, well, that’s not a good prompt. And I go, uh, UX, I should be able to put in whatever I’m thinking if it really is that smart. So I just wrote. Can’t wait to see you just to see what email it would write for me. And I assumed my, I dunno what your assumption would be, but my assumption was I was gonna get a short email, Hey, can’t wait to see you.

Looking forward to getting together, you know, something like that. It wrote four paragraphs and it made up a life for me that I’m not living. It sounds so much like your story. It was like, I’ve really been enjoying a lot of good movies and books lately, and I’m sure you have too, and I can’t wait to hear about them.

And I’m thinking, I haven’t read a book in years and I hate going to the movies. I just watched Ryan George’s pitch meetings on YouTube. and it invented this life for me that I don’t even have, and it was. Four paragraphs and as you pointed out, didn’t sound like me. And someone said,it’s the prompt that you put in.

And I said, I just wanted a very simple, can’t wait to see you email, but the one that’s really boggling my mind is an online event system that I use, who I won’t name, decided to throw AI into their online event system. But how are they doing it? Every time I log in, now I get a popup saying, we now have an AI event namer, do you need help? Naming your event, and I’m thinking out of all the event help you possibly could have given me, I already had a name for my event that’s done. I’m I’ve got that. What else do you have? Nope. We’re AI event naming and it’s a popup every time I log in. So yeah, I think we have to ask ourselves.

Are we building what users need? How do we know it’s what users need? It can’t just be cool. It can’t just be interesting. It can’t just be different. We can’t pretend we’re innovative. I think we have to ask ourselves, would the user have chosen this for themselves? And certainly in your story, I can’t imagine someone saying, I sure hope AI replaces everything I’ve just written with its own text.

[00:16:07] Bill Raymond: I know we’re just talking about some AI situations, but of course I think anyone that’s used a software product in their lives have watched the product kind of shift from the thing that was really useful and helpful to them, to something that is no longer useful and help helpful to them.

Or is too many buttons to click to get something done. Yeah. The bloat.How do we refocus that so that we’re making sure that we are. Meeting the demands of our customer.

[00:16:33] Debbie Levitt: Yeah. To me there’s two main parts of our larger project life cycle where we need to be connecting with customers. There’s the very, very beginning of the project, and this is the research teams love to skip because they think we don’t need that. We’re going to do build, test, learn. We’re just gonna take an idea, we have build it, we’ll put it out there and we’ll learn from that.

But usually that leads to small cycles of small changes and, or sometimes nothing at all. Cuz we say we’ll fix it later and then we don’t. But, the early research really sets the whole project up for success because what do we know? Very often our teams are working from guesses and assumptions. We assume a user would like AI to replace all of their information.

We assume users want to drink out of a one liter cup. Hey, this will be great. So we need that early research, and that’s best done with professional qualified researchers observing people, and the task, the way they do it now, which it should or could be outside of your ecosystem, it’s not about watching how they use your tool.

That’s later in what we call a evaluative research, but early we call it generative research. Some people call it discovery, but remember, it’s not to discover who likes your crappy idea and try to shoehorn that in. It’s really about discovering people behaviors, as we like to say on my YouTube channel.

People. Systems and context. These are the things that we want to know more about so that this can better guide our strategies, our decisions, our products and services. So that’s the first time where we should really be working with target audiences, some who might be customers and some who fit the model or the segment, but aren’t we always learn more from people who could be our customers but aren’t. And then there’s the evaluative testing, which is best still during that CX or UX process. Where now that we have a prototype, a concept, something like that, before engineers burn time on it, I want to test my prototype again with archetypal users.

Some might be current users. Always better to use non-users or customers who fit your target audience because the current users. They know the system. They’re savvy, they know the workarounds. They’re used to the terrible thing you’ve built. So best to get those fresh eyes. And that’s where we can see, some people think that, uh, UX testing or user testing or usability testing, whatever they’re calling it, they think it’s, is this good enough to build and ship.

But what we should really be looking for at that time is did we solve the original problem? And that’s again, where we tie it back to some sort of opportunity to make something better for our users. Did we solve that problem? And then when we watch them, it’s really more of an observational study when we watch them in the prototype or an early dev build before it’s released to the public.

Did we solve that problem? And is this easy, logical, intuitive? Does it make sense? If someone is saying stuff like, we’ll need to put more instruction text on here, or, hey, this is gonna need some tool tips and tutorials. We failed because a lot of people, the companies we admire most, you take it out of the box, you turn it on and you go, I get it.

It just works. And that’s what you expect from the companies you do business with. You don’t wanna read a manual, you don’t wanna take their training. You wanna say, I can figure this out. Nobody wants to feel non-intelligent. So these are key points where we have to interface with users, or archetypal users before this ever goes live.

Because if this idea crashes and burns while we’re still in that CX or UX phase, the cost to, to change this, is very little. It’s gonna cost us some time and some money, but not as much as if we really build this and put it out there and then find out we didn’t solve the right problem, we solved the problem poorly.

It’s not a real match to our users. Now the costs are off the charts and it’s where people start sweeping things under the rug and saying, we’ll fix it later, and it’s good enough. And they’ll just call customer support because we don’t build customer support costs into our budget. So we think we can just pass our problems down the line.

There’s so many things that we can hear ourselves saying at our jobs every day that should really be red flags and important moments for us to look at what agility is supposed to be. It’s supposed to be these empowered teams who can say, wait a minute, I don’t think we’re doing the right work right now. Let’s talk about this. I don’t wanna wait two weeks for a retro, let’s talk about this now.

[00:21:19] Bill Raymond: Now I hear everything that you’re saying. Let me share with you a counterpoint that I hear quite frequently, where, they say yes, CX, customer experience, user experience, UX is very important to us. And what they do is they bring the team together and they’re starting off the journey of building this new customer solution and they do all that work that you talked about, that sort of phase of work where you’re defining what you’re trying to do and meeting with the customer and things like that. And it works really well and we watch it happen. And when we have retrospectives and meet up as a team and say, what’s going well?

And it’s like this is the part that’s really helping us get excited about the product because the customer’s already excited. We just showed them, a screenshot and a PowerPoint of what this might look like, and they’re, and they can’t wait to get their hands on it. So you know that you’re getting, you’re going somewhere.

But then what happens is you start developing the product suddenly you start to see the customer experience and user experience, people seem to get pulled off of the team. Now the developers can take that code and start building, and now they have a backlog of work.

And we see the shift away from that sort of regular defining what the customer needs are. How do we make sure that we don’t shift away from that and lose that focus?

[00:22:41] Debbie Levitt: It’s a fantastic question and thank you for saying all of that great story too. And, and the way that I see it is it’s really this push pull that I’ve experienced where Agileists or agile coaches, or Scrum Masters or whoever might be involved will say, we really want these UX people embedded. We want them a hundred percent on our project.

We want them all the time. We want researchers, we want, designers, we want, writers, we want all the people available to us all the time. But then what happens is, whoever is in charge of the project from a budgetary perspective says, these people are just a line on the budget and we can’t wait until they are off this budget.

Okay, UX needs, three weeks, four weeks, two sprints, nine sprints, whatever it is. I’m just making up numbers right now. UX needs x. Okay, budget for that and done. And then what happens is, especially when a company uses what we sometimes call an internal agency model, the UX team says, hey, we don’t need you anymore we got stuff in the backlog. I heard this all the time when I worked at Macy’s as a senior UX architect. Hey, that’s fine. We got your designs and they’re in the backlog, and you can leave our project now never to be seen again. And that doesn’t make sense. It doesn’t make sense for what I think Agile is supposed to be.

It certainly doesn’t make sense for good teamwork and collaboration. And I think there’s so many more points where we can continue working with the developers. So UX would be working with developers, especially when there’s ambiguities or questions or, Hey, what happens if the person’s phone explodes while this, whatever.

There’s always going to be some question best if the designer can answer that and say, oh, in this case this should happen. When the designer’s not there, the engineers start making stuff up and playing designer, and sometimes they make great things and unfortunately, too often they make not great things.

It’s just not their expertise. And so I think we have to stop treating, our CX or UX practitioners as some line on the budget that we can’t wait to make smaller and smaller. And if Agile is serious about saying, we want these people embedded, we want them as part of the team, we want them, whatever.

I remember, gosh, I remember. Back at Macy’s was co-location. we wanna be smelling distance from you. I was like, I dunno about that. But,I love the remote work thing, so I don’t think we need the co-location. We can fight about that another time. But,

I would love to see five UX people completely dedicated to, let’s just call it an agile team. And that way you have enough people to be agile. But at many companies, you get one third of one person. You get no researchers, you get a designer 30% of the time or for four weeks, and then they’re gone. And then everyone’s mad at everybody else.

And so I think that we have to, look at UX or CX as a permanent member of that team or hopefully five permanent members of that team and not just as some passing consultant, because I also find what happens is people act like, ah, UX is easy. I can do it. I’ll call them if I need help, but I’m pretty good at this.

And unfortunately, usually people are not as good as UX as they think. It’s in kind of tip of the iceberg thing where people think UX is much easier than it is. They see us make wire frames or prototypes and they think I can do that too. And okay, tunes this, the cat can drive, but not very well. These are some of the concerns that I have, and I think it just comes down to budget. we have to budget for UX people to join the team and stay on the team, especially post-release monitoring. That’s where our research and interaction with customers have to come back. Analytics might not tell us everything.

Surveys might not tell us everything. We’ve gotta keep, observing customers and it’s best when the qualified researchers do that.

[00:26:25] Bill Raymond: I hear you. There’s actually a product that I used very frequently over the course of many years, and it had one of the greatest features that if you will, beat out all the other competing products in that market space. And that’s the one reason for why I used it, was because of this one feature.

And I got a very close relationship with the developers, and they kept talking about how difficult it was to maintain that feature, which I totally understand. And what they did was they started burying the feature in the product so you couldn’t find it easily. And then I. I heard rumors that they’re going to remove the feature completely.

And I said, why are you doing that? And they said, well, our customer telemetry data, or,for folks that may not know what that is, when you run the software, usually the software’s collecting every button you press and everything you do. And they look for things that you’re using and that you’re not using.

And what they did was they buried the feature,

[00:27:23] Debbie Levitt: And then said, no one’s using it!

[00:27:24] Bill Raymond: And then said, no one’s using it, exactly.

[00:27:26] Debbie Levitt: I’ve seen that. I’ve seen that as well from a company I won’t name. And it was like, oh, you’re just trying to kill this and you’re using the metrics as the reason to kill it. And, but it’s completely unfair and not customer centric. So I’m with you on that one.

[00:27:41] Bill Raymond: So this comes down to accountability, doesn’t it?

[00:27:43] Debbie Levitt: Holy cats, how much time do we have to talk about accountability? Oh, I’m just on fire about accountability right now. yeah, I think that accountability is ultimately the root of. cause of a lot of our problems because I’ve been on so many teams over the years and I keep hearing, this person’s gonna be accountable, this person’s gonna be responsible.

Usually, usually it was a product manager, not necessarily. And then when there was carnage and disaster and everything went wrong and blah, blah, blah, nothing seemed to happen. I was like, then what is accountability? What is being responsible? What does it mean if we have a project that fails in a small or large way, who’s accountable and what does that look like?

And it’s even reflected in some of the news we’ve seen over the past year. All of these executives coming out and saying, oh, we’ve had to lay these people off and I hold myself responsible. Slow, sarcastic clap. what does that mean? did you take less pay this year? Most of them did not.

What does that mean? And I don’t want people to think that, I believe that accountability means you do something not great and we fire your butt immediately. There’s a lot of things that can happen between A and B, and so I, I think that accountability means responsibility and it means there are consequences.

There are rewards and there are consequences. I haven’t seen any consequences at any of the places where I’ve worked or consulted. And at times I’ve seen the person who created the most problems lauded and promoted and it was like, what do you, what is the message here? What’s your company values again?

Cause I’m not sure you’re living them. So I think that, accountability would fix a lot of stuff. I think it would give engineers more time. I think it would give engineers more human power because in instead of trying to drive these people to work themselves to death and just be faster and faster, robots, someone might actually care about their mental health.

Someone might care about their work life balance. Someone might care about all of this and say, wow, we need to add another person to that team, or whatever the case may be. If there were more accountability around CX and UX, maybe other people would stop trying to do my job and doing it so incredibly poorly. Because then they might be held accountable later.

Hey, the product manager came up with this idea and made their own wire frames and wow, this super tanked. Slow, sarcastic clap. Okay. Thank you. Can you please not do my job again? Can someone please bar you from trying to be a UX designer? This ain’t your thing. So I think that there are things that can be done with oversight and governance and budgeting.

We could put some of these people on a performance improvement plan, which some people think is harsh and terrible, but usually they love to put others on a performance improvement plan. So what’s good for the goose, perhaps. But I think that if we had more of this accountability both at the individual level and at the team level, then things have to get better for all of us. I’m not sure things are great for any of us a at many of the jobs that, that we’re at. You’ll see more of this than I will, I’m sure, but I just am not seeing that accountability and sure it’s okay to make mistakes. It’s okay to fail fast though it’s best when it’s still behind the scenes and a UX prototype and not something we release to the public that we have to undo. But where is that accountability? Because I would love to be held accountable at a job. I would love for someone to say, Hey, Deb, that that design needed didn’t work out, and I would say, awesome.

Let’s talk about how I was given two days. When I asked for two weeks, or let’s talk about how I needed to test it a second round. And I was told, we don’t need to test these things. We’re just gonna put ‘em out to the public and see how they do. I would love to be held accountable. I would love for someone to say to me. Your design didn’t do as well as we’d hoped.

Why is that? And I could go, here’s all of the decisions other people made that blocked me from doing better work. Agile Manifesto principle number five, give motivated individuals the time and then resources they need to do their work and trust them to do their jobs. I would love to have that. I would love to have those conversations.

I would love to talk about it in retro and then see someone act on it. Wow, the UX was really bad when we gave those people two days. Maybe we need to talk to them about how much time they need to do better work, et cetera.

[00:32:12] Bill Raymond: It sounds like you’re passionate about that.

[00:32:14] Debbie Levitt: For sure. Fire!

[00:32:15] Bill Raymond: we’re getting very close to the end of the podcast. You shared a lot of very useful information here and I am curious, I. sometimes I think when we, look at all these things that you’re proposing here, which seem very reasonable and natural to me, I did of course hear some words that might scare, if you will, teams that are always shipping and moving fast.

Such as saying you might need two weeks instead of two days, and things like that. So if I’m a leader and I wanna bring some of these ideas and concepts into the organization, but I’m also worried about things getting slowed down by bringing this, uh, UX and CX ideas and concepts into the team.

What are some things that I can do to make sure that, we’ve reached some sort of a good balance?

[00:33:04] Debbie Levitt: Yeah. For starters, the, that team leader or project manager or program manager in the very earliest stages has to be talking with CX and UX. workers or leaders there, because I find that a lot of times projects are being planned and I know nothing about them. Nobody has talked to anybody in UX. No one has said, Hey, UX, how much time do you need to do great work?

Good work, mediocre work? The fastest crap you can spit out. These are conversations that we could have and we often don’t. What typically ends up happening, especially with our UX architects or designers, is someone says, Hey, we’ve planned out all these projects or the whole release and hey UX, you’re gonna get two days and get me those final wire frames or prototypes, and I’m going.

Wait, I just heard about this. Why didn’t anyone come and talk to me? So I think again, if we, especially if we want to have that team spirit and especially where we want our UX peeps to feel like they are part of the team, maybe even embedded or dedicated, they have to be part of that early planning as well.

And I think ultimately, while sometimes days or week or two weeks is very scary to people. And they go, what? Two weeks? And I go, that’s funny you’ve got what, 6, 8, 10 engineers who want to work on something for two sprints, three sprints, four sprints, some that’s agile. Somehow six to 10 people working on stuff for weeks is agile.

But when UX wants a few more days, or God forbid, a couple of weeks, holy cats, people just explode and they go, that’s not agile. And I say, look, it absolutely can be. We just have to make sure we’ve planned for it. We, you can have that engineering team working on project. A, and your UX researchers are now researching for Project B, and then your UX designers are working on Project B while the devs are still building Project A and building it and testing it and merging it and deploying it.

They’ve got plenty to do. Don’t do. I love when people tell me, what are our engineers gonna do while UX takes all this time? First of all, you have other projects you’ve gotta do and we can start our stuff early. Second of all, I’ve never met an engineering team that had nothing to do. There’s always something in the backlog or the ice box or, The to-do list or the stakeholder ego trip, there’s always something we could do.

How’s our performance? Do we need to refactor something? So I don’t want to hear what will our engineers do you have things to do? I just know it and again, this is just all about good planning while the engineers are still working on project A, we are already researching, designing, testing, improving, iterating on B and then if we’ve planned this, well, UX will be ready when engineering is done with a, Hey, guess what? We’re ready. But of course there’s collaboration along the way. I don’t believe in just, Hey, here’s our design. Nice to meet you. There should be, there will be collaboration in all directions along the way, but I think that’s the main message I would give people is stop being afraid of words like days and weeks.

These are not scary words, and somehow engineers can get that time. We should as well, and it just has to be planned for.

I really appreciate this conversation today. Debbie Levitt, if anyone wants to reach out to you, how might they be able to do that?

Yeah, thanks for asking. Um, they can certainly find me at customercentricity.com, which is my new website still um, putting that together in some ways and, uh, that’s got more information on, on what we do and how to find me. You can fill out the contact form. It goes straight to me. People who love LinkedIn are welcome to find me on LinkedIn

If you do send a connection request, please tell me you heard me on this podcast cuz I don’t accept a lot of connection requests. Let me know, you heard me here so that I can click that accept button. I know you don’t give out email addresses here, but really anyway that people are comfortable getting in touch with me I’m always happy to answer further questions. cuz I know there’s a lot of mystery around how CX and UX and Agile can all be buddies.

Yeah, there certainly is, and that’s why we’re doing this whole series to uncover what CX and UX means and customer centric delivery, and I really appreciate the time that you spent. Thank you, and I forgot to mention my YouTube channel. deltacx. Sorry.

[00:37:20] Bill Raymond: Oh yeah, that’s perfectly fine. Debbie Levitt, before we go, I will make sure that all the links that you provided, your LinkedIn, your YouTube, and customercentricity.com will be on the agileinaction.com website. And of course it will be on any app that you might be using to listen to this podcast right now.

[00:37:39] Debbie Levitt: Wonderful. Thank you so much.

[00:37:41] Outro

[00:37:41] Bill Raymond: Thank you for listening to the Agile in Action Podcast with Bill Raymond. Subscribe now to stay current on the latest trends in team, organization, and agile techniques. Please take a moment to rate and comment to help us grow our community. This podcast is produced in affiliation with Cambermast LLC, and our executive producer is Reama Dagasan.

[00:38:02] Speaker: If there is a topic you would like Bill to cover, contact him directly at bill.Raymond@agileinaction.com.