Podcast: Play in new window | Download

Joe [00:00:00] OK everyone we are here today with Jeff Gothelf and we’re really excited talk to Jeff. He’s got a lot of different topics that he talks about, and he’s also going to be speaking at our conference coming up in the fall. So, very, very, excited, but Jeff, if we could just start off like we always do. Could you please introduce yourself. Talk about where you come from and what you do?

Jeff [00:00:20] Sure thing. So my name is Jeff Gothelf. I am originally from New Jersey. Today I live in Barcelona, Spain and today I work as a coach and a consultant and a keynote speaker with product teams to help them build great products. And I work with the executives who manage those teams to help them build the cultures that build great products.

Joe [00:00:45] Very, very cool. So, you know, something we haven’t really talked too much on this podcast yet about, even though we’re 15 episodes in, is just the practice of Agile and what that means. You know, we focus a lot on UX, product management, but if you’re in one of those jobs you’re probably working with an Agile team nowadays. So we hear terms like modern Agile a lot these days. Has Agile evolved or what does this modern version of Agile mean, if anything?

Jeff [00:01:14] I believe that Agile needs to evolve in order to be successful today. So it’s been around for about 20 years at this point and it has taken the business world by storm. There’s no organization today that will publicly admit to not being Agile. They might not be using it, or using it well, but they’ll never admit to it. When I hear conversations around modern Agile, what that means to me is the kind of work that I promote, that I teach, and that I consult about, which is cross-functional, collaborative, customer-centric and evidence driven. Which, I believe, was the original intent for Agile. All of those things actually end up driving the agility of an organization which I think is ultimately the goal. Most organizations today, the ones that I work with, certainly the medium and the larger organizations, implement Agile recipes. They’re looking for 8, 10, 12 steps that they can take to become more efficient at delivering their product and their service. But what’s missing from that is the value component. So just because you built it doesn’t mean that it’s valuable. And today, given the modern nature of technology and software; the fact that it’s continuous, there’s no beginning there’s no end to it, we can learn very very very quickly whether or not we’re actually delivering value. And so if we can build cross-functional collaborative teams that focus on the customer, that collect evidence, and then decide whether or not the thing that we shipped made a positive impact on our customers, and then if it didn’t, how to improve it, then we’re implementing modern Agile.

Joe [00:03:01] Got it. That makes a ton of sense and I totally agree. You know, as companies nowadays have started mostly to work with Agile, you know, everyone’s got maybe one team or two teams or three teams. Talk to me a little bit about some of the pains you see as companies scale Agile, per se. You know, we’ve got a client who, they first grew to 30 teams and they grew to 120 Agile teams now. What do you typically see on that journey? I remember back at Agile 2015 everyone saying, “as you scale you have to do scrum of scrums,” for example. What are some of the other, the pain points you see as they scale?

Jeff [00:03:33] So first and foremost, if we’re trying to implement these collaborative cross-functional teams, one of the key things that we’d like to give those teams is autonomy, the autonomy to make the day-to-day decisions based on the information that they’re collecting. Now that’s all well and good if there’s one, two, three, four, five teams. But if, like you said, if you’ve got 30 teams, 120 teams, 500 teams, inevitably there are going to be significant dependencies. And so first of all, how do we build clear transparent lines of communication across all of these different organizations so that they can understand what everybody’s working on? How do we reduce duplication of effort so if my team is working on a particular initiative and learning certain things that might be helpful to your team, how do we get that across to you? One other thing that’s become really challenging as organizations have taken on this new, it’s not a new concept but that’s becoming very popular, is this concept of objectives and key results. Basically what we’re talking about there is managing to outcomes and if my team is trying to optimize a specific outcome but that is negatively impacting the outcome that your team is trying to impact, how do I find out about that, how do I make sure that we then start to discuss that so that I’m not ruining your work or vice versa? These are all some of the challenges we see as we scale.

Joe [00:05:04] So what would some of your advice be to both the product leadership and maybe the folks working the day-to-day for their product leadership to allow them to have more autonomy? Does it come down to like the visioning process of how, you know, the larger vision gets communicated down, or is it just like letting them take the reins? Like how does that autonomy occur? What do you recommend.

