Join Murray Robinson and Shane Gibson in a conversation with Jeff Gothelf about Lean UX and Sense and Respond. Lean UX explains how to do UX design and product development in a highly agile way. The core of Lean UX is the canvas, a facilitation tool for collaboratively collecting and testing product hypotheses. The key output is a prioritised backlog of discovery experiments. Sense and respond is a management book that explains how to organise and support agile product teams and encourage agile product and UX design thinking. It explains how to continuously research, design and development to maximise learning and value. Dual Track means that one team with one backlog does research, design and delivery work simultaneously with the same team in the same iteration. A lot of discovery stories should result in no further development. Higher-level planning should be done with outcome-focused product roadmaps, not lists of features. Outcomes, not outputs. Collaboration, not authority. Continuous discovery, not upfront design. Cross-functional product teams, not specialised research and design functions.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson.

Jeff: And I’m Jeff Gothelf

Murray: hi Jeff. Thanks for coming on. We wanted to talk to you about lean UX and sense and respond today. Why don’t you kick us off by telling us a little bit about your background and experience and how you got to this point. 

Jeff: Absolutely. I actually started off as a broke musician. That’s where my career started. I tried to be a rockstar for a few years in university that didn’t work out sadly, as these things tend to happen. That was falling apart in the late nineties. And so I wanted to have a social life and to go on dates. I didn’t have any money and the web was coming around and I was a little bit of a computer geek as a kid growing up.

And so I, got one of those html in 21 Days books, and I taught myself HTML and I started making websites for my band and for other bands and for other folks. And as the band stuff was dying down, the.com web 1.0 stuff was coming up. And so back then in 1999, if you could spell html, you could get a job. And so I got a job as a web designer. And from there was a fairly quick transition to information architecture, which was a pretty new profession back then.

No one really knew what it was, but there was a book. And so we read the book and I was like, Yes, this is what I wanna do. Organize the information, make it easy to access. And as the web became more interactive, there was a seamless transition into interaction design and UX design. And about 10 years into my career, I was leading a design team in New York that was trying to do good design work in a high growth startup that was transitioning to agile software development. And so I had the challenge of both building a design team and making it successful working in this new, for us, agile way of working. And it was hard and there weren’t a lot of good answers about how to do this. There was a lot of stories of failure and depression and sadness and tears, but not a whole lot of success stories. And so we set out to learn from those anti patterns, tried a bunch of things, blogged about what was working and what wasn’t working. Eventually we figured out a solution that worked for us and I was writing about it with the help of Josh Sein and a bunch of other folks who were trying to do the same thing around the same time, ended up becoming Lean ux, the subject of my first book, which I co-wrote with Josh Sidon.

And that book launched 10 years ago. And that fundamentally changed my career. I began doing less design work and more teaching and more coaching and consulting work. We launched a consulting company and built that for four years. And since then I’ve written a couple of other books since in Respond Lean versus Agile versus Design Thinking, and then a brief foray into career development called Forever Employable.

And all throughout that time I’ve been working with organizations, helping them become more customer-centric, more agile focused on building cross-functional collaborative teams and just generally building better products and services for their customers. So that’s what I’ve been doing for the 10 or 12 years or so. 

Murray: Yeah. So what is the difference between the two books, Lane UX and Sense and Respond. 

Jeff: So lean ux is now in its third edition. When it first came out 10 years ago, lean UX was a very practical, very tactical book for designers, by designers. Here’s how we have discovered to do good design work in an increasingly agile world. In the two editions since the first edition. The scope of the book has expanded. It’s not just really tactical design. It’s had to be a successful cross-functional collaborative team. And then ultimately, I think in its most recent iteration, it’s really about how do we build great customer-centric products in a world defined by agile and empowered by agile mindsets and ways of working.

Over a decade, we have received a lot of feedback and the top theme coming out of that feedback has consistently been for 10 years. These are great ideas. I really love what you wrote in this book. My boss won’t let me work this way. My company doesn’t work this way. This is not how we’re structured. And so for Josh and I, that became a very clear signal from the market which said, people want to do this, they get it, but their companies, their bosses don’t understand it yet.

And so we responded to that feedback with a business book. So Sense and Respond is a business book. It’s published by Harvard Business Review Publishing. That was by design and by choice. And it’s targeted at leaders and aspiring leaders. Lean UX is the tactical, team level guide for building great customer-centric collaborative products. Sense and respond is the leadership manual that says, here is how you have to lead your organizations to support this way of working and why you should do that. 

So fundamentally sense and respond breaks down into two thesis. The first half of the book is you’re in the software business, no matter what you build or what you do, the way that you scale and grow today is through technology and software. And then the second half of the book says, Okay, if you agree that you’re in the software business, then managing a software-based business is different, and here’s how you should think about it and how you should manage and lead. And so sense and respond, it’s a higher level book. It’s designed for leaders and aspiring leaders, but it’s a direct response to the feedback we were getting from Lean ux, which is, No one will let me work this way. 

Murray: Yeah. So we talk to quite a lot of product people, technical people and ux design people on this podcast. And I feel like the message of sense and respond has become, the way you should do it. But everybody’s still having a big problem in getting their organizations to do it.

Jeff: Agreed. 

Shane: For people who haven’t read it, which way should they read it? lean UX first, then sense and respond or sense and respond then lean ux? 

Jeff: I think it depends on where you sit in the organization. If you’re in a leadership position or you’re aspiring to lead product development teams or product development organization, sense and respond makes a good starting point because it lays down the foundation.

