Podcast Ep. 14: Chris Spagnuolo on Design Thinking

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In this week’s episode of the Agile Coaches’ Corner podcast, Dan Neumann brings on a colleague of his at AgileThought to explore the topic of design thinking —Chris Spagnuolo. Chris is one of the Product Specialists at AgileThought, serving as Principal Consultant of Product Management and Innovation. He has a deep background in a lot of things from a product standpoint and is incredibly passionate about all things related to design thinking, Lean Startup and agile.

During this episode, Dan and Chris share their insights on what design thinking is, where it came from, its core elements, and how to incorporate it into overall delivery. Chris also gives his advice around design thinking and where he sees it developing in the future.

Listen on Google Play Music


Key Takeaways

  • What design thinking is:
    • Designing products with people in mind
    • Focusing on understanding the problem that you’re solving and understanding the person that you’re solving it for, and then building a solution
    • A fluid process with a loose methodology
    • Building a product, having the real end user test it, and incorporating their feedback
  • The five core elements of design thinking
    • Empathize: get to know your customer on a personal level (who they are, what they do, and what they’re trying to do)
    • Define: looking at how you can start to frame the problem that your customer has
    • Ideate: coming up with as many ideas as possible that can solve that problem
    • Prototype: create lots of low-fi prototypes to see if these solutions solve the problem
    • Test: give the customer the solution, test it with them, and collect the feedback without bringing your own biases or opinions in
    • And remember: you don’t have to go through these core elements in this order; you can go back to any of them at any time to get it right
  • Chris’ advice around design thinking:
    • Small batch things and solve small parts at a time
    • Support continuous discovery
    • The more feedback the better; don’t make false assumptions about how to go forward
  • How to incorporate design thinking into the overall delivery:
    • Getting feedback from real end users to incorporate
    • Start up an input committee and get real customers that well-represent the end users to sit on the team
    • Get feedback on each iteration
    • Make sure there’s somebody holding the vision and focusing the feedback back into the iterative process
  • Where Chris sees design thinking being applied in the future:
    • Escaping the realm of product development and instead permeating business in general
    • Being brought into the organizational level for better engagement
    • All decisions within the business



Mentioned in this Episode:



Chris Spagnuolo’s Book Pick:


Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.



Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.

Dan Neumann: [00:17]  Welcome to the Agile Coaches’ Corner Podcast. I am your host, Dan Neumann and one of our goals here is to bring you agile topics in a really approachable way and I’m looking forward to doing that with my guest, Chris Spagnuolo today. Before we get into that though, if you have a topic you’d like us to discuss, you can email it to podcast@agilethought.com or you can tweet it to us with the #AgileThoughtPodcast and we’ll look to include that in a future episode. Chris, thank you very much for joining me today.

Chris Spagnuolo: [00:47] Thanks for having me.

Dan Neumann: [00:48]  Chris is one of our product specialists here. He has a deep background in a lot of things from a product standpoint, and today we’re gonna be exploring design thinking and for those who aren’t familiar with design thinking and maybe where that concept has come from. Chris, could you give us a little bit of a lead into what design thinking is? Maybe where it came from?

Chris Spagnuolo: [01:08] Sure. It’s it, it’s been around for awhile. So it’s, it’s nothing new and nothing earth shattering. Um, it’s just that we’re starting to see a lot of people pick it up and try to use it. And what we want to do is make sure that people are using it the right way. Right. But it started, you know, quite a few years ago, you had people from Ideo, um, who really brought it to the forefront of thinking about how we design products, uh, for, for people. Right. And really at the heart of it, it was all about understanding what the problem is that you’re solving, understanding the person that you’re solving it for, and then build the solution instead of build a solution and look for the person who might want to use your solution, but not really, no if you’re solving a problem or not. Um, so Ideo really grabbed onto it and, uh, folks at the Stanford Design School really, um, with Ideo kind of codified that. Right. And really got it to a point where it became almost a methodology. Right? And it was an easy way to walk through, um, figuring out how to design products for people and build products that people love.