Jeff [00:05:26] First and foremost, we have to change how we assign work and frame work for our teams. So the first thing that we do is actually frame the work as a problem to solve rather than a solution to implement. That’s the first thing that I recommend. That’s a fundamental difference, right. So it’s a difference between, “build me an iPhone app,” which is a solution to implement, to, “I would like you to increase mobile commerce by 15 percent because it’s not performing as well as it has in the past.” That’s a problem to solve rather than a solution to implement. So automatically you’ve now empowered the team to go figure out how to solve this problem. The second thing you’ve done by doing that is you’ve given them a very clear measure of success that is an outcome. It’s a change in customer behavior. We want more people buying through the mobile channel. And most importantly, what we’ve done in that situation is we have not told the team what to build. We haven’t told them what to make. Right. If I tell you to build an iPhone app, you’ll build an iPhone app, and whether or not it increases mobile commerce by 15 percent, we’ll have to wait and see. But if I tell you to increase mobile commerce by 15 percent, you and the team now have to go discover the best combination of code, copy, and design that drives that customer behavior. And so right there you’ve empowered a team to experiment, to learn, to iterate, to be Agile. And that’s a great start, but there’s a bit that’s missing here is that the teams owe a communication stream back up to their leaders to let them know what they’re working on, what they’re learning and how they’re making decisions. And it’s that proactive upward communication that allows these teams to stay autonomous because if I’m your boss and I don’t know what you’re working on, I’m going to start to revoke that autonomy bit by bit until I find out what’s happening. And so the more that you tell me, the less I have to do that.

Sean [00:07:33] OK so you’ve talked a lot about empowering the team and allowing the team to stay autonomous. I like that. One of the quotes I read in, I think it was Lean vs Agile vs Design Thinking, your book, is that the problem with Agile and skilled Agile frameworks is that they treat other disciplines as support staff for engineers and that Agile puts the business as the customer versus making sure the customer is the customer, the user is the customer, so I’d like to, you know, ask you to talk about that a little bit. What do you mean when you say that Agile, traditional Agile or some forms of Agile, or the scaled Agile framework, treat other disciplines as the support staff for engineers?

Jeff [00:08:15] Agile was conceived by 17 software engineers and so it’s only natural that their frame of reference and the suggestions that they came up with, the manifesto that they came up with, was centered around software development. The majority of Agile implementations over the years have started in the I.T. department which makes sense. It came from software people; it’s safe to assume it’s for software people. But the reality is that today we can’t deliver successful digital products and services without product management, without design, without copywriting, without content strategy. We need those disciplines to build great customer experiences and sadly the majority of the frameworks, including scrum, including SAFe…certainly if you look at Extreme Programming, right, they just simply don’t account for these other disciplines. Now for those of you out there who are practicing SAFe, you’ll say, “well Jeff, you know, SAFe 4.5 has Lean UX in it, right, literally it says it: ‘SAFe 4.5 now with Lean UX,'” which is great, right. But I challenge you to find a team that can figure out how to integrate user experience, design, product management into that SAFe workflow in a continuous way. It always feels bolted on; it always feels either after the fact or before the fact. It’s extremely difficult to find space for these activities in the recipes as they’ve been prescribed to date. And I think that’s primarily due to the origins of Agile and kind of the methodologies that have spawned from the Agile Manifesto.

Sean [00:10:07] Okay Jeff you keep referring to this term recipe which I think you are equating somewhat to a process or to disciplined a disciplined engineering process. And we know at least I I’ve learned from reading your stuff and and from 20 years of experience in this field that there is really no perfect process every team’s different things need to be adjusted.

[00:10:41] But the one thing that I think is universal tied tightly to what you just said is this need for balanced teams independent autonomous empowered and balanced teams. So let’s talk a little bit about what you mean when you say when you use the word recipe and what you think about rigid process versus an alternative.