To be fair, we worked very hard to use the word agile in there as little as possible simply because we were trying to make that book as evergreen as possible. Agile is mentioned in there, of course, but it’s really designed to be as evergreen an approach as possible.

So if you’re in leadership or inspiring leader that’s the way to go. Lean UX is a fantastic mid-level management and down book. Like how do we start to think about designing our teams, assigning work, measuring their success getting folks to collaborate together. what are the questions that they should be asking?

Even super tactical stuff like dual track agile and managing your backlog on a daily basis. Like how do you do discovery and delivery stories on a daily basis? So it gets super tactical in there. So if you don’t manage a backlog, you should probably start with sense and respond.

Murray: Yeah. So could you take us through the, sections on the Lean UX canvas? 

Jeff: Absolutely. So the third edition of Lean UX is organized around the Lean UX canvas. And it became obvious to us that once we started teaching with the canvas that this is how we should organize the book because this is how we teach it. Why not tell the story in the book the same way. The canvas, like all canvases is a facilitation tool, it’s not a checklist, it’s not something you need to go through and make sure you tick every box, but it’s designed to help teams have the right conversations as they set out to tackle new initiatives new products, new services, whatever it is. And it’s broken up into eight steps or eight boxes in the canvas. If you haven’t seen it, but you have seen the business model canvas, it looks a lot like it. It’s just the boxes are different shapes. Pretty much inspired by the same template. 

But it starts off with box one. Box one is the problem statement. And it asks the team to articulate what problem they’re trying to solve. And generally speaking it’s we built the product to do X in some kind of context, and that context has changed. And because of that, the product is no longer meeting its goals. And we see this because customers and users are doing this and they’re doing that. And so then how might we make it better? And if we make it better, what will they be doing differently? There’s no mention of solutions. It’s just a problem statement, what is the problem that we’re trying to solve? Like for example, we built Facebook to connect with our high school friends, and now it’s ruining democracy. How might we improve Facebook to not destroy the world. That’s the problem statement. 

In box number two, we talk about the business outcomes. So if we solve the problem what will people be doing differently. What are the behavior changes that we wanna see in our users? In the business problem statement, the success criteria is very high level. It be things like revenue and retention and maybe acquisition and things like that. But in box number two, we get really specific, we want people to come to the site. We want people to download the app. We want them to create a profile. We want them to add something to the cart, add two things to the cart. And so we wanna be specific about the behavior changes that we wanna see. If we solve the problem.

In box number three, we talk about okay, if we wanna change behavior, whose behavior are we trying to change. So let’s declare our assumptions. Everything in the canvas is an assumptions declaration exercise, we’re doing this together as a team over the course of hours or maybe a couple of days. And so in box three, we declare our assumptions about who our users and customers are, Whose behavior we’re trying to change in a positive way, and we create proto personas, which is our best guess about who we believe our customers are. 

In box four, we talk about the user outcomes. So if we solve the problem and we make the user and the customer successful, what do they get out of it? Not so much how their behavior changes, but what do they get out of it, and it’s things like they work more efficiently, so they save time and they can get home to their kids’ football game. Whatever the benefits are, for them. We wanna talk about those sort of intangible benefits. Now, you’ll notice the thing that we haven’t talked about yet at all is what are we making? We get to that in box number five. The fifth step in the canvas is solutions or initiatives or services or campaigns or whatever it is.

And that’s explicit and by design, because what we were trying to do when we designed this process was to constrain the space with a bunch of assumptions when we have the features conversation, certainly you could start with the features conversation, but it’s super unconstrained and super blue sky.

And so you’re gonna get a whole bunch of irrelevant ideas that don’t really make sense. Look, that may be useful in some contexts, but for the overwhelming majority of the teams that we work with, they already have a sense of where they work, their domain, their customers, et cetera. So if we can declare our assumptions around the problem statement, the business outcomes, the user and the user outcomes, when we get to the solutions conversation in box number five, it’s a very focused brainstorm.

It’s a very focused conversation that says, What can we make for these people so that they get these benefits and that it solves this business problem. It’s a lot of criteria to take into consideration when you’re talking about features. So people aren’t gonna just make stuff up and be like add news, sports, and weather into the app. Come on. So that’s box five as we declare our solution ideas. 

Now in box six, we combine all of those previous assumptions into hypothesis statements. Solution hypotheses are like agile user stories. Where the fundamental difference is that the definition of done is not works as designed. The definition of done is we’ve changed user behavior in a meaningful way. So the hypothesis template says we believe we can achieve this outcome, this change in user behavior if these people the personas, our target audience attain this benefit, what’s the benefit that they get out of it with this feature?

And so what you have to do as a team is you have to ensure that every feature idea that you have can be tied directly to a persona, a benefit for that persona, and a behavior change that you think it will generate in that persona. Writing those hypothesis statements is the first test of any feature idea.

In other words if we do the feature brainstorm, and then in box number six, in the canvas, you can’t compellingly and convincingly say that this idea that I had is for this customer. This is the benefit they get out of it, and this is how we’ll know we did a good job. Then you shouldn’t work on that feature. Something doesn’t make sense there. 

