These days, it's nearly impossible to plan ahead with any level of confidence. One week, new tariffs. Later that week, tariffs postponed. The next week, sweeping policy proposals that reshape healthcare, immigration, education, tech regulation, and you name it. From the White House to the State Houses, but especially the White House, the pace of political and cultural change is staggering. And the ripple effects are hitting every industry. For leaders trying to plan, it's like trying to build a sandcastle in a windstorm.

This kind of environment that we're leading in now, it's unpredictable, it's volatile, it's constantly changing. And so here's the question. If the rules can change overnight, how useful is a static plan? That's what this episode is all about. Why planning isn't working anymore, and why designing with prototypes and feedback loops and iteration is the only way to lead in a world that refuses to stand still. So let's get into it now. Not only do I help guide leaders and organizations on how to adapt in the face of this kind of volatility that I'm talking about, I also need to do so in my own business. To be sure, I follow my own advice as much as I can. Or as we like to say in the UX field, I eat my own dog food.

But that volatility that we're talking about, well, sometimes I'm on the receiving end of it. Case in point, I experienced this firsthand not too long ago. I had a client last October. We talked about bringing me in to deliver leadership program to their organization. And sure enough, proposal drafted, contract signed, date confirmed, February. Everything was all buttoned up. Now, keep in mind, the program had nothing to do with politics. It wasn't controversial in any way.

Straight up leadership skills. But the funding for this session came through that organization's women's org, or employee resource group. And in the weeks leading up to the program, President Trump issued an executive order threatening to pull federal funding from any organization with DEI programs. Now, this client is a private company, and as far as I know, they don't receive any federal funding. But they are in a highly regulated industry and they didn't want to take any chances. So the day before the event, let me underscore that, the day before the event, they called me to cancel. Not because of what the session was about, not because of budget, but because the political climate has shifted and they didn't know how to navigate it. Again, that's the kind of environment that we're leading in right now.

Unpredictable, volatile, constantly changing. So how do we survive and how do we thrive in these types of circumstances? Well, I'm going to give you some ideas that stem from my keynote called Expect the Design for what's Next, which is entirely backed by UX thinking. You see, I take the perspective that there is no crystal ball to look into. We cannot with any accuracy whatsoever, predictability, predict the future, but what we can do is we can design for it. So I'm going to talk about designing versus planning and I'm going to give you some actionable takeaways that you can put in place to start to design more and rely on plans less. And you'll understand exactly why you need to do that as this episode progresses. So let's define both terms clearly so that we know what we're talking about. When I say planning, I mean something that is linear, simple, static.

It assumes predictability, the kind of thing that you create when you go into the leadership retreat and create the three year strategic plan. There are some common planning assumptions. One of them is that we know what the landscape will look like and that it won't change. Another is that our stakeholders or our customer base will remain the same and that resources and policies and the political environment that we live and work in will, will remain stable. But when any of these variables change, well, that just really puts the whole plan at risk. So that's planning.

Now let's take a look at designing. On the other hand, designing is adaptive. It's user centered and it's built for iteration. It doesn't intend to stay static. So design assumes that change is inevitable and design builds in flexibility. The core mindset here goes something like this. Let's try something, let's learn quickly, let's evolve, let's iterate. That didn't work. Let's fail forward, let's fail fast, let's try it again. So designing is also centered on users needs, whether those users are your team members, your customers, other business partners, either inside your organization or outside your organization and not just top down directives.

Design treats strategy as something to shape and reshape and mold and remold, not something that's locked in. So again, a strategic plan assumes that you know what's coming, but a design assumes that you don't. And in this world with rapid change and so much volatility, we cannot, with any level of accuracy whatsoever, assume that we know what's coming. Now when we put a UX lens on this, what we see is that you know designers well, they prototype things and they test things before committing to them before building them out for real. Planners, on the other hand, lock in direction too early and have rigidity about sticking with that direction. So design is not just for products. And again, if you've heard any of the episodes of the podcast these last couple of months, you know that I'm talking about UX thinking and UX tools to help us lead better, to help us lead the users who are following us again, whether we're leading from the side or leading from the top of the org chart. And it also helps us evolve and shift in changing market conditions and in this volatile world that we're in right now.