[00:11:05] So when I say recipe I mean that. Or look if you look at the successful methodologies today scrum for example SAFe massively successful from just kind of a commercial standpoint from an adoption standpoint why are those so successful they’re successful because they provide organizations with a step by step process of how to implement Agile that’s their promise that an organizations who are not experts in Agile or suffer development for that matter look for these recipes because it’s easy right. If we follow these 10 steps then we will be Agile. And that’s that’s the belief. But the reality is that, to your point, there is no perfect process. And the context of your organization your domain your regulations your corporate politics your customers all of those things will inevitably force the morphing of these recipes into something unique to your organization. And that’s part of the underlying theme of what I was writing about in lean versus Agile versus design thinking is exactly that there are components of lean that makes sense in some organizations but not in others. There are components of Agile and Scrum that make sense in some situations but not others designs thinking the same thing. Pick and choose the activities that make the most sense for your organization and help you learn the fastest help you get value about to your customers the fastest and make sense in your domain. I mean for example if you work in in B2C commerce you can get ideas into your customer’s hands and feedback very very quickly. But if you work in pharmaceuticals, for example, that cycle time is going to be longer simply because of the nature of the product and the service that you’re delivering. And that’s OK. So. So again there is no perfect process. Pick and choose the components that make the best sense for your organization and your context.

[00:13:30] So you know and think about like how we’re trying on matter national what’s evolved and what’s different nowadays. And all that. Do you have any kind of foresight into maybe what the next major evolution of the software development process is going to be just based on all the different companies you talk to or what you’re hearing in the fields.

[00:13:49] What do you think is next. That’s a terrific question. Here’s what I hope is next. Which I think is different. Here’s what I hope is next.

[00:13:59] I hope that over time we begin to drop the labels of Agile and lean and design thinking and waterfall and that we we simply have the kinds of organizations and the kinds of cultures that encourage and reward learning and customer centricity. And I think that if we can do that if we can build companies and organizations that incentivize their teams to deeply understand their customers, to ensure that we’re always delivering value for them, and to feel safe changing course if they find out that we are not delivering value to them, then all of those organizations stand a much greater chance of success. And you can call that Agile you call it Design Thinking or whatever you want. But to me, that’s the goal and my hope is that the labels just drop and that’s ends up just being the way that we work.

[00:15:03] Yeah I like that a lot. I mean it should just be the way. Like there shouldn’t be any convincing that you need to talk to customers for example or anything like that. Yes just just be how it works out is. So, one of my favorite things that you talk about is how everything is a product and that is something that I personally connect with a lot I think about a lot.

[00:15:22] And I think that you know this is product managers we’re gonna have a lot of opportunities to really look at the business as a whole. And every experience that you know has a customer touchpoint, or even internally. And think about how to improve that experience or that product. Because it’s all an experience. It’s all a product when you’re thinking about how we interact with each other internally the tools we use the way we talk and communicate every which way a customer can ever work with our product or talk to us. Can you just maybe talk a little bit more about what you think about that? I love the way you’ve framed it in some of your writing.

[00:15:55] One of the things that I try to get across because I don’t work with your software teams. I work with with H.R. teams. I work with legal teams. I’ve worked in finance teams. I’ve worked with teams that build cell phone towers and teams that build locomotives and and industrial lighting systems and air conditioning units and you know you walk into these situations and what I’ve learned over the years is that when. People approach the work that they do from the perspective of ‘I make a thing.’ I make a product I make a service and I have customers or users of that thing. They simply do better work because they start to think about well who are the users of my product and are they having a good experience. And if they’re not. How can I make that better. I get I’ll give you a great example which is it’s going to sound a bit obscure but but this is exactly the kind of application that I think is massively valuable as organizing organizations try to scale agility throughout every discipline. So one of my clients is a global telco. Huge global telco. And I was teaching a workshop for that client and one of the people in the workshops was a woman who writes cyber security policy for that company right. She doesn’t make cell phones; she doesn’t make cell phone plans; she doesn’t make the deal the Web site to buy the plan. Nothing to do with the retail; she makes cybersecurity policy and I said to her I said, “Who’s your customer?”

[00:17:28] And she looks at me like I just you know like I do. My mom is my mother is like three three eyes on my head. Right right right. And. And I said to her I said I said you’re looking at it as if I’m your customer. I’m a vendor for your company.