And the final two boxes are about validating those hypotheses, testing those hypotheses. So box number seven, once we’ve identified the first hypothesis, we wanna test, box number seven asks, what’s the most important thing we need to learn first? Conversation about risk. We’ve got this hypothesis that says we believe we should build this app for these customers, and this is how it will help them. Terrific. What’s the most important thing we need to learn first? And the interesting thing is, if you build a cross-functional team to do this, and you should, to be clear, is you’re going to get all kinds of risks. You’re gonna get technical risk and market risk, and product risk, and brand risk, and design risk, and all these types of things. And they’re all valid risks. But at the outset of a new initiative, the ones you should test first are usually around value rather than feasibility. Do people want this? Will they look for it? Will they try it? Will they tell their friends? Rather than can they use it, cause that’s secondary. If they’re not even looking for it. It doesn’t matter if they can or can’t use it. 

And so then once you’ve identified the most important thing to learn first, then box number eight is, okay, what’s the least amount of work that you need to do to learn that? And that’s where experimentation and learning and product discovery comes in. How can we find out as quickly and as painlessly as possible, as cheaply as possible, how serious this risk is and what we should do about it. The feedback from the experiment could be anything from a customer conversation to a paper prototype, to a live data prototype, to a A/B test, a feature flag, whatever. If the feedback comes back positive, terrific. We can continue working on this hypothesis. And if the feedback comes back negative, then we have to determine do we kill this hypothesis? Do we pivot? Or do we figure out a different way to persevere with it? But that’s the canvas. That’s a very fast run through of all eight boxes of the canvas. 

Murray: Okay. And how do you recommend that you developed a canvas? You’re saying with a cross functional team? 

Jeff: Yeah. So the default ideology in lean UX and certainly in sense of respond is a cross-functional collaborative team. So cross-functional, at the very least when it comes to digital products and services means product design and engineering. At the very least, we want those folks represented. Ideally we want all the folks who can make this thing a reality, participate in this process. So maybe not just product design and engineering, maybe we have subject matter experts. If we’re working with qa, maybe QA is there as well, product marketing if they’re there. But ideally a cross functional collaborative team that works together to declare these assumptions together and to build this shared understanding as they do the canvas together? 

Shane: How often do you see that happen? Because, one of the problems we have in the agile world is that the product manager is the person that talks to the customer and does all the research. They hand over the answer effectively to a team to deliver. So how often do you see everybody involved in the lean UX process and developing that canvas? 

Jeff: It doesn’t happen nearly as often as it should. That said, it’s because the definition of team is so loose in so many organizations. In my head. I’m running through my current clients, the clients that I’m, training and teaching with right now. And I’m like, just bring the team and you see this look of curiosity on their face and they’re like, what do you mean by the team?

And I’m like the people who make the product, and they’re like that could be 10 people, or it could be 30 people. What are we talking about here? And I think Part of the challenge is for organizations to very clearly and cleanly define team. So for a lot of folks, like you said, there’s a product owner, there’s a product manager, there’s a designer, maybe there’s another UX person or a copywriter, and then there’s a bunch of engineers, some front end, some back end, some platform engineers, and not all of them are a hundred percent dedicated to this initiative.

So okay, what’s the team? So sadly not enough. And that’s one of the big problems. we can at the very least get a representative from engineering, product management and design or UX to do canvas together, then at least, there’s representation.

Look, ideally if we can build seven to 10 person teams that contain all the disciplines, then it’s a lot easier to get folks to do a canvas like this together. Cause we have a very clear definition, We have very clear roles. But the risk is real. The risk that you describe is real. As soon as we begin to outsource any of this discovery work or upfront assumptions declaration, we slip into agile fall, and we break the shared understanding and we increase the siloing inside these organizations. Anyway that’s what I’ve seen. 

Murray: I’ve worked with an agency that did this with a client, and the issue was that it was done up front and then put on the wall and not revisited.

Jeff: Yeah, 

Murray: I think that’s probably quite common. It’s being done as a kind of project charter project initiation. Thing, which is not really its intention at all, is it? It’s supposed to be a live thing a way of capturing hypotheses and continually changing them every week. Is that right?

Jeff: It is and, it’s a real risk. It’s one of the things I miss a little bit about the physical world because there’s a shock factor when you’re sitting in a room full of folks and you’ve finished a canvas and maybe you ran an experiment and you realized that the canvas was wrong to stand in front of people and just tear it up like physically rip paper in front of people. There’s a visceral reaction to it that you don’t get with a Mural or a Miro board. But you’re right. There’s a real risk to these artifacts becoming fixed and worshiped almost, because we spent the time doing it. When we teach this stuff we try to move quickly. We keep it messy and we try to get to real data. So we wanna get the assumptions out there as soon as possible. But the most important thing is to start the discovery work, the data collection the experimentation, the research as quickly as possible. Because without fail, it begins to poke holes in the assumptions. And the sooner that we can start to poke holes in the assumptions, the sooner we can illustrate the non permanence of this canvas. I think the longer you spend on it and the longer it sits there untouched, like if it takes us two weeks to actually get in front of a customer and ask some questions, the more hesitant the team is to actually make any real changes to it. It’s an absolute risk. 

Shane: I think also who’s completing the canvas also increases or decreases that risk of my experience. So if the team that are gonna do the work are doing the canvas, they tend to have a culture of challenging each other. They have a culture of experimentation and iteration, and so they’re more comfortable writing some things down with the, assumption that they’re gonna, gonna tear it up. 

If there’s a hippo, right? If there’s somebody, higher power who fills it out for them and hands it over, it becomes a immutable requirements document, which is not the idea of it. Have, you found that, that, if it’s filled out by the wrong person it gets treated in a different way and loses its value as a result. 

