Everyone's onboard. So why isn't change happening?

Thanks, everyone. I'm just going to set a quick scene for why we put together UXDX and what we're hoping to achieve over the next few days. At UXDX, where it all started from was really working in software. My background—I’ve had 20 years working in software development, and I had worked for big enterprises and then thought, "I can do this!" So I went into startups and realized that the waterfall way of working doesn’t quite work very well if you’re just thinking you know what the customer wants.
After that, I went back to enterprise and realized they’re still ignoring all the research. They’re still ignoring all the upfront design and iteration, and we’re seeing that in the outcomes. Back in 2009, it was at 33%, and it’s actually creeping lower and lower whenever they test. And so, Ron Kave, pictured here—he is the ultimate guru in the world for A/B testing—and he’s just seeing it sliding in terms of effectiveness. That’s a bit because things are getting harder. We’re not just replacing old, kind of paper processes. It’s a bit more difficult because we’re always having to create something new. That’s where it’s difficult because customers—you can’t just ask them or expect that if I write upfront, this is how they’ll behave.
But I really feel that our processes are the problem. It’s nothing to do with the people. It’s not because we’ve got really bad people, and that’s why our effectiveness rate is so low. I really believe it’s how we’re working—or not working—together that’s the problem. That’s why we created UXDX: to get multiple disciplines together to figure out how to work better.
The typical scenario would be the business and IT divide. The business comes up with the idea, management signs it off, and then IT is all just focused on "Are we on time? Are we on budget?" The challenge there is that you end up—you’re not agile. You’re doing waterfall the whole way through until you get to development, and you do a few sprints. Then you’re "super agile." But because it’s all about time and cost, any kind of changes or anything you learn from customers—that’s scope creep, and that’s going to cause problems. So, let’s just ignore that and keep going with our original plan because we have to be on time, and we have to be on budget.
Instead of looking at development as where we need to get agile, we need to look at the end-to-end. We need to be thinking about where ideas are coming from, right through until we have satisfied customers. We need to make this short and iterative so that it can move quickly—you can go from idea to validated solution as quickly as possible.
This is why we have product, UX, design, and dev at this conference—because this process involves everybody. You do that upfront research to try to figure out what you actually need. You do design to iterate on different prototypes and validate different ideas—or evaluate and kick out the ones that don’t work. You can see here that there are overlapping phases because it’s not quite clear. There’s a little bit of boundary, and that’s why we wanted a cross-functional conference for people to work together.
We have product, UX, design, and dev. And now I’m going to jump into my talk. That was just to give you a little bit of a background about why we’re hosting the conference and what we’re trying to achieve. So, my goal is to actually make change happen. A lot of conferences—you’re going to leave here and hear some amazing talks over the next few days, and you’re going to be super pumped. You’re going to be inspired, and you’re going to go back to your office and say, "There’s this brilliant new methodology that I just learned about! It’s doing wonders in JP Morgan Chase and all these kinds of things. Let’s implement it!" And you’re going to just get a little bit of pushback, and a week or two later your motivation will be down. Then, you’ve got your deadlines, so you focus on that.
So, my goal is to try to figure out—and this is our whole thing at UXDX—how can we get to that next step? How do we get to the point where we’re actually implementing all these changes? My talk is called "Everyone’s on Board, So Why Isn’t Change Happening?" Because I’m sure when you go back and say how amazing it is, you’re going to hear people go, "Yeah, that sounds great! Let’s do it." But it still doesn’t happen.
As I said, we have this problem. We have very low effectiveness rates. So, I’m going to do an example now as I go through this. I’m just going to imagine that you’re pitching to your boss. So, you’ve just come back, and you’re like, "We need to do discovery as part of our development process because it’s going to give us better products, better ROI. It’s going to be less rework because when we deliver it to customers, it’s going to be what they actually want instead of us having to go back and do V2, V3. It’s going to be better team buy-in because it’s going to be more empowering for the team." So, everybody’s going to get pumped. This sounds amazing. Who thinks it’s a good idea? Show hands. Most people. I think so. Everybody back in your office is going to think it’s a great idea as well.
How many people have tried this already? Okay, a good few hands. How many have actually implemented it? A lot fewer hands. Great. When should we start? "We just need to get this project finished right now. We’re halfway through; let’s just finish this one, and then we’ll look at that." Or, "Let’s put a business case together because it’s going to cost a little bit of money. Let’s put a business case together, and we’ll pitch it. But I’m really on board. I think it’s a brilliant idea, and I’ll help you put the business case together. But right now isn’t good because, you know, the economy and the market are a little bit down. So, let’s just keep our heads down because we don’t want to rock the boat too much, and we’ll park it for now. But we will come back to it, I promise."
Any responses like that when you’ve tried to pitch an idea?
Yeah. But the thing is, they don’t get it. It’s not your fault. It’s okay. They don’t get it. They don’t understand. We need to convince them of the value. So, you’ll hear lots of, "How do I convince somebody of the value of UX? The value of design? The value of DevOps? The value of discovery? The value of..." There’s so much stuff out there about how to convince people of the value because it’s not us, it’s them. They don’t understand the value, and that’s why we’re not getting it across.
So back in 2003, I just kind of looked at things like, "Let’s see what’s the return on investment for usability?" So, we were pitching it in 2003, in 2006, in 2014, in 2015, and every year. That’s been going on for 20-plus years. Have we convinced people of the value yet? No, because it’s not the right way to go. What’s the definition of insanity? Trying the same thing over and over and thinking that we’ll end up with a different outcome.
So, no. We don’t need to convince them. We need to get somebody in there. We need a seat at the table because they’re never going to understand. So, what we need to do—because they don’t come from our background—is, if we get a seat at the table, it’ll be sorted. We just need somebody with the right background. In 2014, we were saying this: "We need somebody at the seat at the table." In 2018: "Designers finally have a seat at the table." Then: "Designers, stop asking for a seat at the table." And now: "Design lost its seat at the table."
So, what happened here? Everyone’s pitching about the value of the process, but we need to be thinking about the value of the business. It’s not that people don’t get it; it’s that their incentives are not aligned. So, why is this happening? Now, what I want to do for the second half of this is to try to figure out—like, put yourself on the other side of the table now and imagine somebody’s coming to you asking for this.
The challenge we have to figure out is: does your boss really care? We all know from research, don’t ask somebody, "Do you like my new product? I just built this. I have a lot emotionally invested in this; please don’t hurt my feelings." So, if you ask somebody in research what they think of something, of course, they’re going to say, "Brilliant! It’s amazing. Your baby’s beautiful." But do they really care?
What are the KPIs that your manager is being tracked on? I’ve spoken to so many different companies. Even all the super agile ones—they’re still, or claim to be, super agile. Did I deliver on time and on budget? Am I predictable? If I tell you we’re going to deliver, we’re going to deliver. That is, by far, the most common. And then there’s the utilization of resources. How much percentage of time are people billing to kind of CapEx projects versus OpEx admin work?
So, you’re coming along, and you’re saying, "I want to talk to customers during these phases." All the way from new idea to getting down into the detailed analysis and design. You’re saying, "But rather than having this big plan up here in our business case, rather than sticking with that, I want to keep talking to customers the whole way through because I want to really understand: Is this what we’re trying to achieve? Is this what you need? Is this solving your problem? Actually, I want to keep doing it. I don’t want to just do it upfront; I need to be doing it the whole way through because things change. We learn new information." And there’s a name for that, and it’s called scope creep.
So, your manager is hearing that, going, "I’m being tasked with predictability, and you want to keep changing things over and over and over again. I’ll never get anything delivered." So, immediately this comes up with the old adage: "Culture eats strategy for breakfast." You’ve probably already heard that. The strategy sounds great: "Let’s build these amazing products our customers love." Who’s not going to be on board for that? But the culture is "on time, on budget, predictable," and that’s going to win out every single time because KPIs drive your culture. It’s why I’m wearing it as my t-shirt.
So, the point here is, if your KPIs are "on time and on budget," no matter what you try to do—anything around continuous discovery, talking to customers—that’s scope creep. And that’s going to make it hard to be on time, on budget, and predictable. It’s difficult to get a man to understand something when his salary depends on not understanding it. It’s just a brilliant quote, but that’s kind of the gist of it. People aren’t bad; they’re not actively against it. But they’re trying to reconcile this: "Okay, that’s a great idea, but it’s going to cause me a lot of pain and a lot of political problems, and I’m going to have to try to solve this."
So, what we need to do is start with KPIs, and that’s been my lesson. I’ve gone the wrong way of trying to do the motivation—sell the value, do all of that—and you’re just hitting your head against a brick wall. Many companies think of software as an assembly line because that’s how the most successful companies were structured in the 20th century. That’s where our divisions came from—marketing, sales, operations. It came from the concept of an assembly line. Somebody does something, hands it to the next person, hands it to the next person. So, you have a bit of design when you’re coming up with the new ideas about what we’ll do. Then you’ve got the assembly line of once that’s done, it goes step by step. We approve it, we create our business case, we do our big design, we sign it off, we do our developments, and release it in a kind of one-way flow. You don’t want work going back.
But it only makes sense if we’re building something repeatedly. Assembly lines are amazing in manufacturing where you’re just churning out the same product time after time after time. But in software, we have copy and paste. So, we’re never building the same thing twice. We’re always trying to figure out something. So, our design phase is right up until the customer tells us they actually want it. Then we can do some DevOps stuff like an automated CI/CD pipeline to get that code into customers' hands. That’s our assembly line. But all of the steps up to that point? Actually, that’s design. And design is messy. Design is squiggly lines. Design is all of that—dead ends and trying things and restarting.
So, imagine that we get to the point where we’ve got KPIs, and everybody’s rowing in the same direction. We want outcomes over outputs. I’ve talked to a lot of companies again where they say, "Oh yeah, we are outcomes over outputs. We’re definitely there." But then when you kind of look at it and dig a little bit deeper, it’s still, "Oh well, obviously we have to be predictable. We can’t lose face." If somebody says something and they’re the ones paying for it, we need to deliver because we’re always just getting attacked for how slow and expensive we are.
But let’s say we’re there. Let’s go again. Let’s pitch it again: "We want to do discovery. It’s going to be great for our products, great for our customers, great for everybody, great for the team." What are we really asking? We’re asking for an upfront process that we do. But what are we really asking? Let’s just do a little back and forth.
"We want to do an upfront research phase before a project starts to make sure that we’re building the right thing."
"Well, actually, the business does that before their business case. They do research beforehand. So, are we not just doubling up on the research they’re doing?"
"Well, actually, our phase is a little bit different because we do generative research to understand the pain points, and then we do evaluative research to validate those needs. And yeah, we’re going a lot deeper into it than maybe the high level that the business would be doing."
"But that sounds awfully time-consuming. If you’re going into that deep level of research, how much time is this going to take? And what happens if we get halfway through and we just keep hitting dead ends and find out it’s not working? What happens to all that spend?"
"We can do it fairly quickly."
It’s a little bit vague here around how quickly you can do this research. "No, it’s great if customers don’t like it. That’s great. It’s a winning thing." But yeah, it just comes back to: "Okay, how much is this going to cost me, and what’s the ROI?" That’s kind of where the boss is thinking. They’re thinking, "Okay, I’m going to need to pitch this. It’s going to cost money. What’s the ROI? How am I going to sell this to my peers and my managers?"
What your boss just heard during that conversation is: "I’m not a big fan of this upfront approval of kind of signing off the scope because that locks us in too much. So, I don’t really like that business case signing off—it’s making it even stricter because that’s getting into a lower level of detail. I really don’t like that one. And we’re going to keep adding scope here as we build, so just forget about time and cost, and we’ll be efficient. We promise—Scout’s honor. We’ll do our best to be as efficient as possible."
This is a really difficult position for your manager to be in, who’s just heard this. What they’re thinking is, "I need to go talk to the department leads in different areas and say, 'Okay, we’re going to do this new thing. You can’t just give us a full package solution anymore.' Then I need to sell it to them. Then I need to go to the senior exec about the whole funding model and the business case. I need to sell it to them. Then I need to go to the PMO or head of delivery, because their whole structure is around time and cost management and project reporting. So I need to sell it to them. I need to convince architecture and engineering that instead of doing these big upfront architecture layouts and designs, we need it to be a lot more iterative. I need to sell it to them."
That’s a lot of political capital you’re asking somebody to go around the business and try to sell this idea to every single one of them. I’ve tried this. You cannot do that. I have literally gone around offices trying to convince people, and there’s always a few people who just flat-out disagree. They don’t believe that approach is the right way; they think the current way of working is the best way.
Leaving aside the politics, what we’re asking is, "What is the process?" "Okay, we want to do upfront discovery. But now we have to change it." Because if you’re going to be doing these continuous changes, we need developers to be on board. We need designers to be on board. We need to be working together, not handoffs. How do we structure the teams? Because we don’t want two teams working on the same thing. But if they’re all iterating in their own areas, how do we make sure they don’t accidentally creep into each other’s areas? How do we align on strategy? Because if the teams are iterating and they’re a bit more empowered to figure it out, well, we have our business and product strategy. How do we make sure they don’t just start going off in weird tangents?
How much should we fund each team? Projects are easy. We put together a project; we say it’s going to cost this much, we’re going to get this ROI, so I know how many people I can put on that team. But it gets a little bit more awkward when we’re saying, "Well, we don’t quite know what we’re going to build, but we’re going to do the best we can." How do we govern them? Time and cost is a great way of governance because it’s, "Are we on time? Are we on cost?" But what do we do now? What’s our new governance model? How do we scale this across the business? Because, yeah, we might have a test team where we just loosen the rules a little bit to get them up and running. But what do we do when we need to scale this across all the teams?
Because of all those problems I mentioned, what your boss just heard was: "You’re giving me a lot more work to do, and I’m already super busy." So, even though we think we’ve gone with the best pitch ever—"We’re going to build better products, we’re going to improve ROI, we’re going to make customers happy, we’re going to make the teams happier"—this is a slam dunk. This is amazing. But what the boss is hearing and trying to figure out what they need to do to get this embedded? It’s really, really hard.
There’s a great model from a professor at Stanford, BJ Fogg, and he’s come up with this model for how to get behavioral changes adopted. You have one axis, which is motivation. If you’re super motivated, you don’t need to make something easy to do—which is the second axis. If you’re super motivated—and this is typically what happens when a company is about to go under—they literally have no other option. This is: "Everybody jump on this, let’s give it a shot, and hopefully it’ll work." But it’s very, very rare. If a company isn’t literally about to go under, it’s very rare to get that high motivation.
So, while we think we’re high motivation and we’ve talked about the process that we want to do, in reality, we’re down at the bottom left because your manager doesn’t have the right KPIs. So, they’re not actually super motivated to do this because it will conflict with their KPIs. And it’s really hard for them to do it because they have to convince everybody across the business.
Lesson one: Start with the KPIs.
Lesson two: Make it easy.
Now, this isn’t easy. It’s not an easy problem. If it was, we’d all be doing it. This is where I go a little bit against the orthodoxy in agile circles of "people and interaction over process." We don’t ask people to reinvent programming languages from first principles. We have layers of abstraction to make it easier. So, we have machine language, where people are doing ones and zeros. We have assembly language, which is barely any more complex than that. And all the way up to high-level languages, because it makes it easier to do things. Yes, you’re constrained. You can do a lot more the lower you go down, but you can move a hell of a lot faster the higher you go up. So, you’re trading constraints for speed.
This is where I’m actually a big fan of frameworks because frameworks are the exact same thing. We don’t want people to have to figure out all of those processes, structures, alignments, funding, governance—all of those things themselves. They don’t have time. They don’t have capacity to do that. So, I think frameworks are actually a great way to help people get started. But the problem is, our frameworks have gaps.
We have product development frameworks, but they don’t talk about the upfront ideation. They don’t talk about where the ideas come from. We have Scrum, waterfall, Kanban, and they kind of start with the developers because they were created by developers. So, that’s kind of the start of "we have our scope; what’s the best way of actually building that out?" We also have problem-solving frameworks, so we have things like design thinking, lean UX, double diamond—all those. And they’re solving that ideation problem upfront, coming up with, "Where do we come up with ideas? How do we evaluate those ideas?"
And we have scaling frameworks. So, we have things like SAFe, LeSS Huge, and Nexus, and all these kinds of scaling frameworks. But they’re kind of a little bit separate from the other three. We have these three different things that we need to get together, and essentially, we’re giving people Lego blocks and saying, "You try to figure out how." So, we have double diamond, and we have Scrum, and we have SAFe, and yeah, there you go—that should be enough to scale this across your organization.
But if you look online, it’s like, "How do you integrate UX and agile?" And there are basically hundreds of thousands of people giving their ideas because it’s not straightforward. Nobody has figured it out perfectly. Everybody’s still focused on their silo, going, "Okay, well, this is how we solve the ideation problem." But they’re not doing the cross-functional sharing of, "How do we actually get the idea into dev? And how do devs get into the ideation?" And kind of that mixture.
Maybe scaling frameworks will be easier. But like SAFe—I don’t know if anybody has tried SAFe—I think it should be more like "waterfall described" rather than agile. It’s kind of institutionalizing waterfall but with agile words. But yeah, so there’s a mountain of people just complaining about how strict and how—it’s basically just locking in waterfall. Which is a great way—if you’re selling a framework, call it agile, don’t change any processes, and it’s easy to adopt. But it doesn’t make it easy because we’re still giving people these Lego blocks.
As you can see, people are having difficulty trying to figure out how to put them together. I don’t know if you’re working in companies where they’re trying, and you’ll definitely be feeling the pain of trying to do that—merging them together. To solve this problem, we need to look end-to-end—from coming up with the idea until we have satisfied customers. And it needs to solve these six areas: process, how do teams actually work on the ground? How do we structure those teams? How do we get alignment with our business, product, and company strategy? How do we do governance? How do we fund these teams? And how do we scale?
This is not easy. But at UXDX, we’ve been blessed because over the last nine years, we have been doing case studies on this stage, and in New York, and in all of our community events around the world. So, I’ve pulled together about 700 different case studies and pulled out the insights from all those different companies. I didn’t want to come up with something theoretical that hasn’t been proven in the real world.
So, if you go to zeroblockers.com, you can scroll through all of these hundreds of case studies. They’re grouped into different areas of solving these problems. What we had the beauty of doing is, because there’s so much duplication in different areas, we were able to see the patterns that worked. And that’s what we’ve done. We’ve pulled out all of those patterns so people can learn from the best practices because our idea is that we need to just make it easy for people to adopt this.
So, we’re going super opinionated, which is the opposite of the kind of agile mantra of "ignore process." But I don’t think process is the problem—bad process is the problem. Process is just basically tracking what people are doing, and that could be a lot of cross-functional interaction, or it could be complete silos. The process in itself isn’t the problem, but a process that stops people from talking or tries to act as an assembly line in a design problem—that’s a problem.
So, Zero Blockers is what we’ve published from our UXDX research. It covers the end-to-end process, and the reason it’s called Zero Blockers is because we need zero blocking dependencies from idea to satisfied customers. What do I mean by a blocking dependency? One team should own this, and they should not need to talk to anybody else in the organization to go from idea until they’re releasing that software to customers. Because every time you have a handoff to somebody else in the organization—for approvals, for "we’ve built it, now we need to hand it over to the operations team to release it," or for any kind of internal handover—once you have dependencies, you have a lack of accountability. It’s not my fault; I did my job. I built it. I did exactly what I was asked to do, but it got delayed because of those guys.
So, you have to have one team owning end-to-end. We have a process that describes how the team is building the product. At the product level, they’re doing the research, design, and development iteratively together. What I mean by that is—I don’t know if you’ve heard of pair programming before—it’s the concept of two people sitting at one computer. The idea behind it is that it’s not the typing speed of developers that shows their productivity; it’s how quickly they can think through and solve conceptual problems. So, two people having a chat will actually produce fewer bugs and have higher-quality code. That kind of thing.
And then one team said, "What do we do when we have a crisis? We get everybody in the same room together and basically pair program, but as a whole team. So, why don’t we try that on our software team?" And Woody Zuill tested out this idea. He calls it mob programming, or "teaming." They found that, yes, they were slower than individuals working separately, but they were much faster because they had so much less rework. They didn’t have a bug in production for two years because with that many eyes and that quick of a turnaround—if your designer is in the same room as your developers and your researchers—they can say, "What did you mean by this?" and get instant answers to what they need. They were able to solve things at a higher quality than otherwise.
How do we structure it? We call these stream teams, where you’ve got your researchers, your designers, your developers. We call them streams because there’s a concept of value stream modeling that was popularized by Toyota. Essentially, you look at the customer journey for your product and find your logical boundaries. It’s never perfect, but you can kind of figure out where to start slicing your products. Then you give teams ownership of that little sliver, but it’s a vertical slice of the product.
So, they own the catalog. That could be a team responsible for sourcing new products and getting them online. You could have a search team responsible for filters, data, and search functionality. But we need another team above them to get that alignment. You have the structure of slicing up these stream teams, but we also need some layer of managerial oversight to ensure alignment with the strategy. Now, this is where it can get a little difficult. It’s not about telling the teams what to do but setting the strategy, the areas to play in, and the guardrails. You’re setting the guardrails, but you’re not dictating what the teams should do.
The next thing on alignment is that you need to have four elements to ensure teams can make high-quality decisions. The biggest fear for managers is that we give these teams control, and then they do stupid things—things that could harm the brand. For example, middle seats on an airline. I worked in two airlines with very different segments: Ryanair and Aer Lingus. Ryanair decided people hate the middle seat, so they’ll put everyone there and charge them to get out of it. Aer Lingus, being a value carrier, said, "We’ll offer a product where you can buy an empty middle seat for a bit more armroom." If you swapped those ideas between the companies, it would hurt the brand in both cases.
To avoid this, you need shared values and principles. You need strategic context—what is our product vision? Where are we going? What’s our three-year strategy? You need aligned incentives—KPIs should be team-based, not individual, especially in cross-functional teams. And you need experience because a team of seniors will have a very different outcome than a team of juniors.
For funding, once we slice into value streams, not every value stream is equal. So, we’re not funding teams; we’re funding those value streams. We might fund one value stream a little less because it’s not strategically important right now and put more funding into another. Then, we determine how many value streams each team can support. I actually think the perfect team size is two—anything more introduces challenges—but most teams go up to eight.
On governance, there are four ways to track performance: hours worked, features delivered, user behavior, and business impact. Business cares about cost and revenue, but it’s too slow for reactive governance. So, we govern on how users interact with features—did they achieve the intended outcomes?
Finally, on scaling. I’ve introduced stream teams, but we also need internal products. These include things like design systems, technical platforms, and enabling teams. Enabling teams consist of senior experts who coach stream teams, train them, and help them improve rather than doing the work themselves.
So, our goal is to make change easier. It’s not about improving motivation—it’s about reducing friction. The framework we’ve developed, Zero Blockers, tackles these problems to make change easier—not super easy, but easy enough to actually happen.
To summarize:

1. KPIs win every time. When time and cost are your KPIs, you’ll never succeed.
2. Make it easy. We’re asking people to change a lot, so we need to reduce the effort required.
3. Process isn’t the problem—bad process is. If we define and implement good processes, we’ll see better outcomes.
   Thank you very much.