[00:17:45] And as part of my vendor onboarding process I have to read and agree or not to your cybersecurity policy. And I have to tell you that the cyber security policy that you’ve written is completely inappropriate for a vendor of my size given the kinds of services that I deliver. And it causes me headaches and delays in getting onboard it and getting paid. And I’m happy as a customer of your cybersecurity policy. And this was such an eye-opening moment because you know if you make an app you know if you’re working into technology and software you talk about your users you talk about your customers. But if you work in cybersecurity policy or you work in H.R. and you make a learning and development plan you don’t really think about the user or the customer in the same way that we do when we’re designing software digital products. And I find that when when we do that the conversation starts to shift. Right. Because again we start to move away from outputs. Right. I implemented the H.R. policy to what was the impact. I know there was always a change in behavior that we saw after we implemented that H.R. policy. Did it work. Because that’s what actually matters. And it’s extremely eye opening and it has two massive benefits. One is it increases the agility of the entire organization department by department. But the other is that it helps these non-product disciplines understand how to better support the product disciplines as well because they have a better sense of how they work.

[00:19:19] All right. So use the word agility a lot when your favorite words. I think you define it based on what I’ve heard you say as how well an organization learns. Would you agree with that? Like an organization that’s Agile is one that learns frequently.

[00:19:41] And not not just learns but actually responds to what they’re learning in training that makes up our times.

[00:19:48] So how do you. Have you ever thought about how would you measure or how do you compare team versus team B in terms of how well they learn.

[00:20:00] My thinking on this has changed over the years. My thinking is Agile I’ve learned and I’ve written. I’ve since then responded over the years.

[00:20:12] I’ll tell you I’ll tell you how so when I first started thinking about this this exact question I was hung up on the fact that if you measured if you compared to teens and you said FEMA ran 50 experiments and Team A ran five experiments right to me those were vanity metrics. Those words were not you know Team Team A talked to 100 customers. Team B talked to 10 customers. So what did they learning thing with a good conversations with the right customers.

[00:20:44] Those are interesting questions and I was I was pretty hardcore about that belief for a long time and I still believe that ultimately they are vanity metrics. However however I also now believe where this has evolved is that teams that have never done this before teams that have never since then responded teams that have not done these kind of learning activities. There is value in simply going through the motions. It teaches them how to learn. It teaches them what techniques work better in certain situations. It teaches them to synthesize the learning. It teaches them better ways of responding to what they’re learning. And so today with teams that are just starting out down this path of towards agility measuring things like how many experiments you’ve run; how many customers you’ve talked to; how frequently you talk to customers; how much time you spend talking to customers. All of those things I think are fine. I think ultimately as teams mature what we want to see is things are things like the number of decisions that are made with evidence. I think that that’s a really excellent metric. So there are decisions that are made because someone told us to do it, and there are decisions that are made because hey we felt like that was a good idea. And then there are decisions that we made because of the evidence that we’ve collected. And so to me that’s it that’s been a nice evolution of that and a good measure for a team that is is increasing their learning velocity and the quality of the learning that they do.

[00:22:26] Cool, and if I could pull on. Your initial response to my definition of agility they’re actually doing something with the learning right. So it might be useful to look at how are we measuring what we’re doing with the learning like what is the result that we’re impacting based on what we learned.

[00:22:50] Yeah absolutely. We want to make sure that we’re doing something. And this this is this is believe it or not this. This is also kind of an anti-pattern that I see a lot.

[00:22:57] So I’ve worked with organizations who say look we’re doing everything that you said you know where we’re writing hypotheses and we’re designing experiments and we’re running those experiments. OK. And then what happens. Well nothing. We still just kind of go through the roadmap and build things that we were told to build. Right. And so there has to be that understanding that there are two sides to this. And again there’s you know to be a bit tongue in cheek because the book is called that there’s the sensing part and then there’s the responding part.

[00:23:27] Right. And so sensitive. And they’re both equally as important you have to collect the data and you have to act on the data. And if you’re doing one without the other it’s a broken process, and you’re not getting value.

[00:23:41] So what do you what do you think about. I know you think about it. It’s a fun time. We talk about with several guests now. You know NPS…net promoter score. So if you could just give your little your take on it in terms of it doesn’t provide any value or is it just a totally wasted no don’t don’t even worry about it. Here’s what to do instead that kind of thing. Yeah I actually had differing we had two guests who had both sides of the opinion there.

[00:24:07] Yeah. So I wrote a relatively popular article called “NPS is a waste of time,” which I guess I guess which side that should give you a pretty clear indication of where I fall on this particular side of this argument.

[00:24:26] However, look I know I’m the first person and the biggest cheerleader for customer satisfaction. I want customers to be satisfied. I want them to love the things that we make for them. I want them to come back I want them to tell their friends right. And that’s what I care about. I care about what satisfied customers do. Measuring A.S. is is asking a human to predict their future behavior.