Jeff: Yeah I mean, remember it’s designed to be a facilitation tool. A facilitation tool to have the right conversations with your team if somebody, and it doesn’t matter who it is, whether it’s a hippo or it’s the product owner manager, or an engineering lead, or a uX person, whatever, if someone goes off on their own, fills this thing on their own, this is here, this is what we’re doing. The sanctity of that document is increased because confronting any false assumptions in that document means confronting that individual person rather than the broader team’s shared understanding. And that’s more difficult to take on one person than to take on the group and say, Look know we, we thought it was gonna be this way, but it’s not. And so yeah that’s a real risk as well. 

Murray: So I heard some pushback from a UX designer on this, on the basis that people are just writing down on their assumptions and then they’re developing a solution based on those assumptions, and they don’t test them even though they’re supposed to. So instead of doing that, what we should do is spend a few months doing real UX research anthropological research, engage specialists. Go out and get all of that real information so that when we write the canvas, It’s much better informed. You can see that this is on the assumption that once it’s written, it’s not gonna change. What do you think about that view that should do a whole lot of deep UX research at the beginning?

Jeff: So I have a lot of reactions to this. First of all, we need to talk about the complexity of the space that you’re entering, and the risks in that space. 

For example, if you’re entering a healthcare space with a lot of risk, a lot of personally identifiable information, a lot of emotion, a lot of people’s lives at stake you know, move fast and break things is probably not the right approach in that space. At least, certainly not upfront. Cause move fast and break things means we’ll probably kill someone. In those situations where there is a lot of risk, there’s a lot of emotional volatility, there’s a lot of personal connection. It can make sense to do upfront research, to understand the space, to understand what’s come before, to understand what’s working and what’s not, and so forth.

So there’s a time and place for that but we should do that work with Eyes Open. The cost of doing that kind of work is waiting around to start actually testing ideas in the marketplace. Which again, in certain context is perfectly okay, air traffic control, we’re not gonna move fast and break things. Nuclear missile silos, we’re not just gonna be like, Hey, try this new UI I came up with over the weekend. See what happens. But in the majority of the situations where most of us work the approach that we advocate for in Lean UX and in sense and respond it’s not an approach that throws out research. Our philosophy is do less, more often. So instead of doing all the research up front, we’re gonna do research, every sprint, so there’s going to be learning discovery work in every sprint. And in doing so over time, we’re doing nearly as much, if not more than the upfront research.

And it’s more relevant. It’s more just in time, it’s more contextually accurate to what’s happening in the world. If a project takes six months, nine months, a year to bring to fruition, remember what the world’s like a year ago, and a year before that, and a year before that, if you started working, did a whole bunch of upfront research in 2019, and then started building an Oh crap pandemic. We don’t have any more research budget , because we spent it all in 2019 and we’re all locked in our homes. The point is that there’s tremendous value in deep anthropological research. There’s a time and place for it. Generally speaking, in the majority of the cases, we advocate for doing the research in smaller chunks and to doing it more frequently, more regularly. So it’s more accurate. It helps inform the work that we’re doing. It helps inform the work that we’re planning on doing. It helps us be agile. It informs our prioritization. Most teams are like we don’t know the space at all, so we have to do three months or six months of anthropological research.

I would guarantee you that in the majority of the spaces, if you were to run a lean UX canvas exercise with a team and they just guessed, they just made a series of assumptions about the world that they’re about to enter, I guarantee you that they wouldn’t be a hundred percent right, But I also guarantee you they wouldn’t be a hundred percent wrong. And so you can get started with that. Remembering that if we’re working in short cycles in sprints, then the amount of risk that we’re taking, it’s two weeks worth of risk, three weeks worth of risk. And if we’re wrong, worst case scenario, we lost three weeks. As long as we learn something from that, we’ll spend the next three weeks more effectively. So I think it’s all there.

Murray: Yeah. So the idea is you come out of this with a list of experiments that you need to do that are being prioritized by risk and value. So you might start off by saying, Do people really want this? How can we test that? And then that becomes what the team focuses on for the first sprint. 

Jeff: Value is crucial, so for example if you’re heading down a path, and again, we’re not talking about air traffic control or healthcare or nuclear missile silos or whatever, but if you’re heading down a particular path and you’re wondering, do people want this? If that’s the most important thing you need to learn first, you can just put up a landing page, ask for people’s email address, and drive some traffic to it, and see if people give you an email address, you can do that very quickly. You don’t need to do six months of anthropological research to find out if somebody will give you an email address for a specific value proposition.

Murray: Yeah. Yeah. So this then means that you’ve gotta have a product team that has all of these skills in it. So you can do research, design, development, maybe even marketing. Is that what we’re talking about? 

Jeff: Yes. We need a product team that can do everything it needs to do to design, define, build, deploy, research a product. Now that doesn’t mean that we need a specific individual from every single discipline to be on the team. Sometimes, that could mean that, but there’s certainly people who can wear two hats and do a decent job. You’ll often find designers or product owners or product managers doing research and discovery work. I know designers who can code. I know coders who can design, it’s a magical world out there if you care to look

Murray: So there’s an argument though that in order to do UX research or UX design, you need somebody who has many years of experience, a real specialist. So that your team of 10 people should have two UX researchers and two UI designers, which would make a very design heavy team, and people can’t really afford that. So what’s your view on having those highly specialized people in the team? Is it necessary or not? 