Dan Neumann: [02:12]  You use the term methodology. And, and to me that brought to mind the use of that term around a lot of agile methods around let’s say Scrum, which we referred to as a framework versus the methodology. I’m curious the degree to which, uh, Stanford D. Schools work being viewed as a methodologies may be helpful or harmful. Is it really more of a framework like we think of as Scrum or is it truly a methodology where you kind of follow a recipe?

Chris Spagnuolo: [02:38] That’s a great question. And I, I really struggle, actually struggled with both words, right? Methodology and framework. And I try to stay so agnostic from either one. Um, when I had my own independent consulting thing, one of my catchphrases was, you know, dogma solves nothing. And I feel like when you get hooked into methodologies and frameworks, it starts to become dogmatic. Right. Um, so that does become problematic because design thinking to me is a very fluid, um, quote unquote methodology, right? It’s a very fluid process that you’re moving through. Um, and there, there are five general meta patterns and we can move back and forth between those meta patterns and lots of different ways depending on what we’re learning as we go through it. Um, so to say that it’s a strict methodology where you follow the steps and you know, one, two, three, four, five, you’re done. It doesn’t really work that way, right? It could be. We started one, we go to, we go to three, we go back to two, we go to three and we go back to one, we go to three, we go to four, we go back to two. Right? We’re all over the place until we really feel comfortable that we have a valid understanding of who it is that we’re building for, what they’re trying to achieve, what their problems are, and then what the outcome is, right? Like what the product is that we’re going to build that’s going to solve that problem. Um, so yeah, methodologies and frameworks really get under my skin. So I try to stay away from it. And if you’ve ever seen the design squiggle there, there’s this like class of thing called the design squiggle, right? And it’s just this line that looks like this big, not like a ball of string at the beginning. And eventually it gets a little neater looking. And by the end it’s a nice straight line where you’ve got clarity and focus on what you’re doing. And that line sort of represents the journey, right? It’s really messy at the beginning. So, so the methodology, the framework, it kind of guides you along with, here are the things you need to be thinking about, but it doesn’t give you prescriptive steps.

Dan Neumann: [04:30]  Dogma may solve nothing, but without it, we couldn’t have good Twitter fights. I mean, yeah, no, I liked that dogma isn’t going to solve things. Um, you alluded to the five steps or the five phases, elements of design thinking and the ability to hop through. And maybe it would be good chance to talk through those. So you know, they’re uh, empathize, define, ideate, prototype, test, and we’ll, we’ll put a visual up in the show notes that people can get at AgileThought.com/podcast in the show notes. But yeah, let’s maybe talk about those steps to again, help build some more familiarity with the design thinking.