[00:24:57] Right. In the future, will you tell somebody about this experience that you just had. Yes. No. 6. Right. Like who cares right. I think a much better question is did you tell anybody about this. That’s it.

[00:25:15] That’s 100 hundred times better question because that’s a thing that actually happened. Yeah. I told my I told my best friend. I told the Internet and in fact you know that because three people signed up with my referral code. That is a far better indication of satisfaction than me asking somebody to rate their likelihood of recommending the thing in the future. And so that’s so I absolutely care about customer satisfaction. I think it’s crucial. However I think a I think the best measures of customer satisfaction are behavior behaviors in the system. What are people doing in the system to tell us.

[00:25:51] I believe they like to do. I don’t believe. Surveys in general are destructive in terms of how they build relationships. I mean they’re in it they’re interrupted. Right. So even even a small thing like one little question like would you be willing to recommend your friend or family member. It’s still degrading in terms of the experience that you produce. Nowhere on that.

[00:26:14] Absolutely.

[00:26:15] Absolutely. Basically don’t want to listen to what people say watch what they do with your wife’s actions. Exactly. That’s exactly right. And that’s what. Yeah. We were big on the advocacy you know measure of our people actually recommending either using a feature to actually share it with their friend or prefer someone in or you know measuring anyway of doing that is really the value we say that’s kind of like the ultimate the ultimate goal of any product is not really to make money it’s to get people to be advocates and tell their friends or their family recommend it. That’s really investing in the future of the product right.

[00:26:48] Yeah. And if you look if you truly care about this particular question then do what Netflix does. Netflix asks you, “Did someone recommend Netflix to you?” when you sign up. Yes. Yes no. That’s it that’s it. That’s a far better indication of of the answer to this one question than will you do in the future.

[00:27:11] All right.

[00:27:12] So customers vote with their feet. And you know you’ve built a great product when they behave in certain ways like they become advocates or they exhibit loyalty they exhibit trust or things of that nature. And they don’t really care. This is another quote from your book that I’m reading from right now. They don’t really care whether you’re Agile lean or using design thinking your customers don’t give a hoot about any of that stuff. What they care about is that you build a great product. So we need to figure out how to measure what is a great what constitutes a great product right. Yeah. So what have you seen has been sort of the best. So along these lines what have you seen has been a great measure of a great product.

[00:27:59] Look I mean I mean ultimately we’re talking about you know. Well again context is everything right. So Facebook gifted us the metrics of Mao and Dao — monthly average users and daily average users and. Many many organizations have adopted those metrics even though they make absolutely no sense. Right. So my friend Jeff Patton always makes the joke he says. What if you’re in the fire extinguisher business. Right. Like you looking for daily average users of the fire extinguisher. No it’s nuts. It’s crazy right. It doesn’t make sense.

[00:28:40] And you know my father actually owned a fire extinguisher business.

[00:28:48] Well so what’s what’s the measure of the success of that product right. You want people to own them right. That’s one thing. And ideally you wanted to work when necessary but if people are using them on a daily basis it’s a real issue. Right.

[00:29:02] So I think that we learned was that we could charge an annual subscription to have that fire extinguisher measured, but along the way you know there are other there’s inspection touch points. And we figured out like what is the right cadence for that specific business that.

[00:29:20] Right. Right metric for the business. Every every business has its metrics that make sense. Like a dating site. If they’re doing their job it shouldn’t be of any return to users after time.

[00:29:31] Exactly. I used to work. I used to work at a job board called the ladders for four years and it was a subscription service and we wanted people to renew their subscription but not first 18 months. I get three four five six months. It’s like OK something’s wrong here.

[00:29:49] A couple of folks talk about the one metric that matters. Josh Ellman talks about it in his mind the product talk that the guys who wrote Lean Analytics Alister Crowley and Ben Yoskovitz. They talk about the one metric that matters, and really it’s the thing that you want people doing in your product right now and whether that’s subscribing or following or time on site or referring or purchasing. It’s going to differ based on what it is that you offer and how that value is consumed by your customers.