Jeff: Look, if you’re lucky enough to have a researcher on your team, congratulations. That’s amazing. Not every organization invests in researchers. Generally speaking, you’re never gonna have enough researchers to have a researcher per team. If you’re lucky enough to have one, fantastic, add them to the team and start. But they’ve gotta figure out how to do their work at the same cadence that you’re doing the rest of the work, so how do they fit their work into sprints. And we talk about that in lean ux, not all their work has to finish at the end of the sprint, but they’re gonna add what they’re learning along the way. But the reality is in most organizations, there are never gonna be enough researchers to have one for every single product development team.

And so in those situations, we want to do two things with those researchers. We want to deploy them on those big, meaty, scary, deep research initiatives like we talked about before. Hey, we’re entering this unknown space, or this very risky space, and we need some upfront research so they can do that before the product development teams are assigned to that. That’s one thing we want them for. And then the other is to train the rest of the teams in proper research techniques. Now, they don’t have to make them awesome researchers, but essentially, you’re deputizing them so they know how to run a good customer conversation. It’s not rocket science to do a decent customer interview. You teach people how to do it, you let them practice 10 times and they’re decent at it. How to synthesize the information they come up with and how to make some quick decisions and move forward so they can make people better researchers and empower the organization to do research more broadly.

And I think that’s a good use of those folks. Speaking from my experience the most successful teams I’ve been on, generally speaking consisted of some version of a product manager, a designer, and two to four engineers, roughly speaking. So if you have two designers on a team, that’s a lot. You should probably have a lot more engineers, that’s roughly what I’ve seen work.

Murray: Yeah, that makes a lot of sense to me. The other pushback I’ve heard comes from UI designers who are saying, This doesn’t give us enough time to think through the design concept, because the design concept is at a high level. If we are being asked to redesign a car website to allow customization of ordering and rebranding we need to spend quite a lot of time thinking through it all, how it’s all gonna work together. And the problem with sprints is that they force you as a designer to focus on the micro, on the buttons on some things that are happening on a particular page so, you can get fragmented designs. What would you say to that designer?

Jeff: I think if the concept of the user experience, is largely undefined, then we shouldn’t be designing buttons. Number one, we shouldn’t be implementing buttons. So we’re putting the cart before the horse. And this is an opportunity, particularly if we truly have a lot of unknowns and a lot of uncertainty about the concept of the user experience, what would this look like? How would this might work? This is a good opportunity to do some kind of a spike. So the interesting thing about the agile world is we do have the concept of a research sprint. It’s called a spike. Traditionally, it’s been dedicated to engineering research but that’s not enshrined in any stone tablets anywhere, as far as I’m aware.

If as a team we don’t have a great sense of the concept of the user experience that we’re trying to build, then we could take a week and do a design sprint, where we work together as a team to conceptualize what this user experience might look like, what our assumptions are talk to some customers, build some prototypes.

So that coming out of a week long initiative like that, we have a series of hypotheses about how we might wanna move forward. And again I think that if the conversation that’s on a team is the designer saying, we don’t even know what the UX concept is, and the engineer’s saying, Well, I gotta implement buttons this week. And to be fair, that happens. I know that happens. It happens with the teams that I work with on a regular basis. Then there’s a breakdown in communication there. We have not properly defined the space that we’re going to work in and we need to pause and reset.

Murray: Yeah. I think it still is a bit of a struggle for a lot of people. There’s different ways of approaching it. I like design sprints as an idea. There’s also this idea of dual track design and development, what are your thoughts on that? 

Jeff: Lynn Miller and Desiree C back in 2007 published the original dual track paper and diagram. And you’ve probably seen it if you’ve done any kinda work in this space. And it literally looks like a series of mini waterfalls. And the takeaway, sadly for them cause this is not what they meant when they wrote this paper and what they did. The takeaway was designers work a sprint ahead. Now, generally speaking, we believe that’s an anti pattern. 

Now look, if you’re working a hundred percent waterfall today and your goal is some form of agile in the future, then a sprint ahead is the midway point. On the journey to agility sprint ahead is a good start cuz you’re reducing your cycle times, you’re having conversations more frequently, you’re still handing off, you’re still negotiating, but it’s something there. But the way that dual track is actually defined by Kagan and Patton, myself and Josh is that it’s two types of work, discover and delivery being done by the same team at the same time. It’s two types of work, but it’s one team.

And so it’s a balance, if you think about the concept of the backlog, I love the concept of the backlog cuz it’s super simple and if you truly put it into action in the way that it’s designed it’s a forcing function, it’s a time box and there’s a finite amount of work that can go into that time box.

Its a week, two weeks, three weeks, whatever it is. And so we are going to divide that time box on a variable basis, on a sprinty basis between discovery and delivery work. What do we need to learn this sprint? What do we need to deliver this sprint? Some sprints, for example, we just talked about spikes. Some sprints, we don’t know what we need to deliver. We have to take a sprint and just do discovery work, and that’s okay, some sprints, we know exactly what we need to build. We’ve de-risked everything. We’ve got all the data. We’re heads down building stuff. We’re not doing any discovery work.

And in the majority of sprints, there’s some kind of a balance. We do a little bit of discovery, a little bit of delivery, but the idea is that there’s variable scope for each, and that you can’t expect one to happen without the other. And you can’t expect to account for either of those works to magically take place somewhere else and be managed somewhere else.

So it’s about managing the discovery, the delivery work together in one backlog for the same team, and then adjusting the quantity of each in sprint planning based on what do we need to learn this sprint, What do we need to deliver this sprint? But it’s the team doing it.

