Podcast
In this episode of Get Reworked, Andrew Lindsay, global head of enterprise design at KraftHeinz, joins me to discuss why that lack of a clear definition is in part why design thinking has been called into question of late, and advocates for why it's more important than ever.
Listen: Get Reworked Full Episode List
"In the absence of a design practice and design strategist and user researchers, engineers and product teams and business stakeholders are the hippo — the highest paid person's opinion — who drive those types of decisions. And so having that third-party perspective, that nonpartisan view coming from the design team really helps the teams take a step back, lead with data and insights, and then make more informed decisions," Andrew said.
Highlights of the conversation include:
- What critics of design thinking got right and where they missed the mark.
- Why Andrew views design thinking is one form of business development.
- What goes into choosing which problem to solve when with design thinking.
Have a suggestion, comment or topic for a future episode? Drop us a line at [email protected].
Tune-in Here
 |  |
Show Notes
- MIT Technology Review: Design Thinking Was Supposed to Fix the World. Where Did It Go Wrong?
- Watch Andrew's interview on Three Dots
Show Transcript
Note: This conversation has been edited for clarity.
Andrew Lindsay: Design thinking isn't really anything, right? Design thinking could be a workshop. It could be Post -it notes. It could be somebody writing on a whiteboard. And that's, think, where we come back to the original provocation that we kicked off with today, which is it became so generic, everybody thought they could do it. And when everybody thinks they can do something, it doesn't really mean or equate to much of anything at the end of the day. A well -structured research program, which can be informed by design thinking types of activities is something that requires a specialized skill set.
Siobhan Fagan: My guest today is Andrew Lindsay. Andrew is the global head of enterprise design at Kraft Heinz and he joins us today to defend the practice of design thinking.
That quote of his gets to the heart of the matter: the post-it notes, the whiteboard sessions, the workshops — people see these tools of the practice and assume that’s all that goes into it. But as we’ll hear from Andrew, design thinking goes much deeper — and involves far more rigorous research — before you ever get to the post-it notes.
So let’s bring Andrew on to share his experience.
Why Design Thinking Still Has a Place in the Corporate World
Welcome to the show, Andrew! To start off, can you share your background and why you want to push back on some of the criticism surrounding design thinking?
Andrew: I'm a lifelong designer of many different stripes and I have been part of the corporate world for applying design and design thinking for 15 or so years. And so I've seen it go through a number of different phases and, you know, different understandings at a variety of levels from corporate sponsors down to the functional teams who are tasked with bringing it to life. And so one of the reasons why I've become a little bit frustrated with the general discourse around it is because it's not one thing and it's usually in the articles that you mentioned presented in a very one dimensional manner. The reason for that is because of how practitioners have brought it to the table and commoditized it, when in actuality, it can shape and form in a variety of different ways in order to solve a vast range of different problems and issues that a business or a client are facing. And so for us to just make blanket statements that it's no longer valuable or it doesn't have a place in the corporate world anymore is defeatist.
Siobhan: I admit that after you raised this topic, I went back and re-read the MIT Tech Review article about design thinking. And it did seem like a very specific application of design thinking that they were taking on — it was about the consultants swooping in and going through this design thinking practice. Post-it notes came up many times throughout the article and the same team just kind of swoops out without actually doing solutions. And I think in your role, you're obviously inside an organization. You're applying this. So can you talk a little bit about the differences of what that is when it's you inside a business applying design thinking as opposed to a consultancy swooping in and saving the day?
Andrew: I want to, course, make sure that we're respectfully acknowledging the amazing work and publications that come out of MIT and Business Insider. So not to start a war here, but more in the spirit of collective collaborative and thought sharing.
Having said that, there is a pretty significant difference in how an outside company, regardless of who they are, would come in for a short engagement with a larger enterprise to help begin the identification of problems to solve versus an in-house team who's responsible for ultimately bringing those to fruition, right?
Good, well-seasoned firms like an IDEO are going to make sure we start identifying those problems, working through the ideation phases, begin to apply those to different sectors and teams within the business so that we can finish the engagement with a clearly defined set of requirements and ideally roadmaps that are going to allow us to understand what we need to do to bring this to life.
I think what has tarnished this concept of design thinking a little — and this is where I start to bristle a bit — is it's not just design thinking where we see this shortcoming, right? It's in many different types of consultant-based engagements. They'll go in and say, 'This is what you need to do in order to get better.' And then the internal teams are responsible for actually figuring out what that means and how to bring it to life. A real, true partnership is one which goes from the very beginning all the way through the execution and deployment of that solution. And that's where there's significant benefit for having in-house teams, because we have skin in the game throughout every stage of the life cycle, so that up to and beyond deployment, we're continuously shepherding that solution or pushing that solution forward. The sort of swooping in and solving and then ducking out is problematic beyond this design thinking scope.
Who Is Part of a Design Thinking Team?
Siobhan: To ground this a little bit, in your years of practice, you said you've been doing this for 15 years within organizations — what sort of team would you have around you when you are executing on these projects?
Andrew: So we have sort of the trifecta that I always like to refer to engineering product and design are the key partners that we would consider as our functional teams. We would also obviously have business stakeholders or consumers or customers involved in those discussions as well, depending on the nature of the business and problems that we're attempting to solve from a design standpoint that's really big-d Design: researchers, design strategists, user experience designers, customer experience designers, service designers and many different dimensions within that space because obviously the design field is one which has a lot of different disciplines that are contained within it.
And as we build out teams and practices within organizations, whether they're small or large, we want to make sure that that design field is fully represented so we can bring holistic, thoroughly considered end-to-end solutions to the table, as opposed to just kind of spot checking features and functionality from a product standpoint. Having engineering involved in the conversations is critical because obviously we want to make sure that these solutions that we're thinking about are capable of actually being built and deployed at scale.
And then product, of course, to make sure that we're creating this from an ecosystem standpoint. Again, there are very few instances that a company would find itself in where it makes sense to do something in isolation, outside of the context of the broader digital ecosystem that they're otherwise developing or responsible for accommodating. That sort of trifecta of teams are gonna be the ones who measure success as we go from one end of the spectrum to the other. And then amassing the inputs from the stakeholders and our customers and consumers to inform each of the phases of the product development lifecycle, whether it's ingesting insights to help with ideation, leveraging the voice of our consumer as we're going through testing and iterations, as we get closer to deployment, and then post-deployment measuring success.
Design Thinking as Antidote to HIPPO Decision Making
Siobhan: If we're looking at the employee as the customer, it just makes me think, who are you replacing? Who did this role before? Or did this role not exist in general? Did they just kind of throw out solutions and be like, 'Deal with it'?
Conference
Sep
16
HR Tech Conference Las Vegas 2025
Register
Conference
Oct
27
Gartner HR Symposium/Xpo Orlando 2025
Register
Andrew: From what I've personally experienced, in the absence of a design practice and design strategist and user researchers, engineers and product teams and business stakeholders are the HIPPO — the highest paid person's opinion — who drive those types of decisions. And so having that third-party perspective, that nonpartisan view coming from the design team really helps the teams take a step back, lead with data and insights, and then make more informed decisions. as opposed to, 'I think we should do this because I talked to this person in the hallway the other day.' And that takes us back to the whole purpose and benefit of going through research, which is ultimately design thinking, which is ultimately one form of business development.
If we're looking for new opportunities that the business needs to tackle or identify so that we can become more streamlined or more optimized or more competitive or whatever it is, we need to first start by understanding the problem in its entirety. That's research. And one method or model of conducting that research is design thinking.
But design thinking isn't really anything, right? Design thinking could be a workshop. It could be Post-it notes. It could be somebody writing on a whiteboard. And that's where we come back to the original provocation that we kicked off with today, which is it became so generic, everybody thought they could do it. And when everybody thinks they can do something, it doesn't really mean or equate to much of anything at the end of the day.
A well-structured research program, which can be informed by design thinking-types of activities is something that requires a specialized skill set. Just as much as a business analyst is a specialized skill set, a sales analyst is a specialized skill set, a project manager and a program manager and so on.
What Design Thinking Looks Like in Practice
Siobhan: I would love for you to walk us through an example from any of your roles, if you could, of a design thinking process that you went through that led to a final product. Could you share an example of that?
Andrew: Absolutely. Just before the pandemic, I started a new role. I was brought on as the head of design and asked to oversee one of our flagship programs, which revolved around a comprehensive overhaul of the customer experience.
And so we were working with one of the big name vendors at the time who came in and did an amazing job at everything that we're talking about here. And this is one of the reasons why I remain a firm believer in the power of what we're talking about as design thinking today. Because we started from the very beginning, with our internal teams, aligning across the board, C-level executives, functional, mid-level sort product owners, and then boots on the ground, like builders and analysts and such.
It was the first time we all sat together in a room to talk about the one problem collectively. Everybody was claiming, 'I don't think we need this meeting, I know what we're talking about. I've got a good idea of what this whole thing is.' When we finished that session, which was an all day session on site, almost everybody in one form or another came around and said, 'That was amazing. We've never actually done that before. I have a better understanding of why we haven't been able to do this in the past.'
Just having that initial point of alignment allows us to mitigate the risk that come with even a one or two degree difference in collective understanding. Because if we have that small of a divide about how we're framing up this problem, near-term it might not be so much of an issue. But longer term, that two degrees is going to turn into a pretty significant divergence in our march towards what had previously been a collective roadmap and plan.
After that initial alignment session, we get into unpacking what we actually need to do to get frame out this problem as a whole in the eyes of our customers. So going and taking that same model from an internal standpoint and getting the external perspective. When we have the external perspective, who in that instance were our paying customers, that was the definitive inflection point where we were able to say, 'All right, it doesn't matter what we think. It doesn't matter what our partner team who has come in to help us with these things, really what matters is what our customers think. And here's what they're saying. Statement A, statement B, testimonial one, testimonial two.' And that's the data that drives the decisions, or at least the recommendations.
When we have clearly-defined data that is supporting the recommendations we bring to the table, that is when we say now we're going to go in and test these concepts. It's very difficult for anyone to push back based on their opinions because in the absence of that data, everyone's going to say, 'No, I don't think we should do it like that. Here's what I would like to test or here's what I think is going to work the best.' Where we're all just pushing for preference of opinion. So taking that data and then going back with our customers, testing, iterating, circling through the continuous optimization process, which again, that's all part of the design thinking model, allows us to continuously refine down into the best common solution that's gonna address the problems that in that instance, were presenting to a fairly broad cross-section of customers.
So then when we get into the deployment phase. after we've gone through user testing and the different iterations, deploying that into actual production, we're still going through and listening and watching and seeing how that solution has actually hit the mark. And if it hasn't, which oftentimes after the first deployment, it's not going to be a hundred percent. We go back into that product development life cycle and continuously iterate again.
That listening, processing and aggregation of data and insights to inform the actions that we take, it's really all the design thinking process at the end of the day. And so if we're talking about design thinking as a point of frustration, maybe we say we're sick of the term design thinking, and I could fully get behind that. It's a commodity, it's a buzzword.
AI and GenAI is turning into the same thing, right? Everybody loved to talk about it. It was the first thing that people opened up meetings with. It was the last thing people mentioned when closing out meetings. And now it's like, what does it actually mean? What is that actually gonna do and deliver and bring to our business? Those are the right questions to be asking.
If that's what we're talking about here in terms of the design thinking pushback, then I'm 100% aligned with that. If what we're talking about design thinking without actual actionable next steps and recommendations, I'm 100% aligned with that as well.
However, I think that that those two things are not faithfully representative of what design thinking actually is. I go back to design thinking being more of a really hyper-effective business development framework, which is powered through teams that are generally situated under the design spectrum.
How Much Optimization Is Too Much Optimization?
Siobhan: When you were talking about the process — I love that it's iterative, I love that you're looking to continuously optimize, but at what point do you say, OK, we're done? Do you reach that point?
Andrew: It's a million dollar question. And I think it depends. It depends on the needs of the business, the goals and objectives that we've established from the beginning.
There's a risk if we're saying, let's just continuously iterate this product through ad infinitum, right? Because we have to make sure that we have clearly defined goals and objectives so that we can understand what we're driving towards. Once those goals and objectives are hit, is that the problem that's been solved? If that problem has been solved, then make sure we're accounting for all of the other problems that the business is facing, right?
And if it's not solved, then sure, continue to iterate. But we need to make sure that we're creating a robust portfolio of solutions. And one of the things that we see product teams everywhere get lost in is, 'OK, this is my product. I'm responsible for shepherding this product. And if I don't have this product anymore, then I don't have a place in this company anymore either.' As opposed to saying 'I, as a product owner, I, as an engineer, I, as a designer am responsible for the strategic enhancements and maturation and development of this business throughout all the different layers and touch points across the spectrum.' And so that might be focused on this one solution today, next year, and in successive years, it's going to be many different things.
Siobhan: One of the benefits is you are taking a broader business-wide perspective. Even if you're solving a specific problem, you're looking at it within a bigger framework of all of these other tasks, all of these other things that you've delivered, correct?
Andrew: I think we have to, right? That's where one of the greatest benefits of having a role like a service designer comes in is because we have a clear line of sight into the broader ecosystem, whether that's the digital ecosystem or more of the analog employee touch points that are manual and in-person, mapped out as a journey so we can create a connective narrative thread throughout every single meaningful point of engagement.
Identifying Which Problems to Solve
Siobhan: I imagine one of the hardest problems would be knowing which problem to solve. How do you know you're solving the right problem for that moment?
Andrew: I love it. Another million dollar question. How do we know? That's where we lean in hard on the way that we go through that business development framework, right? So the right problems to be solved are gonna be informed by a variety of different data points.
What’s the potential value capture or impact that it's going to drive for the business? Is it contributing to top-line growth or bottom-line efficiencies? What are the greatest challenges that we're facing both this year and heading into next and beyond? So that we can have more of a multi-layered set of considerations that are driving the decisioning around all of those things.
It's not a simple, single point consideration. We have to make sure that we're taking in all of the nuances and complexities of the business and then involving cross-functional teams in the process as well. Because even though we think we have a clear line of sight into the broader ecosystem and we're partnering with one part of the business, we have to make sure that other business stakeholders are contributing to the conversation so that we can make sure that that ecosystem is fully tied up and that that sort of prioritization and jockeying for preference is thoroughly considered as well.
And again, these aren't easy things. Back to the design thinking provocation: it was seen as, 'OK, this framework is going to be easy. We're going to do this workshop and then we're going to get to the other side of it in a much better way. Here's some Post -it notes and a Sharpie and let's go.'
It's hard work. It's really hard work. And oftentimes when I'll kick off a design thinking workshop or particularly when we're trying to build out like more of the information architecture or detailed analysis of one part of the customer journey or similar, giving the teams an understanding like this is going to be a fairly arduous three hours. It's not going to be fun, but it's necessary work in order for us to get to the other side so we can get to that actionable list of items or requirements that will inform the roadmap that we create to take to the next stage.
Siobhan: I'm glad that you raised that last point about the complexity and the hard work, because I think that that was one of the criticisms that came up multiple times was that, it's just a linear exercise, sort of a checkbox thing that you go through and then, boop, boop, you're done. And you're just saying, nope, come follow me at my job.
Is there anything that we didn't cover that you would like to speak to or anything that you're excited about right now in your specific role that you would want to share with the audience?
The Need for Design Thinking Today
Andrew: I think we covered some great ground here. The last thing I guess I'll leave with is design thinking as we've discussed it today is more important than ever as far as I'm concerned. If we look back to the early aughts when digital was kicking off and at a very rapid pace, what we saw was a digital world that was envisioned primarily by engineers.
And that looked and felt very different than the world that we interact with today, which is heavily informed by a partnership between designers and engineers. This whole concept that brought to our collective imagination through Apple has now been adopted by everyone — topics like usability and form and function — and is one which we're seeing play out in real-time as it relates to the conversations of AI and GenAI.
It first came into our collective cultural mindset after ChatGPT's big release. It's cool, it's this amazing new technology. As we've become familiar with what it is and understanding, OK, that's tech, but how does it apply to me as an individual in my daily life? Is it really just a search box with suggested prompts? Or is it going to become more seamlessly integrated throughout and across every single device that I have?
We're seeing some really exciting applications of that. And that's where this concept of experience and design plays an outsized role in ensuring that we capitalize on this new technology and set of capabilities in as many ways as we possibly can. And that's the design component, but it's also getting down to the heart of the matter and saying, 'If I have a photo, what is the real benefit that something like AI or generative AI can bring to that application and to the consumer's experience within that application in that point in time?'
In order for us to do that or answer that question, we have to understand how did they get into the application? Why did they get into the application? What are they doing there? What are their intentions? Are they sharing information? Are they looking to edit pictures? All of those things, right? And that again takes us back to just this sort business development, product development framework, is generically framed up as design thinking, but it's so many other things than that. More importantly, if we don't ask those questions, regardless of what we call it, we're just gonna be chasing tech for the sake of tech.
Siobhan: I think that's a great place to end. You gave a very convincing argument in favor of design thinking. I appreciate you joining me today, Andrew. And I look forward to chatting with you again soon.
Andrew: Cool, this has been awesome, Siobhan. Thank you so much, I really appreciate the time.
Siobhan: If you have a suggestion or a topic for a future conversation, I'm all ears. Please drop me a line at [email protected]. Additionally, if you liked what you heard, please share Get Reworked with anyone you think might benefit from these types of conversations — word of mouth marketing is the best marketing anyone could ask for. You can find more coverage of related topics on reworked.co. Thank you again for exploring the revolution of work with me, and I'll see you next time.