So to do this though, it requires a shift from thinking in terms of plans to thinking in terms of design. It shifts you from rigidity to responsiveness, from knowing or thinking, you know, to noticing, from fixed outcomes to flexible frameworks. So it's designing a better path forward. And what does that look like in practice? Well, let's break it down. I want to break it down into three distinct steps, because this is how design works. It's going to start with prototyping, then we're going to get some feedback on that prototyping, and then we're going to iterate. So three steps, prototype, feedback, iterating, and we're going to use that as a core design methodology for leading through uncertainty. All right, again, these are some of the concepts, not all of them, but some of the concepts that come from my keynote called Expect the Unexpected Design for what's Next.

And we're really going to highlight that design embraces uncertainty as a feature and not a bug. It is not something that is going to throw a monkey wrench into things. It is something that we're planning for. We're planning that there is going to be change down the road and that whatever we're creating is going to have to shift in response to that. So volatility, complexity, ambiguity, that is just baked into a design framework and a design thinking framework and UX thinking framework. Now, from, you know, you know how I like to pull in resources. And so from a resource standpoint, Don Norman, who is like the grandfather of user experience, in his book the Design of Everyday Things, he writes, quote, design is really an act of communication, which means having a deep understanding of the person with whom the designer is communicating. End quote.

Now, that would be your end user. Now your end user again, could be your co worker, it could be your direct report. If you're a manager or a leader, it could be your customer, it could be a vendor or some other business partner that you work with. And Norman's idea really supports the notion that designing, unlike planning, but designing is inherently human centered. It's not about controlling the future, it's not even about knowing the future. It's about understanding and adapting to the needs of users, the people that you're designing for again, your team members, your customers, your employee base, your business partners and other stakeholders. And it underscores the idea that leadership itself is a design challenge. Isn't that fun to reframe leadership as a design challenge, to think about who we're designing for and to create something that is a beautiful design for them to use and live into? Oh, you can tell it excites me.

It gets me all jazzed. All right, so let's look at those three pillars of design and relate them back to leadership. So the first one is prototyping. So let's talk about prototyping for leadership. So when we think about prototyping, we're creating something that isn't fully functional yet. We want to see if the rough design holds its weight. So we want to create something partway and then road test it. So let's look at ideas, decisions, even policies.

We can prototype them before really committing to them. So let me give you a few examples. Let's say that your organization is doing some form of return to office, which so many are these days. Instead of rolling that out as a surprise to your staff, what if instead you did a pilot study of it, you prototyped it, and you prototyped it for just a small group of employees and you had them try it out again. You want to road test it before it's fully baked and cascaded out to the whole organization. So instead of launching a permanent hybrid policy, you might pilot it for 90 days with one department and then collect feedback from them to find out what worked, what didn't work, how was it communicated? Did they appreciate how it was communicated? Were there any flaws in how it was communicated? As well as, you know the logistics of how it was rolled out. Now once you collect feedback on that, you can analyze that feedback, you can make adjustments, you, you could do another 90 day iteration to see if that, if you change things for the better. So there's lots of different things you can do once you do that initial pilot test.

So that would be one example of prototyping and why it matters. I mean, it reduces resistance and it allows learning before there's a company wide rollout of something. Now it doesn't have to just be returned to office. It could be any new policy or any new thing that you're thinking about implementing. Think about what's the minimum viable product or the MVP version of it that you could try and pilot test with one small group, collect their feedback and then iterate. Okay, so another thing that you could do in terms of that sense of prototyping as a leader, you could come up with scenario based strategy sessions. So instead of committing to one strategic plan, you might create two or three future scenarios that presume different market changes or challenges, different economic models happening in the world, different political things happening in the world.

And you could prototype how your team or your customers would respond to each of those identifying gaps and opportunities. You might even run those scenarios past some customers in a focus group type setting. Again, that's getting to the collecting the user feedback. Again, the more you can think about that prototyping, what's a minimum viable version of this that we can road test before we fully roll it out? It's going to save you time and money in the long run. It's going to build agility and it's going to prepare for multiple possible futures. That's right. I said multiple possible futures. Because we don't have a crystal ball that we can look into to say exactly what the future is.