And what I’ve seen work just like every user story gets assigned an engineer every discovery story gets assigned somebody to do that discovery work. Will it be the product manager or the designer In most cases, probably. It doesn’t mean that engineers couldn’t do it either or join the process. So I’m a firm believer in the Kagan Patton got Health Sidon version of dual track, rather than the misunderstood version of it, sadly, of Desiree and Lynn’s paper from 2007. But it’s the way that, successful teams work today when it’s done well. 

Murray: That makes sense to me. One of the issues though is that I would think that quite a lot of discovery work should end with the decision not to pursue it. Like a funnel. We need a funnel where ideas go in the top and they get filtered through research and discovery before they go into development. and what I see usually happens is that if something goes into the top of the funnel as an idea, everybody just assumes that it’s gonna go all the way through.

Jeff: Discovery is the place where ideas go to get validated. Yeah, I mean that, that’s a super common Antipater. Yeah, cuz it’s in the backlog now. So we have to build it. And you’re a hundred percent right. Discovery is where ideas go to get tested and it’s not a place where they go. It’s the process of testing these ideas and if the answer is we should not spend time on them, then we should get rid of those ideas. And that’s super important for teams to remember.

The sad part is that a lot of organizations leadership teams won’t let their product teams kill ideas because someone’s made a promise to somebody else that this thing is going to get built. So figure out how to validate it is something that happens all the time.

Murray: Yeah. Why do people have so much trouble doing this in organizations? So I think this is really the territory of sense and respond now. Why is there so much resistance? Why do lane UX canvases get turned into upfront project charters? Why is it that discovery stories just get on a convey belt. Or why is it that people don’t update their hypotheses? What’s the organizational resistance here?

Jeff: The organizational resistance is that people are used to managing to output. We’ve got a hundred years of historical inertia of managing to output, to making stuff. So first of all, it’s how we train managers. It’s how we incentivize them. That’s number one.

Number two, managing the output is easy because it’s easy to measure. It’s binary. Did you make the thing? Yeah, I made the thing. There it is. The thing you told me to make, I made it terrific, Jeff. You did a great job. You get to keep your job. Maybe I’ll even promote you. I’ll give you a raise, give you a bonus. And so it’s super easy to measure. The world we live in today, and this is why this lean UX stuff is necessary, but also why it struggles. The world we live in today, is a continuous world. So as sense and respond possits, we live in a software driven world and the software systems that we build our businesses on top of today are continuous systems. They never end. When I started working, you went to the store and you bought a box of software. I bought a box of Bank of America back in 1995. Like you can get the software on a cd. No one does that. No one’s buying a box of Netflix these days. The software systems that we build our businesses on top of today are continuous and as we know, cuz you look at companies like Amazon and like Facebook and all these digitally native, leading edge engineering companies. You can deploy software as fast as you want, and so the deployment of software, the making of the thing, has become a non-event. 

When I worked in America online in the early two thousands we’d work on something for nine months or 12 months or 18 months and then we’d ship it and man, we had a party, we got a t-shirt and that was a big deal. Amazon ships code to production every second today, literally 60 times a minute, you can’t have a party every second. And so the deployment of software A is a non-event. B is not a guarantee of value. And so the measure of success needs to shift from output to outcomes to the, did we actually positively impact the behavior of the consumers of our products and services? And this is where lean UX and product discovery and agility and design thinking and lean startup and all these concepts shine . They shine because they focus on customer success as the definition of done rather than the delivery of software. But we haven’t built successfully enough times the kind of organizations and cultures that support and reward this. And we haven’t built the educational systems. That support, that teach how to do this yet. It’s remarkably slow.

It’s coming around. But, this is why this is hard because you’ll get, a leader in a leadership position who believes that is their job, to tell the team what to make. Build me this thing and make it blue and ship it by Thursday. We’re, we’re Seeing this play out with Twitter, live right now. Musk is in the office and he is great check marks for everybody. And they ship great check marks and it’s a disaster. Okay? Roll back the great check marks. That type of approach doesn’t work anymore. But we haven’t built the educational system and then inside the organizations, the reward and incentive systems to get those leaders to behave differently. And so that’s why this struggles. We’ve got teams who wanna work in this collaborative, cross-functional, agile, customer-centric way, and we’ve got leaders who are demanding and prescribing that they do specific things based on their unique genius. 

Murray: So what can we do about it though? 

Jeff: What can we do about it? It’s a great question, 

Murray: So let’s say you’ve got a few people in your organization who wanna do this, what are some useful approaches that will help you implement this and get the message across?

Jeff: So let’s talk about the aspirational approach and then the more tactical approach. I think on the aspirational level, I think if you’re a senior product manager who gets this and wants to work this way, then you should aspire to a leadership position. How can you, become the managing director of a business unit? How can you become the chief product officer? How can you become CEO if it’s a small enough company? How can you do that? If we can get folks who think like that into leadership positions, we start to change the culture. We start to move things forward. I think that’s the aspirational aspect of it.

I think the more realistic, or more kind of shorter term, at least tactical thing is to use the questions. So, We teach how to ask the right questions in lean ux and when we do trainings, with product management teams, and so start asking the right questions in a way that doesn’t limit your career, obviously inside that company. But like when the boss says, Go build me this thing and make it blue and. Ship the great check marks by Friday or you’re fired. Okay, boss. But who are we shipping the grey check marks for? And who’s the target audience? And if the grey check marks work what do we expect to see?

What do we hope to see them doing differently? What problem are we solving for people? So just really starting to ask the right questions and try to shift the conversation subtly away from build me this thing to, we’re solving this problem for these people and if we do a great job, this is what they’ll be doing differently.