Chris Spagnuolo: [05:12] Yeah, sure. It all starts at the beginning, right? Where we have to do some basic research because we’re in an area where there’s a lot of uncertainty, right? And we don’t really know what we think we know, right? Like I can’t tell you how many times when I talk to product managers or product owners and ask them to tell me about a day in the life of one of the people that they’re building for. I kind of get blank stares, right? It’s, Oh, I haven’t talked to them. I don’t really know. Right? So, so step one is called empathize, right? It’s the first meta pattern and empathize as really getting to know your user. Right? And I don’t like the word user so much. It’s your customer, right? It’s the person you’re building for and get to know them on a personal level, right? Really understand who they are, what they do, what they’re trying to do, right? And, and go deeper. You don’t want to just do this superficial, what’s your job title and what your job description. You want to sit down and watch them work, you know, and do some observational stuff. Um, do some ethnographic research and really get to understand who these people are, right? So, so there’s this sort of research getting to know you meta pattern called empathize. Um, and then once we get past that, we start to think a little bit about what are the patterns we’re seeing and how they’re working. And we get into the define Meta pattern, right? And define is really looking at, um, how do we start to frame this problem that this person has, right? Um, and how do we frame what their day to day looks like in respect to that problem? So we get into a little definition thing where we’re looking for patterns and some insights about what we’re seeing. And then we move into the ideate phase. And ideate is really about, hey, let’s come up with as many ideas as possible that can solve that problem, right? They can be anything from the most mundane, boring solution to the completely outrageous and nothing’s out of bounds. Like what, uh, what bothers me when I get into the ideate phase a lot of times with a lot of organizations is I get fixated on just finding one solution right away, right? And, and really what we’re going for at this point, is just volume of solutions come up with lots of different ideas and then start prototyping those. And when I talk about prototyping, um, that’s the next meta pattern by the way, is prototype. Um, I’m really talking low fidelity prototyping. Um, what it is, is just putting something in someone’s hands so they can see what it would feel like, uh, trying your solution and seeing if it solves the problem. Right? Um, so we’re building really low fi prototypes were not writing code. It’s anything from paper prototypes. You know, there’s a great exercise that the Stanford D. School has everybody go through and it’s this wall and exercise and you’re building a wallet that solves a problem for, for people who need a new wallet, right? Um, and the prototyping tools are great. They’re scissors and glue and sticky notes and cardboard and string and all that kind of stuff. So it’s super low fidelity, but it gives you something that you can give to somebody, right? Um, and it’s a bias towards action. You’re making something to give somebody to test. Right? And test would be the last of the matter patterns. We give it to them, we test it with them, and we collect the feedback. And what we’re trying not to do in that test phase is bring our biases and our opinions into it. We stay very quiet. Right? And a lot of times my advice is when you’re testing, the more you’re talking, the worse you’re doing kind of thing. Um, you want all the feedback you can get. You want to watch how they’re using that prototype, how they’re misusing the prototype. Um, sometimes the misuses are really interesting because you gain tons of new insights of what you should have developed, right? Um, but like I said before, the interesting thing with that bunch of meta patterns that that’s kind of the overarching view, right? Um, we’d go through empathizing, defining, ideating, prototyping and testing, but at any point in there, we can go back to any other point, right? We can get through definition and realize we don’t know enough about this person, right? Or we don’t really understand the problem deeply enough. Let’s go back to empathize, right? Or, we get to the ideate phase and realize, you know, we might not have really frameless problem appropriately or we can get all the way down to test and realize, we built a really bad prototype or we came up with a bad solution. Um, or, or not so much a bad solution, but just an incorrect, it didn’t solve the problem, right? So we can go back and forth and over and over again until we get through that last test where we’re like, we are super confident that what we have here actually solves a problem. Right? So, so that’s sort of it. And in a nutshell.

Dan Neumann: [09:44]  So I’ll give you a little devil’s advocate. So now that we’ve come up with the solution, we just go build it right now we just Scrum our way through in two week sprints and build that bad boy. Is that what you would encourage?

Chris Spagnuolo: [09:54] Um, no. So what we’re really trying to do is if you think about this whole idea of design thinking as your discovery piece, right? The thing that’s actually feeding the backlog, um, what I really encourage is small batching things, right? Um, so when you’re doing discovery, when not trying to solve the entire problem all at once, right? We’re trying to solve little pieces of it at a time. So we solve it as best we can. Um, so what I really recommend is along with, um, you know, your Scrum teams that are really focused on continuous delivery. We have this other kind of parallel track, right? This dual track of continuous discovery where we’re constantly doing design thinking to feed that backlog. So all the things that make it into the backlog have kind of gone through this process where we really think deeply about what’s going into it instead of just a product owner, you know, filling out the template, you know, there’s a little story card there with the template and, and coming up with ideas out of their head. This is all stuff that’s actually gone through a good degree of validation. I’m using a design thinking process.

