Andy Budd, design leader, start-up advisor & coach, talks to Maze about the dimensions of product decision-making—the power dynamics at play, how to prioritize features in a democratic way, and how to grow the influence of design in the organization.
The Optimal Path is a podcast about product decision-making from the team at Maze. Each episode brings in a product expert and looks at the stories, ideas, and frameworks they use to achieve better product decision-making—and how you can do the same.
Liked what you heard in this episode? Read Andy's full article over on our blog, In The Loop.
You can follow Andy on Twitter (@andybudd) or check out his website.
Resources mentioned:
Follow Maze on social media:
To get notified when new episodes come out, subscribe at maze.co/podcast. See you next time!
Ash Oliver:
Welcome to The Optimal Path, a podcast about product decision-making brought to you by Maze. I'm your host, Ash Oliver, UX designer and design advocate. Great products are the result of great decisions, decisions that deliver value for customers and the organization. In this podcast, you'll hear from designers, product managers, and researchers about the ideas informing decision-making across all aspects of product development.
Today I'm joined by Andy Budd. Andy is a well known design leader, conference speaker, advisor, and coach. He founded Clearleft, a trailblazing and influential UX agency in Europe and has been responsible for many conferences, such as UX London, dConstruct, and Leading Design. Andy, I'm really excited about our chat today. Thanks so much for being here.
Andy Budd:
Oh, Ash, look, it's my pleasure. I'm really, really excited to chat to you and to chat to your audience about one of my favorite topics. So it's really good stuff.
Ash Oliver:
Now, Andy, you've seen so many teams in this process and have been at the heart of a lot of different scenarios for what we're going to be talking about, which is product decision-making. So I felt like it might be a good place to start by having you paint a picture of what you consider the dimensions of product decision-making to be.
Andy Budd:
I think the dimensions will probably emerge out of what I'm going to say, but I think actually what might be more useful is to talk about how I see it maturing in teams. And so, like you say, I've worked with a lot of early-stage startups. I do a lot of startup advising, startup mentoring. And what typically happens is that at the start the founder will have a really strong vision for what they want to build. They've almost got it pictured in their head. And so the initial stages of the product basically are trying to get out of their head and into code and into design what they had visioned. Now, if you have a founder that's got a great product sense, maybe the thing that they get out in that first product, that first minimum viable product, it's 80% there.
Andy Budd:
If however, you come from more of a business background, it can take a lot longer. But at some stage, the founder will have depleted all of the obvious stuff out of their head, all the low hanging fruit, and then they start to think about, what else do we need? And the first place they tend to go to is, well, let's listen to customers, the customers will tell us what we want to build, and we'll go ahead and implement what they tell us. And so that already starts to become problematic because customers sometimes don't know what they want to have in the product. As humans, we are very bad at judging future needs and future behaviors. And so quite often, when somebody asks us, "Well, what should we build?" They'll often try and be helpful, but they'll recommend things that actually once they get built, don't get used.
Andy Budd:
So first of all, you've got this flow of information, and a lot of founders, because we've been taught to trust our customers, just build what the customer says. We also have a similar problem, which is if you are in a company that's very sales driven, often the sales people will be trying to close a deal. The people on the other end of the phone will then say, "Look, we can't buy this product because of X, Y, Z." And they come out with a whole bunch of features, which then gets thrown into the product backlog. "Well, we've got to have these features because five customers this week have told me they won't sign up until I have X, Y, Z." And so suddenly all these new features start to accrete. And every feature is considered to be super important and then suddenly product management comes into the mix and they've got a bunch of feelings, design and engineering have a bunch of feelings.
Andy Budd:
So suddenly backlogs quickly get overwhelming and companies really struggle to decide which of these things to prioritize. And so I think the first way that people end up prioritizing that is basically delivering what the founder wants. Secondly, prioritizing on what the community is saying or what the sales team is saying. However, what then typically happens is they implement the features that the sales team requested, but weirdly, those customers find other problems that are the reason why they don't want to sign up. And maybe actually the things that the customers are saying, they're not saying it because that's really why they're not signing up, they're just trying to find some reason, any reason, to get this annoying salesperson off the line. So the next phase is people start throwing features at the wall to see what sticks. There's very little structure. There's very little thought about what goes on.
Andy Budd:
We just throw, we throw, we throw more stuff there and hopefully some of it works. A lot of this is defended by the idea of build, measure, learn. So let's just deliver our best hunches, we throw them at the wall, we'll put some measurements in place and we will learn from our experiments. Unfortunately, a lot of early companies don't have the tooling to learn from their experiments, and actually, learning from new experiments often means taking features out. It means trying a feature and if it doesn't work, removing it. But removing a feature costs dev cycles. So basically you get to this point where features accrete, lots of them aren't being used, or worse, they're being used by a very, very small number of customers, but removing them is going to cause all kinds of problems, and then basically you just end up with this massive Frankenstein of a product that isn't well considered.
Andy Budd:
And I think us as designers and product people, we've seen this story play out time and time again. Now, there are lots of frameworks out there for you to judge and prioritize features. And I think frameworks are really interesting. One of the most common, simple product prioritization tools is called ICE. ICE stands for impact, confidence, and ease of implementation. And it's a really simple thing. You look at a feature that comes in and you go, okay, on a scale of one to 10, how impactful do we think this is going to be? Okay, well, we think it's going to be seven. We think it's going to be big impact.
Andy Budd:
How confident are we about this feature? Oh, well, actually maybe only a four out of 10. How easy is going to be to implement? Well, actually it's going to be really difficult. It's going to be a one out of 10. And so what you typically do is you go through all of your backlog, you rate the features on these three scales and you multiply them or add them together and you get a stack ranking that says, "Actually this feature at the top is high impact, we've got high confidence, and it's super easy to implement." In the middle you get a bunch of average things or maybe something's really high confidence but low impact, or vice versa, and then at the bottom, all of the low impact things filter out. And using something like the ICE framework is often the first formalized tool that product teams start to implement.
Andy Budd:
But there are lots of other tools as well. The Eisenhower framework is a very common framework for prioritizing. It's very, very similar to the ICE tool. I've used a tool called Divide the Dollar, you've got engineering teams that play planning poker. I don't think there's any one process to rule them all, but typically people will start with these fairly simple prioritization metrics. And then obviously as the company grows in sophistication, you'll hire more senior product people, more senior product managers, heads of product, and hopefully, the prioritization process will slowly mature into something a little bit more complex and a little bit more focused on what you and your business is trying to deliver, and it might be based on a bunch of important KPIs.
Andy Budd:
You might be trying to find leading indicators versus lagging indicators. And some of the classic leading indicators are things like "how often people come back to the site." Okay, well, people have onboarded. Sign ups are often a really, really poor measure, but if you look at engagement levels and if people are coming back time and time again, you can be pretty sure that these people are going to convert eventually into long term customers that can stick around for a while. So there's just lots of techniques that you start to get more sophisticated over the time, but initially it's throwing things against the wall, some kind of stack and rank, and then looking at a whole range of different factors around KPIs. Usually these are the levels of maturity you go through.
Ash Oliver:
That's a really great snapshot of those traversing that land, because it does change course. As soon as you get started, then there's more than just, as you were describing, the founders initial input, and then you start to have all of these other inputs. And it sounds like from what you were describing there's the combination of the analytics side, the intuition side, and then there's the feedback from customers that you were talking about. How have you seen teams balance those aspects as the grounds are shape shifting and they're growing? Is there a triangulation there of those things that help teams be able to make better decisions?
Andy Budd:
I think, again, it gets quite complicated because generally there are big power dynamics at place. So in the early stages, if you're a lowly designer or researcher or tech or product person, you often lack the ability to challenge the backlog or where features are coming from. So often in the early days, it's really, really difficult when you are constantly being thrown a slew of new features to even have that conversation around prioritization because it tends to be a little bit chaotic and it's just like, "Oh, well, we had this conversation today. The CEO or the Head of Sales had this conversation, now this thing is the most important." And then a week later, a different conversation happens and this is the most important thing. And so the early stages are very, very chaotic, very, very driven by the power dynamics in the organization.
Andy Budd:
Ideally, as the company matures and as the company realizes that those features that are being thrown at the wall actually have a relatively low hit rate, and as the company grows and matures, you hire more experienced people that have worked at larger companies, you start to bring in more rigor, and it becomes slightly more balanced. There's still a negotiation, and the sales team and the marketing team and the engineering team tend to have more status and power in organizations than the research and design team. But slowly, design teams build out their research capabilities. They often initially focus on research to be slightly more summative, like looking at how the product is currently performing, and often it starts as a bit more of a QA type function. But as it gets more sophisticated, it starts to look earlier and earlier in the process and actually start to deploy deeper research, more ethnographic type research to understand problems, understand user needs, et cetera, et cetera, and basically discover problems.
Andy Budd:
And so I think research in general, as it matures, it becomes a great tool for problem discovery. And if you are good at discovering problems, and if you then get better not only discovering those problems but sizing them, then you start to see design and research start putting more things on the backlog. And so the balance starts to go from this is just leadership driven feature factory to you start seeing more opportunities come up based on the formative exploratory research that the design teams do. But there's still often an imbalance. Then what happens is you start to get this really, really interesting psychology whereby people, the leadership team, if they're just basing their decisions initially on gut instinct and those gut instinct decisions aren't moving the metrics anywhere near how they thought they would be moved, the leadership team starts to get quite unsure of its gut feel.
Andy Budd:
It starts being overly analytical, to some extent, of where they put their money, what they build next, and actually become expecting on research not just to find problems but to prove beyond any doubt that that is the problem they should be investing in. And unfortunately, research tends to be pretty bad at saying 100% whether something will be the right solution. It's really, really good at finding problems. It's really good at getting a rough idea of whether this is a solution that would meet a market need, but it rarely, in my experience, gives 100% guarantee to founders and business people that you will get this scale of return in return. And so you very, very quickly move from no research to an over reliance on metrics, data, and research and companies very, very quickly get bogged down in not being willing to make any hunch decisions because everything has to be validated before they move ahead.
Andy Budd:
And that's almost as bad as everything's being thrown against the wall. And so I tend to find that there's this really interesting sweet spot in the maturity of companies that sadly I don't think lasts for long enough. I think what tends to happen is people go from reactive to build a big research team. And there's a spot in the middle of one or two researchers, three or four researchers where they're doing just enough research, where they're finding problems, whether they're figuring out just the right size of the problems, where they've got enough credibility that they can get those problems on the roadmap and get them prioritized, but they're not being used as a tool to guarantee that every single solution will be the right solution. And I would like to see more research teams stretch that beautiful sweet spot out for longer, because I think you can be really, really highly efficient, capital efficient, efficient with your design work, efficient with your release cycle if you stay in that space between the two for longer.
Ash Oliver:
So much to unpack in that. That is brilliant. Even thinking about that inflection point where the research comes in as a proxy to solve for that psychology that you were saying, that untrusting or no confidence within your gut and then leans way too far in the other direction where it's now becoming a risk adverse engine to make sure that the decisions that are being made are bulletproof, which is not accomplishable. I'm wondering if you can maybe break down some of the tactics that could be used there in that sweet spot. Are there characteristics of teams that you've observed that do this really well?
Andy Budd:
Again, it's a tricky one. I really like product teams where research is heavily embedded in the product team and in the design team. I think things start to get naturally bureaucratic when you have a separate research team going out and doing its own self-directed research work that then gets captured in some kind of silo and not necessarily shared with the designers. Design research very, very quickly ends up becoming almost like market research. The role becomes writing papers, writing reports, writing documents rather than a dialogue with the design team to go, "Okay, well, what are you struggling with? What don't you understand? What behaviors haven't you got your head around? Where do you think the opportunities lie? Let's sit down and let's write a really, really well considered research brief so we can go out and we can help answer those questions."
Andy Budd:
So I think having a really, really tight relationship with design and research, making sure that research is acting maybe not entirely independently, but serving the needs to explain those research questions, you're much more likely to get actionable design research and actionable insights. I think also, at the same time, I want designers to be participants in the research as also every other executive. Again, if you have a standalone research team that is just going off independently doing research and presenting it back, the people who are consuming the research haven't really felt the pain points. It's very, very different to go to an interview or three or four interviews and see the same thing come up again and again, and that bringing some internal insight to the people, the product managers, the designers who are making that decision, than being completely arms length and reading a bunch of decks, which this item becomes just a bullet point item.
Andy Budd:
And so I think in the space of communicating research, it's important that research is communicated, but that research is a store of information that was actually built up collaboratively through the participation of that research. And so the research documentation just becomes something that the product managers and designers and engineers refer back to. It's like, "Oh, we went on that research field trip, we learned that thing, what was it again? Okay. I'll grab the research documentation." Rather than just going, "Well, we are too busy and important to go on the research field trips. We're just going to read the findings." I often find that similar to people going, "Well, I'm too busy to go on holiday. Just send me your photos of your holiday and somehow I'll absorb all the value you got from your holiday just from looking at the photos." It's no, you have to be on the holiday to feel it, to soak up the atmosphere, to soak up the learnings and the experience. And so I think tightly integrated design and research teams rather than more silo teams is one big learning for me.
Ash Oliver:
Yeah, that's massive. There's definitely an aspect here of the design innovation and the design decisions that are able to be made when it comes informed by these things. And then it's an entirely another thing, as you're describing, when you're actually firsthand experiencing that, not just in a secondary component.
Andy Budd:
Another thing, I think one of the problems becomes backlogs in general. This idea that what we do is we go out and we find a bunch of problems, we stick them in some kind of linear document, and then we stack rank them and the most important ones come out. And I think, like I said, that works in the early days with the ICE system, but actually I think it's also important to look at prioritizing features across a number of different layers or swim lanes. Because we get some features coming in from the executive team, we get some features coming from the research team, we get some features coming from the sales team, rather than managing them all together and then organizing them, I think it actually makes sense to organizing them in their different layers.
Andy Budd:
So, okay, the sales team are asking for these features, let's stack and rank those and pick the top three out. The research team are saying, "These are the most important things," let's stack and rank those and pick the top three out. And so what ends up happening is you end up prioritizing in a democratic way, so each major function of the organization gets to see the benefit of their problem finding approaches. Because otherwise what happens if you stack and rank everything and one constituent has more power, they're the ones that are going to get, oh, we're going to get 100% of my stacked rank things and everything else will get pushed down. So I'm sure a lot of your listeners will be aware of the Kano model. The Kano model is this really, really nice theoretical model for how you should prioritize features.
Andy Budd:
And it breaks down into these three buckets. You get this fundamental features that are really, really necessary and you can add more of. So the classic example of that would be a hotel room. There are certain things you need in a hotel room just for it to be functional. You need a bed, you need a bathroom, probably a TV maybe might be considered important at the moment, but these are things that you have to deliver or else the offering doesn't work. Then you have these things in the middle which are really, really nice to haves. You can make the hotel room so much better if you offer a flat panel TV and it's a big TV and it has tons of channels. And so you've got this layer of higher level, higher value items which can really add to the experience.
Andy Budd:
But over time, those higher value items end up quickly becoming expectations. If every hotel room is starting to have a big flat panel TV, suddenly it's not important anymore, it's a thing that drops down into just a must have. And then in the Kano model you have this idea of delighters. And it's the delighters I often find that the design and research teams really, really like and become important to them. But they often, in a traditional stack and rank, get really, really pushed down to the bottom. And delighters are often really small things, but small things that can make a big experiential difference. In the hotel example, in the old days, it might be the chocolate on the pillow. Nowadays, it might be that the people that turn your room over write a little message on a card and tell you what the weather's going to be like tomorrow and put it on your pillow. Now, those things will never make it through a more traditional stack and rank, because people would argue, well, that's easy to do, but it's low commercial value, we've got more important things to do.
Andy Budd:
And so some of the things that really build the character of the product naturally get managed out through a more traditional product management process. And so if you can say, "Well, actually we're going to make sure that we're going to give a slice of our backlog to design and engineering and research," so that they can say, "Well, actually, we think that this thing is really important. It's only small, but we actually think that including this animated feature, this character, whatever this beautiful, delightful little delighter is, is going to add value that we are going to prioritize it and we're going to put it on the backlog." So individual teams and individual groups to be able to own small elements I think is really, really important because it actually means that each team feels like they're being listened to, each team feels like what they're adding to the product matters rather than all those things ending up being pushed down the priority list.
Ash Oliver:
That's tremendous. I know that you said that it is a complicated, complex scenario. I could envision where there might be a situation where founder syndrome or something maybe is biasing towards keeping everything in that kind of throw it at the wall self-generated type of prioritization or decision making. How come more teams don't look at it in this fashion?
Andy Budd:
I think it's because each team has a fundamental different lens through which they're looking at the problem. The sales team have the lens that I've been told that I need to deliver this number of sales per quarter, and if I don't, I won't hit my targets and I'll be out of a job. So all they can care about is delivering those sales. The founders of the company, the executives, they're getting pressure from over the place. If it's a smaller company, they're getting pressure from their VC and their investors, they're being expected in order to unlock that next tranche of funding in 18 months time, they have to hit these targets. And so a lot of founders and product people, they're very, very focused on optimizing for short term goals. Now, we all know as designers that if you optimize for short-term goal, you might hit a local maxima. And oh, local maximas are bad.
Andy Budd:
But if the local maxima is going to mean that your business is going to stay in business for another 18 months because it gets its next tranche of funding, there's a real focus on optimizing short term value. And then when you look at designers, we're all about delivering long term customer value. We want to build the best product possible. As designers, we often believe that the best product in the market wins, we believe that user experience is key, that people stick around, they recommend, you know, all of these things if the customer experience is great. And so for us, we'd be pushing back. We're saying, "Well, look, we can't just throw features into the mix. We want to make it perfect." We're going to go, "We don't want to do our research. We want to do some prototypes." You know, that idea is stupid. It's a short term win, but it might have long term negative effects."
Andy Budd:
And so each of us as a different group is optimizing around a different set of outcomes and also a different philosophical and ethical set of beliefs. And sadly, when those differing outcomes and sets of beliefs clash, there becomes a power battle. And unfortunately for design, design tends to be a low down the pecking order. And if they're at the bottom of the pecking order and you are stack-ranking everything, then their ideas of, "well, if you do this thing now, it may deliver value in 18 months time, versus if we make this little tweak here, we know it will deliver value immediately, even if it has a negative effect in 18 months time", people are always going to go to the former rather than latter.
Andy Budd:
So there is this tussle of control. One way around that, like I say, is to try and figure out some swim lane type mentality. One way around that is obviously to remove discrepancy between design teams. I've been a big advocate of making sure that early-stage startups have a founding designer. I think if you are building a new company and you build design in at the start, then that designer will have that seat at the table, from the very beginning will be a peer of the founder, will be a peer of the CTO, will be a peer of the CPO, and so you don't have that power discrepancy. I think I want to see more design leaders not reporting into product, reporting engineering, but reporting into the CEO because that removes that power discrepancy. I want to see more companies hire those senior design hires and have design hires that aren't just delivery people, but that can push back and can advocate for the needs of the customer, et cetera, et cetera.
Andy Budd:
At the same time, I think that is really challenging because, again, as a designer you're always going to lose out if your argument is a moral argument, if it's a values argument, even if it's an ethical argument, sadly, which is why I'm personally really interested in the growth design community. One of the things I think is really, really exciting about this emergence of growth designers is that growth designers are taking all of the skills of design, but they're putting that to bare on solving really, really tangible business problems that are meaningful for the business owners. And so what the growth design community is doing is demonstrating to the rest of business that design can be a really, really powerful contributor towards the bottom line of the business. And if the business starts realizing that design has really smart ideas that can improve their outcomes in the short term, I think they're much more likely to invest in the long term.
Andy Budd:
Because if there's a team, you can say, "Look, we are not just a cost center to be managed. Over this last year, for every dollar you put into the design team, we give you five." As a business person you go, "Well, great. If I double your budget, that just means you're going to double my profit, but with double budget you have more power, you have more opportunity to think a little bit longer term, to bubble up some of those longer bets." And so I think that the growth design community for me is in a really, really interesting place to drag the design community into thinking more business like and dragging the business into thinking more like designers. And so that's an area that I think most teams when they get to a certain size should really start building out growth teams, and particularly growth design teams.
Ash Oliver:
It's just really powerful what you're outlining here. I think all of what you're talking about is stewarding that learning organization across the company in a way that doesn't get locked down, as you mentioned, into a silo, but is something that happens and takes place in lots of different areas, but is constantly being able to be surfaced in a way that's actionable. Definitely a harder endeavor to tackle, especially as the target keeps moving and the organization continues to grow, but certainly I think what I'm sensing from you is first getting that mindset. And a lot of that really takes place in the very inception of the company, as you were talking about, with the founders and having design leadership and forethought at the table.
Andy Budd:
I think a lot of it just comes from, like, when you are building companies there are two ways of doing it. You can either position yourself as a central source of truth. It's the typical pyramid model with the leadership at the top and then everyone just tells the next layer down what to do. However, I think what we see these days is more of a egalitarian knowledge worker environment where actually the people who are in charge realize that they know less than the people they hire. They hire smart people. The goal I think is to hire people who are better than you and then listen to their advice. And so I think management, ideally in tech companies, is about supporting the knowledge workers and feeding their information back and using that information to make better judgments.
Andy Budd:
And that's where research comes from. Research is basically a indicator that you've got a bunch of people making decisions and they're making decisions on a bunch of different angles. Some of it is around the financial needs of the business. Some of it is around the health and culture of the company and employee wellbeing. Some of it is around user needs. And you're pulling this information in, you're sifting it, you're listening to the people that tells you this information, and you're making decisions based on all of the information sources. Sadly, I think in a lot of traditional companies, people have only one information source because they want a really simple life that they will listen to. They often block out or plug up some of the other information sources because often those information sources are giving counter information.
Andy Budd:
It's like, "Well, I don't want to listen to user research because I've decided I want to do X and user research is saying that we shouldn't do that and that's really complicating things. And so I'm going to ignore them and go with these instincts." And so if you have this top down approach, you're not utilizing your team anywhere near as much as empowering them. Again, it's classic stuff. It's asking for outcomes rather than outputs. As a leader of a department, you shouldn't be saying, "I want you to implement X, Y, Z." You should be thinking that this, this and this is important to the business, I want you to independently figure out what's the best way of delivering X. So there's complexity there, but outcomes over outputs and trusting people to solve the problems you've given them rather than just telling them what to go and do and how to solve those problems.
Ash Oliver:
Tremendous. It's such a great summary for what we've just uncovered as well. I really appreciate you sharing that knowledge and perspective because I think it's not talked about enough. Wonderful. Well, I want to close up our session with some more personal questions. Three that we typically ask every guest, it's our hat-trick questions. So the first one is what's one thing that you've done in your career that you feel has helped you succeed personally that you feel that other people don't often do?
Andy Budd:
That's a tough one. When I was younger and when I was teaching diving, I got really comfortable standing in front of crowds of people, talking to groups of people, being in charge of groups of people and their safety, et cetera, cetera. And I think that really, really set me up for my later career as a design leader, as a manager and as a speaker. Understanding how people learn, understanding how you can communicate to people, understanding how you can get people excited and manage their moods, and understanding just the value of communication.
Andy Budd:
And I think that those foundational skills meant that I was good in front of clients. It meant I was good in front of other designers. It meant I felt comfortable speaking at conferences, which opened up a whole range of different opportunities for me. I think the speaking at conferences gave me business opportunities. It gave me opportunities to learn. It allowed me to raise my profile. All of those things were amazing, but I think I tie them all back to being a slightly shy 22 year old and having to get up in front of a boat of people and give them a dive briefing about how to not get bitten by sharks. So a lot of that comes from that experience.
Ash Oliver:
I love that. This is just kudos to how you weave in stories and in your storytelling and in your talks. But if you can do that in front of sharks, then getting up on stage in front of any design conference is going to be a small feat. What is one of the industry relates, and you can use industry related as a really broad term here, but what is the industry related book that you've either recommended or given the most, and why, if you could?
Andy Budd:
The book I'm recommending the most at this moment is The Cold Start Problem by Andrew Chen. As we mentioned earlier in the talk, I'm a big fan of the field of growth design and the importance of growth in general. I think a lot of designers talk about how they need to understand the value or the language of business. I think that's a bit of a red herring, because I think when I speak to people that say they want to understand the language of business, they want to do it so they can convince stakeholders, in their language, to do what the designer wants them to do. And in a weird way, that's slightly manipulative. And actually I think a book like The Cold Start Problem is actually a much better book at teaching designers what businesses value. And so The Cold Start Problem is very much a book around how companies acquire, retain, engage customers.
Andy Budd:
And I would like to see more and more designers thinking not about building this perfect monolith of a product that only meets user needs, but doing it a way that actually also meets business needs. And if we can find a balance between user needs and business needs, but in a way where the users aren't the ones that always miss out, I think that's really important. And at the moment I think the balance of power is often with the marketing teams or with more generic growth hacking teams where they are only optimizing from the growth perspective. So having designers in that can understand both side of those equations and can solve problems in a way that ideally solves both of those elements, I think is potentially really, really powerful. The Cold Start Problem would be one I'd recommend your listeners grab a copy of now if they're looking for their next book.
Ash Oliver:
I love it. Thank you very much for that. I appreciate it. The last question we're going to end on here is what is an unusual habit or an absurd thing that you absolutely love?
Andy Budd:
Oh God, an unusual habit or an absurd thing. I don't know whether I have any overly unusual habits or overly particularly absurd things. But when I was younger, after I left university I did a bit of busking. And so for summer season after university to save money to go traveling I would stand on the streets and I would do a little fire juggling performance. And off the back of that, somebody in the local town saw me doing this and say, "Hey, do you want to come and I'll pay you to manage my juggling ball stand?" And so I used to do a lot of juggling when I was younger.
Andy Budd:
I've got a little set of juggling balls behind me. And quite often, if I'm listening to a podcast or if I'm listening to a meeting that I'm not expected to be particularly active in, I'll just sit and juggle. And it helps me think. It gives me a little bit of an upper body workout and it probably is absurd if you saw me sat on a meeting call juggling, but that's probably the most absurd thing that comes to the top of my mind.
Ash Oliver:
I absolutely love that. That's why I ask these questions, because I'm always surprised by what the answers are. Thank you so much, Andy, this has been an absolute gift to have you on the podcast.
Andy Budd:
Likewise, so good to connect and I look forward to seeing your next ones.
Ash Oliver:
The Optimal Path is hosted by myself, Ash Oliver, and brought to you by Maze, a rapid user testing platform designed for product teams. If you enjoyed this episode, you can find resources linked in the show notes. If you want to hear more, you can subscribe to The Optimal Path by visiting maze.co/podcast. Thanks for listening. And until next time.