It’s tough. You have to have a good relationship with your executives and your leaders. You have to have a culture that allows you to ask questions without consequence. And you have to do it in a politically savvy way that doesn’t make your boss feel stupid. There’s a real risk that somebody told your boss to do it.

And he just told you, so the crap rolls downhill, as they say. And so they might not know why. And so just being sensitive to the fact, if you make your boss feel stupid, they may shut down and then you’re done. So there’s a lot of risk there, but I think navigating that conversation is a great place to start. 

Murray: They seem like key skills for a UX designer anyway, to ask those sort of questions and a product manager as well. 

Jeff: Yes, absolutely. Asking questions is a key component of doing both those jobs well. And then teaching your leadership how to ask those questions is a really nice perk of the job if you can make it happen.

Murray: Yeah. So can you explain outcome driven roadmaps. Cause roadmaps are normally these three features this quarter, and then these three features the next quarter. And then we deploy. What does an outcome driven road map look like?

Jeff: So we talk a lot about moving away from outputs to outcomes. It’s a big part of the conversation. And the output based roadmap is the one we’re gonna build this stuff, we’ll get it done in q1, and we expect this ROI on it. The difference in an outcome driven roadmap is that we are not committing to features.

We’re committing to outcomes. If you use the language of objectives and key results, we’re committing to key results, meaningful changes in the behavior of humans. The humans who consume our products and services. And so on a quarterly basis, we are going to commit to key results to outcomes.

This quarter we’re working on acquisition. Our goal is to acquire 30% more customers than we did last quarter, that’s the outcome that we’re targeting this quarter. And our hypotheses, we have seven hypotheses for Q1 about how we might achieve our acquisition goals. So there’s still a conversation around features, but we’re not committing to delivering all seven of those features.

We’re committing to delivering the behavior change, the acquisition. And so as we work through the quarter, we might run some experiments, we might do some discovery work. We might realize that hypothesis one doesn’t do a great job of driving acquisition, but two and three definitely do. And what we actually learned from hypothesis one helped us add a new hypothesis to the backlog as well.

And so we are adjusting the backlog. We’re adjusting the prioritization based on what we’re learning on a sprint lead basis. We’re being transparent about that and communicating that up and out so everybody’s aware of the decisions that we’re making and we are consistently reporting out on how well we’re doing towards our key results. It’s not a conversation of did you ship X or did you ship Y? It’s a question of you told me you could increase acquisition by 30%. How are we doing? We’re up about 11% so far in the quarter, and we’ve got eight more weeks to go. And so this is what we’re planning on doing. And so that’s the fundamental difference.

The fundamental difference is that the measure of success on a quarterly basis is behavior change, not delivery of actual features. Of course, we will be delivering features and yes, of course we have an idea of which features we’re probably going to work on, but we reserve the right to change course based on evidence. We reserve the right to be agile. 

Murray: Yeah this is far more consistent with an agile way of working than the fixed scope contract approach, I

Jeff: Absolutely. 

Murray: And I think teams will love to work this way and be inspired and do much better work. . One more thing I wanted to ask before we go to summaries. What have you learnt over the last few years since you published Sense and respond And lean U X. What have you learned that’s not in the books?

Jeff: That’s a great question. I think one of the things I’ve dealt with a lot in the last year has been been seasonal businesses. I’ve had a few clients this year who run seasonal businesses, and that’s always an interesting conversation because we just talked about fixed scope, fixed deadline projects, it’s waterfall, that’s what it is. And most companies don’t have legitimate deadlines. They’re just used as motivational tools. Elon Musk saying, shipped great checks by November 7th, or You’re fired. It’s bs. But these folks who I’ve dealt with this year do have legitimate seasonal businesses.

One was in the student loan business their season is June. And then another client is in retail, their season is now. And so code freeze is happening now. And so the interesting thing for them is how do you manage outcomes? How do you manage agility when you do have these rigid deadlines? And it’s an interesting conversation because these are legitimate deadlines. And so the question then becomes how much learning can we get done in the season leading to code freeze . And are there opportunities for us to maximize the learning that we get during the high season?

We’re not gonna be deploying code most likely during that season. Okay, that’s fine. But what else can we do during that season to build a lot of insight so that we can spend the next off season really improving things and moving forward. So that’s been a really interesting conversation about managing legitimate and real deadlines in this world and building this kind of outcome based approach for it. And so using the scope as the variable and maintaining the deadline as the fixed aspect. And it’s tough. It’s tough to get organizations to agree to do that. They wanna build everything by the deadline and make sure the season goes great.

Murray: Yeah. Yeah. All right. Should we go to summaries? 

Shane: Let’s do it. We talked about which way do we read them? So if you don’t manage a backlog, then read sense and respond first. And if you’re still interested in the detail, then go into Lean ux. But if you’re managing the backlog or working on the backlog, start off with lean UX and if you love it, then go to sense and respond to see how to change your organization if it’s not behaving that way already.

I’m a great fan of canvases. I find a well thought out canvas that has a well thought out process that supports it has massive amounts of value. Canvases are great to use for a shared language when there’s more than one person involved. And that’s one of the key benefits of the Lean UX campus. The key box for me is what do we wanna learn first? we have some choices, let’s test the risk of not achieving value. Let’s test that one first. And then after that we can test whether they’ll use it, love it, and all that kind of stuff. But if, nobody’s gonna get value out of it, we’re wasting our time.

We talked a little bit about defining a team boundary as difficult. And that’s common across all domains.