Dan Neumann: [11:08]  Yeah. So a really integral part to that refinement of the product backlog or these product backlog items where you know, if the team is delivering within the current sprint, if you’re using the Scrum framework or if you’re doing a flow based, the team’s delivering some of the items off the top of your product backlog and then the, the product specialists, the product owner and Scrum or other people responsible for the backlog are taking a design thinking approach to the refinement of items as they’re, they’re bubbling up and becoming more and more important. Is that uh, an accurate description of, of what you’re envisioning?

Chris Spagnuolo: [11:42] Yeah, that’s a really good description. And what I’d really want to be sure that, that we kind of mentioned here too, is that what we want to make sure doesn’t happen is that teams feel like they’re losing their autonomy or, or their creative input into the process, right? So, so what I’m not suggesting is that design thinking is, um, a throw it over the wall kind of process, right? We’re done with design thinking, here’s the prototype, go build it. Um, it’s not really what we’re saying, right? The prototypes we’re handing off, like I said, they are super low fidelity. You know, the, the interface may not even really be worked out. We’re just trying to figure out, you know, did, did our little thing here solve the problem and we want to give that to the teams and really say to the teams. Here’s the problem, here’s the thing that solved the problem. Build the thing, you know, with the, the core of the solution intact, but have the freedom to build your interfaces, build your backends, build, whatever you need to solve that problem, however you need to do it, right? So we want to have this idea of aligned autonomy, right? Like you’re aligned with us in terms of yes, we’re all on the same page that we know what the problem is, we know what the solution is, but you totally have the autonomy to finish building out that solution however you need to. Does that make sense?

Dan Neumann: [12:55]  Yeah, I like that phrase aligned autonomy. One of the mindsets that I, I see frequently is, well as soon as we nail the database model, as soon as we nail the user experience, as soon as we nail the whatever my specialty is, then we can go be agile and we can iterate through the rest of it. And that’s, uh, an interesting mental trap that I see repeat itself over and over. And, and really the secret is no, they were like, we need to start with a different mindset where things are fluid. We don’t assume that we know this part specifically. And so bringing that design thinking in solving a problem in a particular way and then taking it to the team and and engaging the team’s, creative power in implementing something that solves that problem in the software. I guess I see that as a much more collaborative than as soon as my specialty gets deterministic than you can go be agile with the rest of the approach.

Chris Spagnuolo: [13:52] Yeah, no, I totally agree.

Dan Neumann: [13:58]  So how do we have, we’ve got design thinking clearly it’s not a thing that happens at the front and then we use water Scrum fall. We had an earlier podcast episode with Barry and Eric where he talked about water Scrum fall and trying to move away from that with a DevOps approach and so we don’t want it to be design thinking as a replacement for this water Scrumming. How do we maybe incorporate the design thinking into the overall delivery in addition to, you said the aligned autonomy with these parallel tracks. Are there some other ways to embrace a design thinking mindset?