[00:30:30] So I got a question here about you know what it would have fear or what’s the biggest resistance you get from maybe like really senior leadership like CEO C-suite, CEO CMO CTO CPA like what’s their biggest resistance in maybe investing more in talking to customers or just you know this this whole product experience and all this this process we’re talking about what’s the number one push back you guys get.

[00:30:56] Super easy. “We know best,” right. We’re big. We’re successful. We know what customers want. I’ve been in this business for twenty five years. I can tell you exactly what each customer wants. I don’t need to talk to them. I know exactly. I know best. That’s that’s 100 percent. Every time. They are the supreme product owners of all the land…the Steve Jobs quote about you know my customers know what they want want to show it to them on those lines.

[00:31:26] Yes but I’d love this I love it because I wrote about this incense and respond and you know the Steve Jobs thing. God he sold us with that quote you know.

[00:31:37] He gave a set good it’s good stuff to work with and he hosed us with that quote that customers don’t know what they want. Right until they see it right and it’s bullshit; they know exactly what they what they know exactly what they need to get done. Right now the challenge is how big of a you know how big of a gamble or or an innovation effort do you want to put forward to solve the problem for them right. Steve Jobs was a master of that. He was a master of understanding the problem he was solving, and he had the capacity and the desire to roll the fate of his entire company over these big, innovative approaches to solving these problems. I challenge you to find a CEO who’s willing to do that. Every time every time I hear a company or CEOs say we want to be the apple of real estate we want to be right or whatever. Well you know Steve Jobs is willing to bankrupt the company over the iPod; are you? Right? And the answer is No. 100 percent of the time Mr. Elon Musk and so right and that’s another good example of a guy who’s just willing to say look I’m going to do it my way it’s gonna be big it’s gonna be bold. Right. But customers. So again I’m kind of back to the meat of this thing. I think it triggered me with that Steve Jobs quote. But the point is is customers know exactly what they want to do. Right. I need to apply for a mortgage, and I need to do it in his quick and painless way as possible. Right? Now, do I know what a mortgage application looks like. Yes. Do I know what an awesome mortgage application process looks like. I have no idea. Show me one and I’ll be blown away. Right. That’s your job. That’s our job.

[00:33:27] Yeah. You know I look to L.A. Jeff Bezos when he talks about a lot with finding problems that will always forever need to be solved. And you know what he says for example as a customer we’ll never say I want something slower. Right. So they’re always trying to find a way to make Prime faster and now they’re going to be moving it’s a one day shipping to two. That’s just an example of you know there’s always perpetual problems to solve no matter how you end up doing it.

[00:33:51] Yeah no I’m glad I’m glad you brought that up; in fact, I just I was I’ve got my kids I have two teenage daughters and we were at breakfast recently and I was feeling philosophical and trying to convey somewhat some paternal knowledge onto them. And at 6:00 that’s exactly I talked about that exact thing I said you know I said Jeff Bezos the richest man in the world. They know Amazon obviously Amazon’s your daily at our house. And and I said you know what he focuses on not everyone always asks him what he thinks will change in the future and he says what I focus on exactly what you said the things that won’t change. And there’s kind of basic human needs that are never going to go away. And if you can serve those needs you will always be successful.

[00:34:37] Yep I totally agree. All right so we’re I’m so cool.

[00:34:42] I got one last question for you. We’re on this. This what our customers want. Ben here wanted one of the quotes I loved from your book was about user research you said we need to do you use a research for sure but we should do less user research and we should do it less often. So talk about that a little bit.

[00:35:04] Less research.

[00:35:05] Oh I’m sorry I did that wrong didn’t I. Yes you’re right. Let’s use a research but more often. Smaller increments more often almost like Agile medicine that.

[00:35:15] Imagine that. So look I spent a generous part of the first 10 years of my career sitting behind the one way mirror eating a bunch of candy for two days listening to people talk about literally the same thing for two days. Bye bye by 14, 15 people coming through.