We need to prepare for multiple possibilities, multiple possible and different futures. A third thing that you could try in terms of prototyping is a day in the life walkthrough. And so this would be before implementing a new policy or whatever it is that you're planning on rolling out, probably inside the organization, although it could be customer facing, you would want to simulate how it would affect different types of customers, like say different market segments or different types of roles inside the organization. How does this affect the marketing department? How does this affect the PR department? How does this affect the software engineers and so on. So you would like literally road test it by asking some of those folks to walk through a day in the life of if this policy, let's say you were changing how people badge into the building, you would want to road test that with, you know, different pockets of the organization before rolling that out to everybody. So in doing so, you're going to get useful feedback from different roles or different customer segments, depending on if this is an internal or external thing. And what it's going to do is it's going to reveal unintended consequences for of things that you maybe hadn't planned for or things that could go wrong and then give you an opportunity to correct those and fix those before you roll something out on a much wider scale, it's also going to boost buy in from the people who got to try it early. Because anybody who got to try something early and offer some feedback, whether that's positive or negative feedback, you know, the opportunities for improvement or what's working really well, those folks are going to have much more buy in.

Even if they didn't like it, they're going to have much more buy in when the thing rolls, rolls out to everybody. So overall, in leadership, prototyping means testing an idea before it becomes policy, before it goes out to your customers or your employees. It means inviting feedback early. It means making those adjustments quickly and on the fly and trying again and treating change like a living experiment rather than a fixed decision. Okay, so that's your first step, prototyping. Now that you've prototyped something, you're going to get some feedback. And in most of the examples I walked through just now about prototyping, there was feedback involved. But I want to treat feedback as its own discrete step because I don't want you to miss it.

It's that important. So you want to use that user feedback as a strategic asset. So whether the users of whatever decision or tool or policy that you're rolling out, whether the users are your employees, your customers, or again, other business, business unit, stakeholders, vendors, that sort of thing, they are users of your leadership. And when you employ feedback loops, that helps you adapt more quickly. So let me give you an example of what are some things that I mean when I say feedback loops could, because there's dozens of different ways you could take that. But let me just give you a handful. The first one is a pulse survey. So a pulse survey is a short recurring check in with your team or stakeholders.

Oftentimes you're asking the same one to three questions on a weekly basis, a monthly basis, and so forth, that tracks sentiment, workload, confidence and direction. Um, and if you're in a mid to large size organization, there's a good chance that pulse surveys are already being taken of the employee base. And if you're not part of that HR team who's rolling out those pulse surveys, you probably could tap into them. Or if you just wanted to do a pulse survey with a smaller subset that you're testing something, or prototyping something with that team could probably give you some good feedback and, and coaching on how to do that and do that well so that your questions are formed in a way that make for really valid research. So when you're able to capture change over time. Again, that's why the pulse surveys are short and repeated the same questions repeated on a frequent basis. It allows for you to course correct early and get that early those early indicators. And this is why you want to, you know, you want a few iterations of that pulse survey to see the trends over time because the multiple data points are just going to be super helpful for that.

So the second idea here in terms of getting the, getting those feedback loops would be a pilot program with built in review. So we talked about pilot program already before, but making sure that you have some review process built into that pilot program so that you're getting feedback directly from the users who are piloting it. So if you've got a new initiative, whether it's a policy or a tool, a piece of software, a process, whatever, you're testing that with a small group and you're scheduling multiple review points to gather input before you're solidifying it and before you're doing a wider rollout. So this matters because it's going to encourage iteration before you scale something, so you're going to get a chance to fix the little and the big problems before you roll it out to a much larger group.

So the third idea I want to give you in terms of feedback loops is retrospectives, or that's what they're called in agile software development. But you might also think of them as a post project debrief. And these are used again in software teams, but you can use them in other teams and other small groups as well. And what you're really looking at here in a retrospective is what did we do well that we should keep doing, what didn't go well, that we should stop doing and what have we not thought of yet that we should start doing? So if you want to think of it in shorthand, it's start, stop, keep, what should we start doing? Or change what should we stop doing because it's not working? And what should we continue to do because it is working.

So what this methodology encourages is reflection and it's a very structured and psychologically safe format because there's no, you know, again, if it is conducted in a way that says, hey, we welcome the feedback, especially the critical feedback. Again, that's what's going to make it a psychologically safe environment where people can take a risk and something that, and not worry about repercussions down the road.