Chris Spagnuolo: [14:44 ] Yeah, I think there are, uh, you know, and, and what I don’t, we talked about it before ready. Like we don’t want the this being an over the wall kind of thing, right? We want the design thinking mindset to kind of start to permeate everything we do. Right. And Scrum, you know, personally I think Scrum or Kanban are kind of like the perfect delivery mechanisms to mesh with design thinking. Um, and here’s why. Like, you know, if you’d go back to the origins of Scrum and think about like what they were trying to get to when they got to that last day and they did their demo and review, it wasn’t just to flash the new functionality up on the screen and be like, Hey, look what we built. The main idea of that demo was to get feedback right. And was to go back and take those features that didn’t quite do what they were supposed to do and take the feedback, iterate and incorporate that in. Right? Like that is design thinking at its core, right? It is. We built something, we tested it with the real end user, um, or we demoed it to the real end user and we got feedback from them and we went back and changed it. And what I see too often in a lot of Scrum teams is the demo is just a checkbox. We developed seven features this time. Here’s what they were, product owner signed off on. I’m good to go. Like that wasn’t the intent of the demo meeting ever, right? The intent was always to have stakeholders and users and people from the business looking at what you delivered and giving you feedback and letting you know yes or no. You hit the mark or you didn’t hit the mark. And the idea was to take that feedback and incorporate it. So, so I really think bringing design thinking back to that meeting would be super useful. Right? So, so that’s one instance. Another thing that I really love coaching teams and especially product owners to do is to build, um, kind of an input committee, right? And if you can get live customers or people in your organization who are actually going to use your software to sit on this kind of advisory committee, a customer advisory board or something like that, you can call it lots of different names. But in the end what it is, is getting, you know, eight to 10 people that you really feel like represent that end user, right? If there’s a certain persona you’re developing for, you know, the people that you empathize with at the very beginning of the design thinking process, bring them to the teams, right? And build these little advisory boards for every team that’s developing. So that advisory board can A help give you input when you’re building your stories and B, give you the feedback at the end of the iteration. So at the end of the iteration, I know I’ve got eight to 10 people who are really doing this job, who are really going to use this software, giving me that feedback, right? And you know, if you’re building an internal product, super easy to go grab those people for an hour a week and get them to participate. Externally you may have to build this remote meeting space where you can actually demo these things. But I’ve done this at all kinds of organizations where you know, we’ve done it with startups, I’ve done it with fortune 500s, I’ve done it with big utility companies that have lots of different types of customers they interact with. But having those customer boards giving you feedback into the process is priceless.

Dan Neumann: [17:53]  I think you touched on something that I want to amplify and you mentioned it a little bit earlier with empathize. We’re really trying to identify with a person or a small group of people, which is different than what I think of from use case. Use case We had actors, or we have this, this demographic where we’re appealing to a, you know, professional women age 35 to 45. It’s really hard to empathize with a group, but when you can sit down with a person, let’s say a consulting engineer who is using your software and you watch them struggle with something, you know, you realize, Oh wow, our, uh, our users aren’t stupid users who just need to be trained better. They have a real problem with what I’ve handed them and it’s not meeting their need. And it’s so much easier to empathize with a person or a persona than it is a group of people that’s really abstract.

Chris Spagnuolo: [18:47] Yeah, it is. And you know, I’m not, I’m not anti persona. I think there’s some good uses for them. I think they get abused. And I think there’s a lot of really crappy personas out there that are just, you know, a job title and some ridiculous thing about, you know, they like to eat pizza and their off time and everything else. I’m like, nobody cares about that. What do they do? Like what, what is their problem? Right. So I really like, um, personas that are based more on wants and needs and groups of people that coalesce around common wants and needs instead of job descriptions and stuff. Right. So, so I think those kinds of personas really help you focus in. Um, but I agree like getting to really know, even if it’s just one of your customers really well and understanding what they do. I remember, Oh God, it’s probably like 15 years ago now, we were doing some work for a department of transportation at a state level. Um, and we had quite a few users that, you know, we were building for. Um, but there was one user who just gave us such good, consistent feedback and invited us in to watch her work and everything else. And I remember the team, like it just crystallized with them. Like, wow we really know her? Right. And everything became what Catherine do that right. Is that, have Catherine would work? Is that how she would solve this problem? Is that how she would think about this? So just having that personal connection where they felt like they were building for somebody instead of just a nebulous as a user. Right. Or just, you know, as, uh, you know, made up persona. There was a real person behind this who they were felt like I’m building a personal product for. So having that was like super cool.

Dan Neumann: [20:23]  You mentioned the sprint review as a place where people can get feedback from these stakeholders or have an input committee where you’re engaging with these. And I view that as not just the domain of the Scrum product owner or if somebody in product, but really getting the whole development team to engage and empathize and have face to face time with these really key folks.