[00:35:33] And by the sixth the seventh person you know exactly what’s going to be said. You don’t even know where you’re coming back the next day. But we paid for it. So we got to go through with it. That’s always been the number one push back to research. It’s expensive it takes too long you know what what are people going to be doing while you’re doing your research. There is no reason why we can’t build continuous research into the way that we work. We’ve had continuous delivery. We’ve got continuous design. Continuous improvement. Research needs to be a part of that. And the only way that that’s going to happen the only way that that research will fit into sprints is to do less of it more often. So for example you know in the U.S. we’ve talked about this for years now but every Thursday when you know when I was working at the ladders every Thursday was customer conversation day. We recruited on Monday we got three people to come in every Thursday. We spent Thursday morning talking to three customers. We’d dissect and synthesize the information over lunch make some decisions and move on and start the process again on Monday again. Right. So it wasn’t a 14-person study. It was a three-person study that we were doing on a weekly basis. And so it was less research more often and it fits. And it it builds that continuous feedback loop that agility requires.

[00:36:49] Right and the other thing you said and I think it was in the same paragraph that I absolutely love and I think it will help all businesses thrive if they can figure out how to do this is to be more transparent with all of your findings like to share them more broadly and to share them immediately. Don’t sit on them Don’t mull over them. Don’t spend too much time analyzing them before you get them out there. Do your best to get them out there as quickly and as broadly as possible.

[00:37:16] This is the key. I think this is the key to making this stuff work is creating the safety for our teams to reveal everything that they’ve learned.

[00:37:30] It’s super easy to reveal the win. We thought it should be red and it was good as red so we were right. Right. But if we were wrong we need to be transparent about as quickly as possible because we’re going to change course. We thought it should be red. Red didn’t work so we’re gonna try blue. Okay great. Why are we doing blue? Well here’s why. Right here the findings from our research. And so this is the key. The key is to create the psychological safety for teams to report back their findings whether they’re good findings or bad findings. And if they’re working in short cycles the impact of a negative finding the impact of being wrong is significantly reduced. Right. So if you work in two week cycles if you work in two weeks sprints then the maximum amount of investment that you make in anything is two weeks. And if you’re wrong. Worst case scenario, absolute worst case scenario. Lost two weeks.

[00:38:29] OK so what. That’s certainly less painful than working on something for six months or nine months and then finding out that you were wrong. And so to me that’s that’s the absolute key is how do we encourage that. How do we build the state the sharing of knowledge and learning at every opportunity. How do we increase transparency across all the organization. It’s the key to making this stuff work.

[00:38:53] Yeah I don’t know if anyone’s got a chance to really up a Base Camp came out with a little book online called Shape up and they talk about their process and they basically do these six week cycles and they say well if it doesn’t work out it was only six weeks. You know they’re managing the risk in that sense but they’re trying stuff constantly. So cool. Well this has been a phenomenal episode. Jeff, so thank you so much. You know we always close out with asking a couple more questions of you know besides your own what what’s your favorite book or some of that you give out as gifts or just recommend.

[00:39:25] So the one that I’m giving out these days and recommending a lot is Barry O’Reilly’s new book called “Unlearn.” It’s it’s kind of a if you take everything that we talked about today and you elevated to a process or a methodology that can apply to really any skill that you’re trying to improve or really anything that you’re trying to improve he opens up with this amazing story about Serena Williams  you know kind of reinventing her tennis playing style it really kind of takes this this approach that we’ve been talking about at the tactical product level and elevates it to anything that you’re trying to improve so “Unlearn,” by Barry O’Reilly.

[00:40:08] Awesome we have another one here. Thank you. And then in closing anything else you want to plug or talk about.

[00:40:13] So I would love to let everybody know about my side hustle Josh side and my co-author and business partner and friend; he’s my friend as well. I always forget to say that none the garbage enemy and business partner.

[00:40:29] Well I mean some people are like that but nowhere where we’re actually friends and we’ve written a couple of books together and we’ve actually started a business a side hustle together called Sense and Respond press. Sense and Respond press is a business book publishing press and we publish short practical business books for busy executives. The books are never more than 50 pages long about ten to twelve thousand words. They focus on business agility digital transformation product management and design. And we’ve got about 10 books out there right now. You can see them all a sense and respond press dot com seven more in the works. And the best part about this is that we’re always looking for new authors. We’re looking to help people unlock their first book as well as to provide a platform for underrepresented minorities to help again get them published as quickly as possible. So check out sense and respond press dot com and see if there’s anything of you like that is awesome.

[00:41:27] I’m going to check that out. Very cool site house well and Jeffrey thanks again.

[00:41:32] Yeah. My pleasure. Thanks so much for having me and give me an opportunity to chat with you.