In fact, the more critical the better because they're going to increase the viability and the reliability of whatever it is you're making so that when you do roll it out, it's going to be a better product policy or whatever as a result. And then as a former professor, I really also like this following one as a feedback loop, and that is office hours or some sort of open forum. So it could be like literal office hours. If you are a manager or a senior leader who's rolling out a new idea, you could have office hours specifically dedicated to, to that where you're inviting people to come either physically to your office or to meet with you on teams or Zoom or wherever you meet in, in the ether. And you're going to create an opportunity for team members to give feedback directly to leaders and directly to you who is designing whatever it is you're designing now. It could also be set up as a ask me anything.

I know a lot of times people like that format as well. Instead of office hours, that could sound a little stiff and formal, but you could set it up as an ask me anything meeting. So you as the leader show up in the teams or the Zoom or a conference room, and people are just invited in to literally ask you anything, ideally about the change that you're making in the organization. So you may need to put some bumpers on that one because you, they may have lots of things they want to ask you anything about, but you might want to put some bumpers on it so that they know that it's asked me anything about this specific initiative. So again, this having that open forum, office hours or ask me anything is going to reduce barriers to people giving you feedback because they know it's invited, they know it is requested and wanted, and that their feedback is welcome. So overall, as you think about these feedback loops and the various ways to get input from your users, you want to think about listening and leaders must design for listening. You want to listen to how things are landing and figure out the best ways to make again, either small or large adjustments. So feedback loop doesn't have to be formal.

What matters is building in these ways to listen, to learn to adapt, and to take action on what you have learned in these listening sessions so that your leadership design evolves with reality and doesn't push back against it. All right, so that is the feedback loop portion. And then let's talk quickly about iterative design over the final plans of rolling something out. So if you've already prototyped and you've already gotten some of those feedback loops in motion, you already know that you want to make some changes. So again, iterative Design. The third step in this process is going to have you basically rinse and repeat what you just did, probably on a fairly small scale. Oh, that one particular part didn't work. Let's try something else for that particular part and keep everything else the same.

That way you're testing one variable at a time. When you start to change multiple variables at the same time, it gets confusing for your user. And when something improved, you're not necessarily sure which part of it improved. So as you're going through that iterative design process, it's much better to make small, fast design changes and then test them. Now, I want to put a ginormous caveat on this. If you are going to be using iterative design and changing things up quickly and then sending it out again, I want you to socialize the idea that you are taking an iterative design approach. Communicate, communicate, communicate.

You don't want to be seen as somebody who is always changing your mind and always rolling out something new without checking with people. Instead, you want to be seen as a design focused UX thinking leader who uses design and design principles to be understood and to be flexible and to be adaptable and to be responsive to how things are landing with people and being responsive to changing environments. So always preempt, preload any changes that you're making with. Remember, this is an iterative design process. We've made a few tweaks to the policy, we've made a few tweaks to how we badge in and out of the office or whatever it is. Now we want you to retest, so make sure that they understand that this is a testing environment and that they are part of the testing environment and that they are being asked to retest. Now, when I teach my masterclass on meeting facilitation, one of the things I do is I encourage meeting facilitators to take one or two changes, not more than one or two at a time, and implement them, but to let the people who are in their meetings know that this is an experiment. We're changing up the agenda, we're changing up how we take meeting minutes, we're changing up whatever.

And this is an experiment. And I will be checking back in with you to see how this works. And again, this is so that your changes don't seem arbitrary and capricious. This is so that your changes are grounded in UX thinking and in taking seriously the notion of design as a leader. This is really, really important. Now when you start to shift from planning to designing, you move from certainty to curiosity. You move from control to responsiveness. You move from knowing everything to noticing everything.

Or maybe not everything, but as much as you can notice and being responsive to what you notice. So good leaders don't just respond to change. They're designing for it. All right now, as you go into this next week, don't plan, don't predict, but do design. I want you to do a little audit of your own leadership approach. Are you planning or are you designing?

So this week, ask yourself, what is one area of my leadership that could benefit from more design and prototyping and less planning? I hope this episode has given you a new perspective.

And if you think that the program expect the unexpected design for what's next might be a good fit for your organization, use the contact form on my website to reach out to me @janelanderson.com super easy to find that contact form. I'd love to help you in your organization, or at least have a conversation with you to see if that program might be a good fit for you, your association, or some other group that you're part of.

Because I want you to design for what's Next. If this episode resonated at all, please share it with just one friend or colleague that you think would learn from it, would appreciate it, would grow from it. All right, my friends, be well and I'll see you next week.