Chris Spagnuolo: [20:45] Oh yeah, absolutely. I mean, and when I’m about that meeting, you know, in my mind I’m seeing a room full of people, right? And it’s the entire development team plus your product owner, plus your Scrum Master and then all these other people giving you feedback. Um, and the more the better, right? Like we want that feedback. It’s what makes our products better, and it’s what makes us more engaged and who we’re building for.

Dan Neumann: [21:08]  Yeah. You get a lot of input and then you have the challenge of what to do with it, but it’s better than having too little input and making some false assumptions about, about how to go forward.

Chris Spagnuolo: [21:18] Yeah. That, that’s a great point. And you know, I hear a lot of people say that is, I’m going to give too much input now and I’m going to get too much feedback and what do I do with that? Um, but that’s your job as a product owner. Right. Um, it, it was probably, again, same timeframe as that DOT job about 15, 16 years ago. Um, I was working with a really big animation studio out on the west coast, and every day they do dailies, right. And, uh, they talk about what they had built out and what they had designed and how the story was moving along. And the director stands up at the front and he’s kind of leading the whole meeting. Um, and anybody in that auditorium can give feedback to that director. Right. But it’s that director who, who kind of holds the vision and understands where he’s going with a movie that’s got to take all the feedback and filter it through his vision and build it out. But that feedback’s valuable. I, you know, I saw him take quite a few notes from different people that I would have never expected to give feedback, gave him feedback and he legitimately took all of it and then looks at it and filters it. Right? So that’s the job of the product owner. And that’s why when people go, oh, product owner is that really a full time job. Yeah. If you’re doing it right and you’re getting that much feedback, it’s going to take you a while to process through it. So I think that’s a really key thing is get lots of feedback, but make sure there’s somebody who’s holding the vision and kind of focusing that feedback back into the iterative process.

Dan Neumann: [22:40]  Yeah. The, the delivery capacity is finite as is the capacity of everything is fine. And so you have to take all the good input and figure out what you’re going to take action on and take that to the team and in a gauge on the right valuable things and more importantly decide what isn’t the right thing to be focused on. And that’s where that agile principle of maximizing the amount of work not done is. It’s like, look, we have, it’s fine it so we can’t do this all and really let’s focus in on, on what’s most valuable. So yes, a hard job for the people filling the product owner role.

Chris Spagnuolo: [23:12] Yeah. And you know there’s that, there’s probably a whole other podcast talking about how to do that filtering, right. And it’s this whole idea of, OKRs that we’ve been talking about: objectives and key results and, and kind of using that as our big broad filter and how do we cascade those down to the team level. So every team has a filter and we talk about OKRs in the sense of they’re not just the, the traffic light that says go and here’s everything to work on. They’re also the stoplight that says, oh, and here are the things that we’re not working on because they don’t align with the or the vision that we’re trying to, to accomplish.

Dan Neumann: [23:47]  Yes. The really important, and we’ll look forward to something on OKRs and other tips for prioritizing backlogs in the future.

Chris Spagnuolo: [23:54] Yeah, we’ll definitely have to do that. That’s awesome.

Dan Neumann: [23:56]  So we talked about some of the background and some of the, the current challenges, the current ways to do design thinking with the parallel tracks and aligned autonomy and refining of the backlog. Where do you see design thinking? Maybe going next? Are some of the frontiers where we can apply design thinking that haven’t been done maybe as much as they should be at this point?

Chris Spagnuolo: [24:19] Yeah, what I’d really like to see and where I think it’s going to head, um, is really escaping the realm of product development. Um, and really getting into permeating business in general, right? Think about things at the organizational level. You know, anybody who works for any organization, um, you’re constantly coming up with, especially if you’re in a big enterprise, you know, new processes, right. Or, um, new internal ways of working. Um, it could be as simple as designing a new workspace, right? Um, all the things that impact the people that work for your organization. I think if we bring design thinking, uh, to the organizational level, I think we’d see a lot more, you know, engagement with employees, a lot happier employees, you know, better retention kind of things because we’re actually thinking about the problem we’re trying to solve, right. Instead of just putting out mindless processes and not thinking about, um, who’s the end user, right? Who’s the person we’re solving this for? What’s the real problem that they’re having? Um, and let’s prototype, right? Let’s try some things out on smaller subsets of our organization to see if this solves the problem before we implemented it organization-wide. So I’d really like to see design thinking kind of start to permeate all of the decisions we make instead of just product decisions.