So, the boundary of what makes up a product that’s useful. The idea that actually organizations struggle to figure out what a team is, is something that I don’t see a lot of, but I’m kind of intrigued by. And that’s normally because we always start off with five to nine, and then we scale out. So kind of interested about that, where you have organizations that can’t even define what a team is. What that boundary is.

I love this idea when we talked about who fills out the canvas and what happens when, a hippo does it. And that idea that if the team are producing the canvas together, it’s not sacred anymore because we had permission to change. But if it was done by a single hippo, that’s a conversation at one person saying, You’re wrong. Not the hypothesis is wrong, but you are wrong. So, make it a team sport just safer. Hell, a lot more fun I find as well.

Jeff: It is. It is. Yeah. 

Shane: You learn something. I love that idea of do less more often. If we do less. We do it more often than we actually end up doing more of it eventually, but we are doing it in smaller loops, Constant feedback, higher value because we’ve learn something the second time, the third time, and we bring that to the party.

Around this idea of specializing constrain resources. So we talk about moving from roles to skills, which we should do, cuz roles are dead. We always have this problem where we have specialized skills and we have a constraint on them. So we can’t have those skills a hundred percent of the time in the team. You talked About this idea of bringing those specialized skills into focus on the largest area of uncertainty. The largest area of risk. That’s the highest value for those people with specialized skills that we have constraints on to work on.

You talked about research spikes, design spikes. I’m a great fan of spiking when we need to. Timebox them as always because everybody loves to co off on hypothesis for six months. You need to time box it otherwise we overinvest upfront. And then I hadn’t heard that description around Dual Track for some reason I’ve been stuck on the mini waterfall one. So that idea that actually we’re doing discovery work and delivery work at the same time with the same team in the same iteration of the same backlog. We are still working ahead. But the team’s working ahead, not two teams where one’s working ahead and handing over to the next one.

And then the final one for me is making the thing is no guarantee of value. I don’t often see people prove the value . And probably the first time. I’ve heard a blend of product UX domain with agile domain in a way that made sense to me, so thank you. Murray, what do you got?

Murray: Yeah, I think your message in these two books, Lean UX and Sense and Respond is very much the message we are getting from all of the thought leaders in product and agile development and UX design that we interview these days. Everybody now agrees that’s the way to go. Or nearly everybody. It brings everything together. I think at its core it’s because we’re all dealing with the same problem, which is that there’s a lot of uncertainty in what we do about the problem and a lot of uncertainty about the solution and product development, software development is knowledge work where we are learning new things.

It’s not a factory where we are producing widgets over and over again. And our management is all designed around factories. I’ve heard CIOs say software development should just be a factory and I should just be able to crank the handle and get a feature at the other end. It’s just a very old fashioned way of thinking about the world, which never made sense at all to me in software development. It’s just wrong. 

A lot of what you’re saying reminds me of the things that Tom Gilb has to say about outcome focus. Tom Gilb was one of the pre agile guys. I think he’s about 75 now. And he talks about outcome driven roadmaps, outcome driven approaches, outcome focus, spending your first week pretty much doing what you’ve said in your charter. But a lot of what he has done has been forgotten.

But nevertheless, there’s a lot of themes in there that I guess people have been talking about at different times, and you’ve really brought it together in a way which makes a great deal of sense. I think everybody should go and do it, but it is very challenging though. I’ve worked in an agency not that long ago, and we had enormous problems trying to get our clients to develop an outcome focus.

They always came to us with lists of features and things that they wanted to do and digital managers often had no idea what the outcome was that they were supposed to be getting. Not in measurable terms, it was always talking about features and then get put into contracts and they’d be bidding and all that sort of stuff. So it was just really hard to get people to think in terms of outcomes, but regardless whether it’s hard or not, it’s the right thing to do and I think everybody should be trying to do it. That’s where I’ve got to with it. Did you have anything you wanted to add ?

Jeff: The interesting thing is that we have the tools today. We have the technology today to make this way of working easy. The reason why we’ve got all this stuff, Agile and Lean Startup and design thinking and OKRs and Lean UX and all this stuff today is because the tools enable us to learn as fast as we can ship. We’re already taking advantage of the deployment side of it. If we can take advantage of the discovery, the learning side of it with the same enthusiasm and with the same level of importance then the stuff that we’ve talked about in this conversation becomes the default way of working.

Murray: Yeah, I think there’s a lot of answers to the organizational change problem in Team topologies and the unfixed work that Jurgen Apello has done. There’s a lot of organizational design patterns there that would really help people implementing this kind of product team approach. Alright, that has been excellent. Now how can people find out more about you, your ideas, your services and so on?

Jeff: I’m super easy to find. That’s by design. If you just go to JeffGothelf.com, you’ll find everything you need to know there about everything that I do and offer and read all my stuff. And then of course, feel free to connect on LinkedIn. Spending a lot of time there these days, more time there than anywhere else these days. So feel free to connect on LinkedIn. I’d be happy to meet you over there. 

Murray: And you, run a lot of courses, on Lean UX 

Jeff: I do. It’s funny. I used to, run public courses all the time. We’ve had a lot of private client work in the last couple of years. So we generally have not been doing public courses, but we do have self-paced video-based courses for Lean UX and we do a lot of private training. So, you bring a cohort of your own teams and we’ll work with you to train them that way. 

Murray: Yeah. Okay. That’s great. All right. Thanks very much for coming on, Jeff. 

Jeff: My pleasure. Thanks so much for having me. 

.