A transcript of Episode 222 of UX Podcast. Josh Seiden and Jeff Gothelf join us to talk about their latest book Sense and Respond plus making change happen, using recipes as a starting point, self-sufficient teams, agile coaches, and shipping something you know is wrong.
This transcript has been machine generated and checked by Tomasz Koper.
Transcript
James Royal-Lawson
UX podcast is funded by me and Per together with contributions we get from you, our listeners. If you’d like to contribute, you can do so financially, but also as a volunteer. We’d love your help to make sure we get our transcripts ready and published for each show in good time. So raise your hand and help us by emailing uxpodcast@uxpodcast.com.
Computer voice
UX Podcast, episode 222.
[Music]
James Royal-Lawson
I’m James Royal-Lawson.
Per Axbom
And I’m Per Axbom.
James Royal-Lawson
And this is UX Podcast – balancing business, technology and people every other Friday from Stockholm, Sweden, with listeners in 189 countries around the world from Grenada to Morocco.
Per Axbom
Today’s guests have been described as designers, strategy consultants, product managers, coaches, authors, speakers, writers and founders.
James Royal-Lawson
And together they have written the books “Lean UX” and “Sense and Respond”. And more recently, they’ve also founded Sense & Respond Press, with the goal of bringing customer centric, evidence-based decision making and agility back into corporate cultures.
Per Axbom
Joining us to talk about culture, operations, agility, templates, deliverables, resilience, recipes and self-sufficient teams. Here are Jeff Gothelf and Josh Seiden.
[Music]
James Royal-Lawson
So, Jeff, Josh – “Lean UX”. It came out back in 2013, I think about that time.
Jeff Gothelf
First edition came out in March of 2013.
James Royal-Lawson
Right, now, well. The follow-up book to that , I guess, is the one that you two did together -“Sense and Respond”. But,first of all tell us a little bit about the journey from the “Lean UX” book to “Sense and Respond”.
Jeff Gothelf
So happy to tell the story. You know that the book has been out now for six and a half years. We wrote a second edition about three years ago and the book has been successful, which is amazing. And the work that we’ve been doing has hinged around the content of the book. And so we’ve collected feedback over the last six and a half years about the material, about how well it works and how well it doesn’t work in some situations. But if you were to homogenise, or boil down that feedback to kind of one core theme, the thing that we hear every single time we get in front of a new client or new class or new workshop or coaching engagement is “We’d love to work this way but my boss or my company won’t let me work this way. We don’t work this way”.
And so Josh and I saw that as an opportunity to have a conversation with the bosses and that was really the birth of the “Sense and Respond” idea and, to be a little tongue-in-cheek about it, really the “Sense and Respond” book and the content that we’ve been working on for the last few years is the response to the feedback that we sensed from “Lean UX”.
Josh Seiden
You know, the specific feedback that we were getting, you know, as Jeff said – people were saying the organisation wasn’t set up to work this way, or “my boss won’t let me”. And what we realised was that “Lean UX” was a book that was filled with things that people, individual contributors and teams, could do differently to work in a more agile way. But that there were just a lot of things that were out of the team’s control and those things, that context in which the teams were working, that needed to change, that was an organisational problem and organisational design problem and so it really was a call to arms for managers to change the organizations – the machine, if you will, that makes the making product possible.
Per Axbom
So I love that how you have learned from the “Lean UX” book and what you learned from there that turned into the “Sense and Respond” book, essentially. Now that the “Sense and Respond” book has been out for a couple of years – what have you learned that you wish had been in it? And how are people responding to that in the sense that “Great, now the organisation is listening to us or is something else we need to still be able to apply to Lean UX processes?”
Jeff Gothelf
Yeah, so I think the conversations that we’re having with leaders who have read “Sense and Respond”, our outlook, our hope was that the people who read “Lean UX” would give “Sense and Respond” to their bosses so that it will be the beginning of the conversation. And we have seen that happen. The conversation that we’re having with the leaders these days is broader because it’s not as simple as saying “Okay, well, I’m the VP [or] I’m the Chief Product Officer – go work in this new, modern, collaborative, customer centric way”.
There are tonne of cultural and operational dependencies in an organisation to change if you really do want to work this way, not the least of which is things like incentives and performance management criteria and things like that. And so the conversations that we’re having are broader – the conversations about the agility of the entire business and the transformation of the entire organisation, which is fascinating and interesting and hairy and complex and difficult.
James Royal-Lawson
Yeah, I mean, it’s organisational change when it comes to the application of these kind of things. You’re not talking about something that happens over a sprint or over, kind of, a couple of months.
Per Axbom
So, I mean – yes, it is extremely complex and, I mean, you understand that it is, but how do you bring that down to “where do we start”? Where’s the key to start on tackling that mess?
Josh Seiden
Well, I think you know, one of the things that we realised and I’ll sort of answer your question in maybe two ways. The first is that our goal for “Sense and Respond”, for that book, was that it should be a high level book that was sort of making the case for change. And to sort of explain in a kind of a broad directional sense, what that change needed to be. A lot of the feedback that we’ve gotten from that book has been “Okay, cool, how do I do it?” And the “How do I do it” problem is a lot more detailed, right? It’s a lot more detailed than your question. Your first question was like “What do we wish was in that book?” Like, you can’t fit “how do we do it” into just, you know, into that kind of book.
And so that was in some ways the impetus for, you know, what Jeff and I have been working on next. I sometimes joke that it’s, you know, it’s the third half of everything I do, which is a new publishing company that we’ve built called Sense and Respond Press. And we published kind of short practical how-to books on exactly this topic, like “How do I make that – those changes?”. And so the books focused on product management, digital transformation and innovation. And there are a series of, like, small, focused, method books that managers can, our hope was, I can read them on a flight from San Francisco to Seattle or from New York to Boston or from, you know, on the train from London to Paris and have a method that I can use in some kind of practical, tangible way to start transforming the company.
James Royal-Lawson
So that was the “Outcomes Over Output”. That was one of the short books as part of the series.
Josh Seiden
Exactly, yeah – so one of the books, the most recent book from the Press. Yeah, we’ve got eight, Jeff, or nine books out now. And…
Jeff Gothelf
Eight we’ve got…
Per Axbom
Oh, really? Wow.
Jeff Gothelf
Yeah, eight published and half a dozen in some form of production.
Josh Seiden
Yeah. Our first book was actually Jeff’s book about the difference or lack of difference between Lean and Agile and Design Thinking. But then we’ve written books on how to run innovation in large companies. And when I say we, as Ryan Jacoby, we have fantastic authors. Woman named Debbie Madden, who runs a consulting firm in New York City, with a great book called “Hire Women”. We have a book by Tim Herbig about how product managers need to be what he calls “lateral leaders”. So I’m not going to list them all, you can go to the website and see them, so it’s not just me and Jeff writing. We’ve got, in fact, our goal is that it’s not us writing but every once in a while we break down and write a book. My, my… I contributed one to the Press called “Outcomes Over Output”, which, again, is responding to this question that I’m hearing in my work, which is “We love this idea of outcomes, we want to be more outcome-focused. But it’s difficult. Can you help us?”
And so that’s really a big, you know, that kind of points to what Jeff was saying, which is that, you know, the change is not just a “Oh, do this new thing”. Actually to be more outcome-focused you need to change the way you framework for your teams, right? Instead of telling them “make me a button” you have to tell them “achieve this results for the business”. And so figuring out what that result should be, how to express it to the team, what’s the right level of detail, how to plan and manage and get visibility into that work, how to staff a team that works this way, how to coordinate outcomes across teams. A lot of issues there. And so that’s what this book is about.
James Royal-Lawson
Actually, I’m, like, thinking, in that particular book, Josh, you, you tweak to the Agile Manifesto? Didn’t you? Did you change the first line of that from… From outputs to outcomes?
Josh Seiden
Yeah, the nerve of that guy. [Laughter]
James Royal-Lawson
Exactly. [Laughter]
Josh Seiden
Yeah, no, I mean, I think you know, the Agile Manifesto you’re referring to, you know, there’s this piece of the Agile Manifesto that says, you know, “Our highest priority is to satisfy the customer with” – I’m going to get the words wrong, but it’s like, you know – “frequent, early delivery of valuable software”. And I think, you know, most of us who work in this business now understand that agile is applicable to so much more than software and that we really want to step back and say “we want to deliver value early and often to our customers and how do we do that?” And so it’s not only about making software, sometimes it’s not about making software at all. It’s about achieving this result. And so how do we broaden our focus to encompass that, to focus on delivering value, not just making a piece of writing code.
Per Axbom
For me, I love how the actual publishing company is an example of a design solution intended to solve the problem of ‘you gave your book to a manager, but they don’t have time to read it’. But you know, they have specific questions, you can hand them one of these books, they’ll sort of have time to read that. And then they’ll realise “Oh, I need to read more of those books.” You’re sort of tricking them into reading a full book, reading it in pieces. And then, essentially, you’re getting your message across by just giving it to them in those small, small chunks.
Jeff Gothelf
Yeah. And look that that is not coincidental, that was born of research. So our background is UX, we are UX designers, right? And the style of work that we advocate is customer centric, right? So if we’re going to build a new product or service for a specific target audience, let’s go understand how to better serve that audience. And we went out and we created personas, you know, target personas of who we thought we were building this press for. And then we went and we talked to those folks. And then we ran the research to understand whether our assumptions were right, and some of our assumptions were correct, and some of them were not as correct. And that helped us really form a better presentation and a better hypothesis for this content that we began to publish.
But one of the things specifically that we learned was, and it really came from, you know, we had a prototype, the prototype was the first version of “Lean Vs. Agile Vs. Design Thinking” which I had self-published just on my own as an experiment. And every time we put that size of a book into the hands of a somebody who matched our persona the first thing they would say would be something like, “Huh, I might actually read this”, you know, and to us that was validating, you know, and it was the length that they were speaking about. They said “Look, this is 30, 40, 50 pages, like Josh said, I can get through this on a flight, or a commute or a train ride.” And that’s far more realistic than a 250 or 300 page book. And so everything that we’ve done here has been research-driven, has been experiment-driven, and most importantly, it’s been customer centric, because, you know, we live the ideas that we teach.
James Royal-Lawson
So okay, so if the book was too long for managers to read, and you said that you can’t fit in all the answers or how you do “Sense and Respond”, how you actually put that into practice? We’ve now got a podcast, which I mean, our interview is going to be like, what, 25 minutes or so. How do we then boil down “Sense and Respond” into an answer to a question on a podcast?
Jeff Gothelf
Josh?
Everybody
[Laughter]
Josh Seiden
Well, well, it’s simple guys, you just follow this recipe.
I think one of the challenges is that, you know, organisations really want, they want recipes because recipes give you the sort of, they let you dictate everybody’s moves from a kind of a central kind of command and control position. And as we try and increase agility, we’re trying to move away from command and control into more of an aligned organisation where leadership is setting direction. And, you know, the folks in the rest of the organisation are, who are closer to the work, are sort of learning their way forward and letting solutions emerge. And that’s really hard and it’s really counter to all of the instincts of leadership, and it’s counter to the structures that we set up.
I mean, you know, starting with fundamental things, like annual planning and budgeting, you know, like, how do you know – it’s August 2019. In the recount, we’re going to come into the sort of annual planning season and keep for now, how in the world am I going to know in October 2019 what I should be building in October 2020? You know, and so, you know, we talk about, we talk about kind of a principles-based approach in “Sense and Respond” which are things like embrace continuous change, you know, that. And just to, just to kind of sit on that one principle for a second. That’s the one that says “look, you won’t actually know in October 2020 what you should be building.
So you need to build resilient systems that are capable of sensing and response, sensing and responding. And then, in your organisation, what does that actually mean? Because we can’t come in here and anticipate all of the problems we’re going to run into as we start to change. So, for example, you might be a consultant company, I worked with a consultant company recently that wants to work this way. But they write contracts in such a way that they promise their clients a specific set of deliverables, right? In other words – “We’re going to make this stuff for you.” And you really can’t be agile when you’re promising a specific set of deliverables. So what do you do about that? And how do you start to change your contracting process? I can’t tell you, all I know is that contract is setting constraint that’s limiting your agility.
And so when I work with teams, and when Jeff and I do this together, it’s about understanding what are the things that are limiting our agility? And how do we design experiments and interventions to start removing those things and replacing them with new structures that might increase our agility?
James Royal-Lawson
I think it’s a great example of the contracting side of things because that, you know, an agency or when you’re agreeing to deliver something, there’s two parties to a contract – it’s you and the customer. So the customer must have requested or agreed to that delivery. So, there you’ve got the opportunity for a dialogue, for a shared understanding of what you’re trying to achieve.
Josh Seiden
Exactly. They’re in the same position where they’re trying to manage their uncertainty, right? We’re not sure if if this vendor is going to be any good. And so we’re going to manage on uncertainty about the quality of this vendor. And by specifying and great deal and a kind of old school command and control away, here’s exactly what you’re going to do. You know, I mean, there’s other contractual arrangements there’s, you know, time and materials, fee for service right. The way we hire doctors and lawyers we can do that, we’re just not used to setting those those kinds of commercial terms when we’re purchasing software or design.
Per Axbom
I like how there’s like a catch-22 here because we’re saying “Of course, there is no recipe”. But what people are looking for when they read a book is “We want the recipe”. So it’s a recipe for not following the recipe, is that you have to keep an open mind, you have to be open to the uncertainty, you’re always going to be surprised. I realise you guys do a lot of teaching and workshops and stuff as well. How do you help people get over that need or want to plan everything and get them to be more, like, open-minded and listening to all, everything that’s going on and sort of sensing and responding to that instead of their plan that they thought they had?
Jeff Gothelf
Look, we like to poop on recipes, to be honest, right? Recipes are fine as starting point, right, so if you’ve ever look at, you read any, certainly stuff that I’ve written and some interviews that I’ve done about SAFe, the Scaled Agile Framework, you won’t hear me say too many nice things about it.But as as a starting point, a recipe is fine. So if your organisation is going to apply the Scaled Agile Framework as a starting point, not as the destination, then fine, right, you don’t know where to start, you want some kind of a step- by-step process to get you started – great.
There’s Scrum, there’s Design Thinking, there’s Lean Startup in the enterprise, there’s Lean UX, there’s SAFe, there’s whatever to combine, right? All these things. Use them as, as a recipe for a place to start, but then truly embrace the continuous improvement, continuous learning and ‘Inspect and Adapt” mantra of Scrum and Agile and so forth. Periodically, retrospect – “We’ve been doing this recipe now for a month, what’s working? Now these five things are working really well, great. Let’s keep doing them. What’s not working? Well, it’s really difficult for us to do these other three things. Okay, let’s do them differently. And let’s try that for a month”, right?
So as long as people use the recipes as a place to start, and then evolve them to fit the unique needs contexts, corporate politics, industry regulations and constraints, etc, of their business, that’s perfectly okay, right? That’s how organisations become more mature in process. The problems come when people apply those recipes wholesale as the destination and anybody who steps outside their little box in a diagram gets chastised or worse, perhaps, right – “That’s not Agile, that’s not SAFe, that’s not Scrum, that’s not Kanban”, whatever it is, right? I think that’s where we get into trouble with these recipes. And so starting points – yes, destinations – no.
Per Axbom
That – I think that’s an excellent way of putting it. It makes me think of, cause I work a lot with accessibility, you have the World Content Accessibility Guidelines and people follow that. That’s the perfect recipe. But that’s not what makes websites accessible. What makes websites accessible is, of course, being able to listen to people with disabilities, including them in the work. So there’s some starting point to get an understanding of the problems we’re facing. But then you have to actually do the real work of talking to people again. So, yeah, completely agree.
James Royal-Lawson
There was something I picked up on in the Respond part of “Sense and Respond” about you suggest that self-sufficient teams are part of the good way of working and that intrigued me, I like the idea of that. Can you say a bit more about how does the self-sufficient team work?
Josh Seiden
Well, so the idea of a self sufficient team is, you know, we talk a lot about in “Lean UX”, we talk about small, cross-functional, co-located, self-sufficient teams. And that means that it’s a team that has all of the capabilities they need to plan, design, create, and deliver their work. And now, in other words, they’re not, they don’t have dependencies on, you know, other parts of the organisation. They can make a thing, they can ship it, if it works – great, it lives, if it doesn’t work they could pull it back. The sort of fundamental notion here is that dependencies reduce agility, right?
So you want to create these teams that have, you know, ideally, you know, dependencies on external people. It’s hard to do, maybe actually impossible but that’s kind of the goal and so to do that you need to, kind of, it starts to break down some of the silos in the organisation, you have to move the engineers and the designers and the testers and the product people – they actually have to sit together. Which, you know, sounds simple but in big organisations moving desks can be difficult, right? You have to figure out, in regulated environments, you know, how are people going to ship when we’ve got this policy that everything gets three levels of oversight and review from legal and compliance and blah, blah, blah, right? What can we do to limit or minimise or eliminate that dependency? So it’s again, it, like, depends on the organisation, it’s challenging, but the goal there is to have a team that can just act without intermediaries and act quickly.
James Royal-Lawson
Yeah, no, I like when you saying again it’s not a dogma, you don’t have to be completely self-sufficient. But if you’re striving to become more self-sufficient, then you will operate better.
Josh Seiden
Yeah, and I think with all of this stuff, you know, I mean, we were just talking about recipes and like, you know, recipes, to Jeff’s point that they’re good starting points, they are the way that we kind of encode and hand off expertise, you know? If you don’t know how to make clam chowder, right? Here’s a piece of paper. This is going to tell you how experts have figured out how to make clam chowder, right? Now go make it your own.
And I think what we miss sometimes in that are the principles behind the recipe. And so self-sufficient teams – that’s the recipe. What’s the idea? What’s the reason? And the reason is that cross-functional, collaborative teams are better because they have more points of view. They create better solutions because they bring all these different points of view together. And they’re faster because they are not limited by dependencies. So there, you know, again, dependencies limit Agile. And so when you start going back to like, the reasons behind these recipes, that’s when you can really start to make them your own in the organisation.
James Royal-Lawson
You know what I’m thinking? – I’m thinking about baking, now, of course. Well, I do, I do…
Josh Seiden
[Laughter]
Per Axbom
James, James bakes a lot.
James Royal-Lawson
I do a fair bit of baking. And that’s exactly the same thing with the recipes. You look around for the chowder or some recipe for a cake and you think “Oh, this sounds excellent!” and then you start doing it and you think “No, this is not, now I need to do this instead or try doing that”, or “This will suit my taste or my family’s taste better”.
Josh Seiden
Yeah.
James Royal-Lawson
Because I think we’re a bunch of individuals just like organisations, I guess are individual, that’s erm. Now, one person can like, you know, lager, one other person likes, you know, stout or porter or something – very different taste.
Josh Seiden
Yeah, and if you think about, if you think about that analogy change, like, you know, if you do a lot of baking, you’re at a point where you can look at a recipe and kind of very quickly say “Well, because I have a lot of experience here, I know how to bring myself into this recipe, and I’m going to change this or I’m going to change that”. And, you know, somebody who’s new to baking wouldn’t have that, sort of all of that tacit knowledge that you’ve built up over your years of baking and so it’s going to be more inclined to just stick to whatever the recipe said and wouldn’t even know if, you know, this happened.
This happens all the time, right? There’s a typo in the recipe. And it says, you know, this crazy amount of salt versus a normal amount of salt. And you go like “Okay, well the recipe says put in, you know, a cup of salt” instead of a teaspoon of salt and this thing tastes awful, you know? So having being able to bring that tacit knowledge – I would say that’s another thing and maybe Jeff, you can comment on this, but I think that’s one of the reasons why coaches are so valuable in transformations. You know, Agile coaches get a lot of grief online. But these are people who’ve done this before and can see the trouble and the recipe and can also help you learn the principles behind these recipes.
Jeff Gothelf
The good ones, the good ones. And so this is the thing, right? And so I’ve worked or been, you know, I’ve collaborated with or have been working with organisations who use Agile coaches and I find that the good ones, who have seen the recipes evolve into useful methodologies inside organisations, definitely want to have this conversation. But I’ve also met Agile coaches who are very staunch defenders of the recipe. And when, you know, you and I both take a very non-traditional, sort of non-purist view of the Agile processes and methodologies, and when you present a challenge to the recipe, there often comes up a big defensible “That’s not Agile”, right? “That’s not Scrum” or “That’s not how we do it”.
Per Axbom
Yeah.
Jeff Gothelf
Right? So I think that the more enlightened Agile coaches definitely get it, but I’ve definitely came across those that don’t.
James Royal-Lawson
Yeah, I mean, there’s just such a huge amount of common sense to all this isn’t it, really? I mean, like, go back to the baking analogy – when sometimes I bake stuff that I like I suspect no-one else in my family alike, but I’ll bake it anyway. And I end up with a huge pile of cookies or biscuits or something that I’m gonna have to munch through over a few days because they’re not interested. But okay, maybe next time I won’t, I won’t.
Per Axbom
Poor James.
James Royal-Lawson
[Laughter] Exactly, pity me. But then, whether the next time I will do that one or I’ll change it. I’ll tweak it another way because now I’ve confirmed that they don’t like it. And I already knew that they probably wouldn’t like it.
Per Axbom
Oh, this is interesting, because I actually have a question I want to ask because it’s something that I come across a lot because I work in a lot of big projects and health cares. You guys are saying that we need to put something in the market, but I assume it will be wrong. Yes, we put something up. But there’s never ever any budget for something being wrong because that’s when the projects and maintenance takes over perhaps but there’s not, like, how do we help people understand the importance of, we will learn so much that’s our, I mean, it’s a fantastic opportunity to perfect the product after we actually put it out there.
Josh Seiden
So Jeff and I ran a consulting firm for a few years together and clients would come to us, clients who were not in the software business. They would come to us and they would say, you know, “We need an app”, or “We need you to build a thing for us” and I would say to them, you know, “You think you’re buying a packaged solution that you can just kind of have, but you need to think about this is, like, you’re getting a puppy, you know, yeah, you’re gonna be, you’re going to be taking care of this puppy for the next 15 years, you know? And so are you really prepared to take ownership of this, of this solution that you’re buying?”
Because it’s not a project in the traditional sense of, like, we build a building and then we have a building and we can dismiss the construction crew. It’s a product, it is a different way of thinking and organising work, and an ongoing commitment. You don’t ship it one-and-done. And so – really moving organ. This is one of the changes that we talk about. That is one of the kinds of changes we talk about in “Sense and Respond”, which is that embracing continuous change means it’s not one-and-done. Your first release is the first of many.
Jeff Gothelf
Exactly.
Per Axbom
I feel like we have a couple of new books for you to be writing on. Right now, Agile coaches and how to launch and to learn after launch and stuff like that. Because I mean, I would, I would definitely want to read those. And there are so many good things to say about it.
Josh Seiden
Well, I will tell you that we’ve got books coming on one of those – too early to talk more specifically about that.
James Royal-Lawson
Oh, a cliffhanger.
Josh Seiden
[Laughter]
Per Axbom
Yeah. This was awesome. Thank you for talking to us and I hope we’ll actually be able to talk about some more upcoming books soon again.
Josh Seiden
All right, terrific. Well, listen, thank you both for having us. It’s always a pleasure to connect.
Jeff Gothelf
Yes, thanks very much. This was great.
Per Axbom
So I really liked the analogy with baking because it was so easy for me to visualise how you experiment when you’re baking and even when you’re cooking, of course, with recipes once you’ve confidently made them X number of times and you know that these are the things that go into it, then you feel confident enough to start experimenting. And that’s how you build knowledge. And experiment.
James Royal-Lawson
Yes, you make mistakes when baking and cooking. You do experiment when doing stuff like I said, you maybe throw in a different ingredients or more of a certain ingredient to see what happens. But I think another thing that’s fascinating is that you build up like a realm of knowledge within baking that some of it is quite inherent, that’s quite obvious, you’d say, there are certain things you don’t do. Like if I’m thinking about what to do with these cookies this time, I don’t grab the nails and throwing a bunch of tucks or whatever into my baking. And I’m not going to, like, break a bottle and throw glass in.
I understand that there. There are certain experiments, certain limitations to what I should do, as part of my experimentation, all these things I don’t need to learn, I guess. Because, you know, maybe I picked up as a child or I don’t know, I picked up early in my career. But yeah, it’s a very, very interesting analogy to use the baking one, I think very much about how we…
Per Axbom
Yeah, if you continue on that, I mean, if you if I tell you to make chocolate muffins, then that’s probably not enough information or maybe it is and I say “I want them with nuts” and then you start having to ask me “So who are these muffins for?” And that’s when we start getting into what I really like, what Josh was saying about people’s specified deliverables when they’re doing proposals. So they’re specifying – “This is what we’re going to give you. We’re going to give chocolate muffins with nuts, and this and this and this”. But along the way, as you’re talking to the people who you’re making the muffins for, you may realise you have to change that. And all of a sudden, the deliverable that you’ve written inside the proposal is wrong.
James Royal-Lawson
Yeah. Exactly. That you’re going to end up shipping an experiment with nuts in that could potentially cause allergic reactions to all the people that are eating them.
Per Axbom
Yeah.
James Royal-Lawson
Maybe.
Per Axbom
Exactly. Yeah.
James Royal-Lawson
I like that.
Per Axbom
Because the client thought that everybody was…
James Royal-Lawson
You know, rather than maybe the client didn’t realise that that’s could be a problem.
Per Axbom
Yeah. Right.
James Royal-Lawson
The knowledge wasn’t there previous to it. The knowledge wasn’t there. So, yeah, it’s embracing continuous change, absolutely, and shipping experiments and shipping things quickly because, it’s just, you’re never going to be finished. Excellent. But, you know, we’ve still got to build up that knowledge and keep holding the knowledge and make sure we don’t cause too much harm.
Per Axbom
Yeah, and how do you recognise the knowledge? If you’re someone buying the services, it’s really hard. I mean, usually people just go “Look at that”, they look – the deliverables look the same. In both proposals. One price is lower than the other – I’m going to go with the lower price. But within the higher price of the other proposal, there might be so much experience in realising that we’re going to be changing this along the way as we learn more.
James Royal-Lawson
But even if you don’t look at the kind of buying in this from an external vendor, and you look at in-house, you know, how do you do it in-house? How do you, kind of, you know, bake your cakes without glass in? Or nuts in?
Per Axbom
Yeah, I don’t have a good answer for this. This is hard. This adaptation of knowing that we have to change along the way, I think this is one of the most difficult things for us both to do but also actually convince the rest of the organisation on because if people are used to us “Oh, so the UX people come in -they’re the ones who do the customer journey maps”.
But at one point or another, we’re gonna realise “Well, in this case, the best thing is not for us to do the customer journey map”. And then someone’s going to say “Well, so why do we need you?” “You need me because I was the one who realised that’s not what we need. We need to go. We need to go out and talk to people and do user interviews first before even trying to do that customer journey map”.
James Royal-Lawson
Yeah.
Per Axbom
But that how our industry and actually how our profession does different things in different scenarios I think that’s what other people have trouble with understanding. How am I supposed to hire you if I don’t know what you’re going to be delivering? I think that’s why we argue so much about what we do.
James Royal-Lawson
Yeah. I wonder if this is related to ,well, why we’ve seen such a growth in in-house teams, that with in-house teams you’ve internalised that issue or question that you’ve already reached, right?
Per Axbom
You don’t have to ask for it because the team will take care of it.
James Royal-Lawson
Yeah, when you’ve reached that point in maturity, where you’ve understood that this is an important part of your basic recipe, that designers or UX needs to be involved. So you bring that resource in-house and then you’re trusting it to make these decisions. And it’s, you know, as it’s a continuous improvement and an ongoing commitment. The fact that you’ve bought into the idea of them, these results have been needed, means that you don’t necessarily need to worry about exactly what they’re delivering. Maybe.
Per Axbom
Interesting.
James Royal-Lawson
But now I’m being very kind of like, high level about what UX resource is. I mean, you know, I know that there’s people who are hired to produce, you know, prototypes or kind of like sit there creating something maybe in, you know, XD or Figma or something. I mean, that is what you do as part of a scaled process.
Per Axbom
Exactly.
I’m not sure we’ve answered any questions here, but it’s it, you’re problematizing things that we need to be thinking about all the time. How we communicate these issues. And how we take care of this.
James Royal-Lawson
It’s fine, but because I suppose it’s some way our outro today is, rather than it’s, kind of ‘come with concrete advice’, we’re giving people the ingredients to maybe work on their own recipe.
Per Axbom
Exactly. We are sensing and the listeners now have to respond.
James Royal-Lawson
Or keep on researching. Keep on digging. We don’t have all the answers, Per.
Per Axbom
[Laughter]
James Royal-Lawson
Damn it. [Laughter]
Per Axbom
Which is why we do have an answer in the form of a recommended listening after this episode, which would be Episode 75, “Principles of Agility” with Dave Gray, which will bring you even more questions.
James Royal-Lawson
Thanks for listening. Always a pleasure. Quick reminder – you can contribute to funding UX Podcast by visiting uxpodcast.com/support. Or you can send us an email and volunteer to help with our transcripts.
Per Axbom
Remember to keep moving.
James Royal-Lawson
See you on the other side.
[Music]
Per Axbom
James, did you hear about the guy who stole the calendar?
James Royal-Lawson
Nope, I didn’t hear about the guy who’s stole a calendar.
Per Axbom
Yeah, he got 12 months.
James Royal-Lawson
Oh, God.
This is a transcript of a conversation between James Royal-Lawson, Per Axbom, Jeff Gothelf and Josh Seiden. Recorded in October 2019 and published as Episode 222 of UX Podcast.
This transcript has been machine generated and checked by Tomasz Koper.