Dan Neumann: [25:38]  A couple of things that came to mind as you were describing areas to apply it. Yeah. The, the workspace. There’s so much buzz around or there was actually around open spaces and collaborative spaces. And then some people started going, oh gosh, you know, we actually we’re getting some negative results from being too open and expecting people to do deep knowledge work in this cacophony of noise where they can’t get any quiet time to think. And so really taking the empathy part and not just following maybe some of the industry trends to, you know, blow up all the cube walls and make it all open space and let’s put in rows of things and a keg and we’ll have an agile team, but really thinking how do we, how do we create opportunities to collaborate? How do we create opportunities for deep thinking, quiet time, you know, really being more critical about the way we go through through that thing. That’s one of those scenarios where design thinking could, could fit. I would think.

Chris Spagnuolo: [26:36] I, you know, that, that’s an awesome example and, and it’s really funny because it really hits close to home with me. Um, so about 10 years ago or so, I was a product director of product, um, at an organization and we were doing this whole move towards agile and I’d done some agile coaching, with the org, and we had talked about changing the office space. Right? Um, and, and I made the mistake of not thinking about everybody else and empathizing and I was like, that worked great. You know, like totally fits with the way I would want to work. You know, I’m very chaotic. I love noise. The noisy, crazy environment totally works for me. Right. Um, and sold it up the chain where everybody was like, yeah, this is great. You know, we’ll be super creative and super collaborative. When we built this really collaborative workspace, um, and it was a team of about 40 engineers that we stuck into it and easily half, if not more of them, ended up having private conversations with me. This sucks. We really hate this. You know, like, I am an introvert. I don’t like being watched all day. This is uncomfortable. I have no private space to go think or whatever. We got like all kinds of interesting feedback and I kind of looked at that and you know, it was one of those spark moments of Oh my God, we never prototype this. We didn’t see if it actually solved the problem for everybody and I didn’t empathize. Right. Um, so that’s a great example. Organizationally, stop and empathize and think about everybody else who’s out there. You know, there are tons of people with different problems that they’re trying to solve. Different personality types, right? If we did personas on all of those developers instead of saying, Oh, engineers, they love open workspaces or whatever. Or put all the engineers into one persona, we would have been way off base. Right. What would have been better is to have personas based on, you know, maybe you know, the personality types or something like that where we can group them and say, Hey, this type of personality is really going to hate an open floor plan or whatever. Um, so yeah, I think bringing design thinking to those kinds of decisions would be super useful.

Dan Neumann: [28:37]  Yeah. The other place, we’re recording this during the first quarter of the year. So it’s annual review time at a lot of places, whether they ended their fiscal year, December 31 or um, you know, at the end of March it’s annual review time. And HR is another place where I think there’s a great opportunity to really apply some design thinking. Why, why are we doing annual reviews? What are people thinking if we do annual reviews and salary adjustments hand in hand with each other, does it allow for the safety of this feedback or, or not? And I know there’s some companies that are really exploring the annual review process and the exploring alternatives. And that’s one that I think is, is kind of timely just because of the way we’re recording this during the calendar.

Chris Spagnuolo: [29:16] Yeah. That, that is another good spot. And I have done some design thinking work with HR groups and, and they seem to really gravitate towards it, right? Because their whole job is to understand people and to solve problems for people in the organization, you know, if they have a good HR department or people department. Um, so yeah, I think that’s an awesome place to start with with design thinking and spreading it through your org.

Dan Neumann: [29:39]  Oh yeah. I know. I often go they’re people not resources and uh, yeah, right in there, HR, it’s baked right into the, uh, the name. So yeah. Good point. The people department. Human first humans department.

Chris Spagnuolo: [29:55] Yeah. Good point.

Dan Neumann: [29:57]  Wow. I haven’t used resources to refer to people in a long time and I just broke that streak.

Chris Spagnuolo: [30:03] Yeah, I know. I try very hard not to.

Dan Neumann: [30:07]  So design thinking, you know, some background, some, some ways to get started with it. We’ll put the five phases, empathize, define, ideate, prototype and test. And yes, it’s not a waterfall per se. You can bounce back and forth between those. So really appreciate you sharing your thoughts on design thinking today.

Chris Spagnuolo: [30:25] Yeah, no problem. This was great. Thanks Dan.

Dan Neumann: [30:27]  One of our regular segments is just a little bit about what people are reading or incorporating from their daily life as part of their, uh, their knowledge journey. And I’m curious what’s on Chris’s list of, of things you’re either reading or bringing into your life these days?

Chris Spagnuolo: [30:44] Oh, good question. Um, I have not been doing a lot of business reading lately. I am super passionate about music and guitar playing, so I’ve been doing lots of reading about new guitar styles and how to play better. Um, but I’ve also been reading this brand new book called the Birth of Loud, um, and it’s about, uh, Leo Fender and a holy crap. I am completely blanking. See podcast makes me forget things. Les Paul, sorry from Gibson. And it’s the whole story about how they innovated their way to the electric guitars that we have now. And they were very different personality types. Like Fender was this engineer guy, um, who came at it very much from an electronics point of view. And Les Paul wasn’t really big on electric guitars to start with, but he was a musician who wanted to get that crisp, clean sound out of his guitar. Um, and this friendly rivalry that they had with each other to keep innovating was really interesting. So, so reading some of that, um, and thinking, you know, relating that back to the design thinking thing we’re talking about, um, they came at it from different perspectives, but they were solving a similar problem. Right. And they solve the problems in great ways. Obviously they made classic guitars that, that everybody uses. Um, so, so that was, that’s been really interesting. I’m, I’m midway through that and might have more to report on. Um, but other things in guitar and music that’s really been, um, stimulating me is this idea of improvisation and learning to do improv with other people that you’re playing with is really interesting. And, and trying to understand how to apply that in a, in a business sense is really kinda cool. And I know there’s a lot of classes on doing improv in business and some of them are kind of corny or whatever, but, but I think that there is something to it about, um, always doing the plussing up and making your partner look as best as you can. So, so those of things are impacting me a lot lately.

Dan Neumann: [32:41]  Yeah. The, the yes. And or the plussing up as you described, you know, learning to build on somebody else’s idea as opposed to having the battle of the ideas. It can be really helpful mindset shift for folks. So I’m going to have to check out the, uh, the Birth of Loud. I went to the, uh, Hall of fame, the Rock and Roll Hall of fame in Cleveland and they have, you know, some of the early artifacts from a, either Les Paul and/or Fender, I forget which, um, it’s really interesting to learn about the history of the electric guitar. So

Chris Spagnuolo: [33:14] Yeah, it’s really cool. It was a, when I was a kid in my late teens, early twenties a friend of mine worked for a concert promoter and I got to meet Les Paul at one of his birthday parties and he was a phenomenal guy. The friendliest guy I’ve ever met, and like reading his backstory now, I’m like, wow, this totally makes sense about who he is. It’s kind of cool.

Dan Neumann: [33:34]  Yeah, it’s neat to learn about people who have excelled in their craft and takes take lessons or get new insights from those. Well, thank you again, Chris. Appreciate you joining me and we’ll look forward to a future episode then on some of the backlog refinement topics we alluded to earlier. Sounds great.

Chris Spagnuolo: [33:51] Thanks, Dan. This was awesome.

Outro: [33:55] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date