Tēnā koutou katoa. Welcome to this Alan Clark webinar on effective problem definition. My name is Craig Griffiths and I'm an innovation and engagement lead here at Alan Clark.
I'll be hosting today's webinar during which we'll provide you with more than 20 practical tips and tools to help you define problems effectively and better understand your business challenges. It's lovely to have you here today. For some of you this might be the first time that you're joining our webinars or you're not familiar with Alan Clark.
We're an Australasian based consultancy dedicated to making a positive impact on communities throughout Aotearoa, Australia and the Pacific. Our areas of speciality include strategy, change management, programme delivery, policy research and evaluation just to name a few. As we go through today's session if you have any questions please just pop them into the chat and we'll try to get them through the webinar.
If we don't get to them we'll cover them off in the Q&A session towards the end of the webinar itself. But before we go any further on that let's get some introductions done. Jason would you like to lead us out? Sure, kia ora koutou.
I'm Jason Carpenter the Director of Business Development here at Alan Clark. So I have a policy background and one of the things I've learned over that time is that there's with policy there's almost never a really simple problem definition. It's normally like a big complex challenge with things outside of your control so economic, social, behavioural, ministerial, you know all these sorts of challenges that arise.
And so today looking forward to how do you frame up problem definitions for big complex policy problems. Awesome and kia ora, I'm Jeremy Markham a Senior Consultant here at Alan Clark. I've got specialities in areas including business improvement, change management, I've got an academic background in psychology, philosophy and business and so today I am particularly looking forward to talking about tackling unconscious bias and even sharing my favourite business tool with you.
No way. In addition to leading our innovation engagement work here at ANC I'm also an Executive Coach at Stanford University's d.school where I get to teach design thinking to execs from around the world and something I particularly think is important today just emphasising how important it is to spend time on defining a challenge you actually need to solve rather than the one you think you do. So today we're going to be tackling five key problem definition challenges, what causes them and our tips and methods to tackle them in order they are jumping to solutions, failing to challenge bias, poor scope management, mistaking symptoms for root causes and struggling to tell a really good story.
Okay so let's get started. Humans are natural problem solvers which is a really good strength to have and one of the things that's made us such a successful species but it does mean that we often jump to conclusions and to solutions even faster. And that causes some of the lessons that we've learnt the hard way as we work through today.
Yeah absolutely. I always say a solution is only as good as a problem it's aimed at or put a different way it's impossible to provide an answer to a question you don't know. What this means is if you want to increase your chances of a really successful outcome we need to invest time in understanding the challenge, the one that you need to address rather than the one you want to and before you try to solve it.
This is particularly true if you have limited budget or time or in fact both. A number of you told us that jumping to solutions and poorly defined challenges and false starts are big issues that you are currently experiencing so we thought rather than leaving it to the Q&A at the end of the session we'd jump in and tackle it right now. It's a really common problem and on the slide you'll see there are some indicators to help you identify if you or your organisation are solution jumpers and why this occurs.
Jumping to solutions doesn't always have to be from the get-go either. Sometimes there will be a you know like an aha moment where during a piece of work where you realise that you're barking up the wrong tree. It might show up as a lack of engagement or slow or no progress in your work or prototypes whether they be design challenges or solutions that just aren't landing with the users.
And sometimes we can refer to that as an oh shit moment as well and to help with that we've developed what you can see on screen here which is a mid-project rescue guide so a quick fire list of tips and tricks that you can sort of use when you hit that point and how you can quickly redefine the challenge to solve, communicate the change and then get the work aimed at the actual challenge. And I think my key takeaway from this is that it's okay to redefine the problem. In the long term you're much better off to catch it that you have an issue and then do something about it and then linked to that is that you'll find that the rest of the work goes better especially if you're explicit about the change so don't act as if you've just sort of found this thing or you know whatever but you get people invested in the change.
Tell the story of what prompted it. Yeah we started with this, we did some work, we then found out that actually it's this and so rather than just you know carrying on with the thing we wrote down in a briefing a year ago, great news we've got a better challenge we can now move forward with a stronger work programme because we've got our challenge set up better. Yeah absolutely agree.
Interestingly enough in about 90% of the work that I've done in design the challenge that we started off with has changed by the time we've come to solve it and the key there was that the input from user perspective so by gathering them, going out and gathering user perspectives you're infinitely better placed to make a call about what the challenge actually is as again against the ones that you think it is. So thankfully there are a few things you can do to ensure that you're focused on the right challenge. One of the key tenets of design thinking in particular and my key tip here is that the use of a product service or system is best placed to help you articulate those challenges associated with them and by adopting a disciplined, sorry by adopting and being really disciplined about maintaining a user's perspective that's really critical to the great problem definition.
Let me give you a quick example of how that pans out. So a couple of years ago I was working in the energy industry and I was asked to look at what the industry might do to help address the issue of energy poverty which at the time was defined as applying to any household that has to spend more than 10% of its income on energy. So after going out and talking to a couple of people affected by energy poverty you know with lived experience I quickly realised that it was clear that the energy industry was looking at it from their perspective or the issue from their perspective either from a supply side one and a lot of the current solutions that were in the market were centred around energy efficiency or for instance the provision of energy efficient appliances and lighting.
However looking at it from a user perspective and adopting a visualisation tool called the lamppost technique of which you'll see on the slide that's just come up it highlighted for me that the current set of solutions were based on a flawed assumption and that flawed assumption was namely that the households experiencing energy poverty had access to energy i.e. that they were connected to the grid let alone able to pay for it. So the problem that really needed to be addressed for those in the greatest need was one of access to energy. This helped me, realising this helped me reframe it into that problem definition into two distinct customer and demand side design challenges.
Namely how might we or the industry provide power to those experiencing energy poverty and how might we do that at a price that they can afford. Two very distinct and different challenges. Interestingly when I was preparing for this webinar I had a look at how energy poverty is now defined and it's called energy hardship nowadays but it's defined by MBIE as when a household is unable to afford access, sorry afford or access adequate energy services for healthy and satisfactory living which is a really much more user-centric definition.
Great thanks Griff, that was really nice. Totally endorse that. Now let's move to our second challenge which is about tackling bias.
I get pretty excited about this one. So most of you know that we don't see the world truly objectively, we interpret the world through a mental model like a filter. It could be based on our values, our cultural norms, our life experiences and so on and just like maybe wearing sunglasses, sometimes you can wear sunglasses so long that you forget you're wearing them.
We become very unconscious of this filter that we have and that can create some really big blind spots for us. Another thing that we need to consider is that our brain's default approach to making decisions prioritises speed and energy conservation but not in depth analysis. So if we do want to do that deeper thinking it can sometimes feel like we're swimming against the tide of our brain's default pathway.
So, we need to be really intentional about choosing to slow down, think things through more thoroughly and actively challenge those assumptions, including the assumption that your initial instincts about the matter are correct which is what we call confirmation bias. Now you can't eliminate all that bias but here's a few things you can do. So one thing you can do is raise your awareness around unconscious bias and its impact on the way that you think.
If you can get really clear on your own mind about that and on the benefits of taking a structured thinking process, it'll help you commit to following a more structured process. Another thing that you can do is to choose to be really inclusive and be as inclusive as your time and your budget allow. We know that you don't have unlimited time and budget so you can tailor this but as much as you can try to really, when you're talking to people, try and talk to as many people as you can that have a different perspective.
So the people that are impacted, yes, the people that are working on the solution, the people who might be in adjacent roles and particularly if there's any disruptors or mavericks who might bring a really different point of view, get that too. And similarly with your data sources, take that same approach instead of going oh but we collect these three data sets so I guess that's our evidence base. Think broader than that, you're not going to have nice neat data sets for every aspect of the thing you want to learn about, right? So you want to think oh what other things could we do to be able to get some information on this? And I'm a big advocate of going to physically observe the problem where you see it occurring.
A third thing you can do is to choose to use one or more structured approaches and there's many tools out there that can force you to think and to really challenge your assumptions and think more deeply about the issue. And so I know you're a big fan of tools but is there a favourite that you want to share with the people, Jeremy? Yeah look there are so many and people have their own go-to's, right? And I know that Jason you're a policy guy and plenty of our listeners will be policy people looking for that but my world in sort of the business improvement space, often we're focused on organisational challenges and like for example one hypothetical one, you can probably see it on the screen, it's to do with staff burnout for example. And one tool that I love that can help with this is something called the Gilbert model or also known as the six boxes.
And what I've found from using it is that it is super intuitive, really easy to understand and it's backed by research. It is really holistic in its approach, it looks at the system and it also highlights why sometimes one of those one point solutions often fail and I know that's a big point of frustration. You can scale it to match your time and budget and you can use it for diagnosis and you can also use it for change planning.
So I've used scaled versions of this many times, particularly when I was in business improvement and change management and I would say that in change management lots of people talk about different tools, you know AgCar and all sorts of things but actually I think this was a real big go-to for me. So just very briefly a little bit about how it works. So on the screen you should see an example of the Gilbert model and about a hypothetical example I came out about staff burnout and so the content there is just very illustrative.
But the tool identifies six areas of influence at play at an organisation that affect behaviour and these are represented as the six boxes. You could start using the tool by systematically considering, you know thinking about what you want to achieve and then asking well for each of these boxes what would need to be in place in order for us to succeed and then you can kind put that to the side for a moment and go okay then, so what are we actually observing? What's actually going on right now? And you can see where you are and where the gaps are and so forth. And so if you look at the third box on line one, incentives and consequences, the easiest thing to think about would be what are our formal processes around performance management right? But actually if you go beyond that and you think about the worker perspective and you think about what's actually going on for them, often you'll find like competing incentives, hidden incentives, unintended consequences and that's the kind of stuff that just doesn't get surfaced very often.
So bringing this tool can really bring some of that out. Now I can't talk too much more about the process although as you can see I get pretty excited about it but if you do want to learn more I'm more than happy to talk to you but also the website sixboxes.com is a really good resource site for it, there's heaps on there. Nice, nice one.
I guess just like that it's important to have a variety of perspectives as inputs to a problem and also to keep that line of sight to the end user. For instance if your end user might be a customer or a client or a consumer or a patient, however you determine it, they're constantly checking that their needs are the focus otherwise bias can really creep in. One of my favourite tools to help against bias creeping in is the line of sight tool.
It's like a mental string line that keeps you tethered to and always referring back to and focussing on the needs of the end user. It's a metaphorical tool that helps me make sure that I'm always using the perspective of the end user and to course correct if there's a kink in the mental string line. Something like the client or organisational solution biases starts to creep in.
I recently used this the line of sight tool in a piece of client work where the client was looking to improve their relationships with their suppliers. They'd done some really awesome work, used a lot of design thinking principles to engage with suppliers and finding out what their experiences were working with our client and how that turned up for them and impacted the supplier's business. But when it came to framing the design challenges they lost sight of the line of sight back to the user and the design challenges had taken on a real inward focus.
So I used the line of sight tool to help highlight the kink and the challenge definition and in this case the internal bias that had crept in and the challenges as they were currently defined were not user focused as they didn't reflect what the user needed or the impact on the client and they were missing the mark. So knowing this we were able to rewrite the design challenges to reflect the supplier perspective and focus on their needs. The client perspective was applied later on when they were prepared to figure out what they were prepared to do to facilitate the solutions to those needs.
And that's actually something that happens a lot in policy, implementation in particular. Agencies get very focused on the status quo, improving the status quo and from their own perspective rather than going back to the end user perspective, that first principles and so your problem definitions end up being built on just too many assumptions around how things have to be and you haven't been revisited, you haven't done the engagement, you haven't talked to the users, you're then sort of you know you're basing your problem off sort of incorrect or not ideal data. Which brings us to our third challenge which is managing scope.
So in policy work it's really easy to get overwhelmed by the sheer complexity of issues and then as I said when something's everything everyone's problem it's no one, so how do you shape that up? If it's too broad paralysis, too narrow, you're just treating symptoms. So one example that we did a few years ago was looking at accelerated silicosis, a really awful disease that affects people working with engineered stone in kitchens in particular. You know it's control sits across multiple agencies, workplace safety, health, immigration, even trade.
And so what I did was I worked with WorkSafe to reframe the problem for now in a way that precipitated action. So it wasn't actually a lack of understanding about the issue or even a lack of evidence, it was the problem that we worked on solving was how do we get change now, we need to make change you know at this point in time. So reframing the problem away from like silicosis is bad, end silicosis to we need to get some decisions made within our sphere of influence so really clearly articulate what that was and then you know got the messaging right.
Another one that we looked at you know Jeremy and I worked on stop smoking services a few years ago. You know when you're talking about something like you know tobacco control it's a big policy issue, there's personal and you know economy-wide issues related to tobacco use and addiction, but when you talk to the user it might be the 15th most pressing thing on their list of priorities. And so you know you can frame it as a I'm going to make sure that we do this thing in this way, but then you talk to the actual users and they're like well you know this person came to my house and we talked about education, health needs, stable housing, income, like these things that so smoking was so far down that if you'd said oh and by the way you should stop smoking for your health it just would land really flat.
So really looking at the challenge for now and then how what are the things in your control, so you can control how the service is set up, you control how it's procured, you can't control that person so just framing your problem for what you can do right now is something you know really important. And so while I'm saying that I'm talking about narrowing your thing. The narrowing only works when you do take a systems view, so if you do start that with the full set of drivers and the wider context you can then keep sight of them so similar to that line of sight, like so then when you do work back up to your sphere of influence you're still understanding and acknowledging the broader set of controls.
So you're trying to you know go back to first principles like why are we doing this, why is the government intervening and then work back up to and then I'm going to improve my intervention now. So one one thing we talk about is the you know the five whys, so if you've got a if you've got an issue you know ask why, just say like why is it an issue, why is it an issue, so push down to sort of the root cause and then on the flip side is you know the how do you then explain that cause to someone else. So in the policy project there's lots of tools to improve your cab paper, your RISs, so you know if you're looking at trying to explain that root cause you can go all the way down with the whys, but then one thing I like to add to that is the the five you know the five what's, so so what.
So you know in the example there you know my legislation doesn't cover new technologies, so you know some risky products reach the market, so you know people have been harmed, it's like well you know and then you can either stop there or keep going. So define the root cause and the leadership impact, so really trying to understand where it's come from, but then also be able to explain it to someone else and so that getting the scope right prevents two traps. So you know you don't want another working group with the chief executives that becomes the deputies, that becomes advisors with no power to change anything, but then too narrow you treat the symptoms without addressing the root causes.
So you can do things like sphere of influence analysis, you can strike the balance, understand the system, but then really clear to define what you can control. Nice, yeah it's a really good segue into a trap that many people fall into actually, that's our common challenge number four, which is mistaking a symptom for the root cause of a problem. So there are a few tips to avoid falling into this trap.
The first one, which we've already discussed at length, but it's really worth repeating, is don't jump to solutions. But the second is that people's behaviours are driven by their emotions, and to understand and change their behaviours you really need to understand the emotions driving them. Now as an example, and forgive me here Jase, but if I was to punch you, you could address the behaviour by locking me up, and that would stop me hitting anyone else while I was in, while I was locked up, but it wouldn't actually address the underlying behaviours.
So as soon as I was let out again, what would I do? Punch someone else, right. So you need to understand what it was that made me hit you, right. So understanding the underlying emotions that made that, so was it you know, was it anger, was it fear, what was driving me to do that? Then we are just, if you're doing that, you're just addressing the symptom and not the cause, so I'm just going to go out and hit people again, and that'll continue.
I guess simply being aware of the relationship between emotions and behaviours can be really powerful in terms of good problem definition. You know, for a great example of this, I'd suggest you maybe go and have a look at my webinar on design thinking, which features an example of one of my d.school colleagues, Doug Deitz, and his amazing work he did for GE around CT scanners. I really recommend you have a look at it, it's a fantastic piece of work.
And then third, what people say and what people do are really different things. I once worked for an institution, a tertiary institution, and I was helping them with their intranet user experience, or their UX. As part of that discovery work, I interviewed a guy who was advised that he never used the current intranet.
You know, he wouldn't know where to find it, he was not a big fan of it, he just didn't engage with it. So I said, I'd love to interview him. So I went over to his desk and I sat down and I said, okay, well, look, you know, I know that you don't like the intranet, but could you just open it up for me? And before I could say anything else, he'd whipped into his bookmarks, he'd dragged down, clicked on the intranet, and away we went.
You know, so a really good example of, again, of what people say and what they do can be really different things. So you really need to balance that out. So to avoid this trap, I always, and I really strongly recommend that you do this well, is to get out into the field and talk to, but also observe your product system or service users in action.
It's a really powerful way to understand your users' relationship with your offering and how they actually interact with it. Yeah, there's a question there from Anne-Marie around where does why now fit? And I think that is one of the big challenges of that trigger. And we will talk a little bit about some of this later.
But what I say is, with that so what, if you're working your way back up, like, being able to explain to someone really succinctly, like, so, like, you know, this is an issue, like, but why? Why now? Why should I act? So that so what of like, taking it back up the chain to try and explain to someone quickly, the impact of that root cause or that, you know, that problem, that's where that really, really helps. Yeah, great. Hi, and also on the topic, you know, and as I said before, there's many, many tools.
But one tool that a lot of people are familiar with, that's pretty cool, and can be quite useful, particularly in the early stages, is using a fishbone diagram, right? And it shouldn't be very hard to understand why it's called that when you see it. It kind of looks a little bit like the skeleton of a fish, right? And in this model, you've essentially got, you pick an area or a topic, which you could use as a head if you want. And then you have the spine of the fish.
And for each one of the major areas that you're going to be looking at, you can have a thematic area. And then you can run a brainstorming exercise to generate possible root causes. And some of that can be intuitively resonating, resonate with people, but also it can also trigger further investigation, but it's a good place to get started.
So if you look at the, you know, the diagram, it's just a really hypothetical example of it, but you'll see that there are some different subject areas there, again, looking at the topic of burnout, and there are some different domains and some different ideas that have come up. If you want to use it, some things that you could do is you start by identifying the topic, what you want to explore, you decide on what a suitable set of themes were, or you could let them bubble up, they can vary during the session. And you create those as the main bone lines.
And as you brainstorm ideas, and again, going back to what we said before, ideally, you know, the more diverse your group is, the better. You want to list any potential causes of problems, and you put them on points on the bone. And you can represent them in a diagram form, like the one that's shown on the screen.
And it can really, when you see it all together, sometimes it enables you to go, oh, actually, this really stands out as the most significant thing, or this one thing here we need to investigate. And it's just a really good way, I guess, of getting the ball rolling. In the days gone past, when I used to run, like, I think it was full day structured problem solving training, we used to break people up into groups and get them to spend about an hour working on this, they would come with a particular problem, and they'd work on this in small groups.
And it was a really good way to just brainstorm and get those ideas out and begin to just progress it, the thinking along. So, that was awesome. And just very quickly, I'm conscious of time, but very quickly, just a few things about that.
And that diagram that I had up, I actually created that using AI. And some people obviously may really dislike that, some people might like it. But sometimes when you are wanting to workshop things in a group, it's good to have a bit of a straw person, like something that they can latch onto and critique.
So, you know, if you don't like it, that's fine. But that could be a useful starter for you. In that version that you saw, the AI actually came up with the different headings as well.
And where I see that could be potentially useful is actually something which could combat group think, right? Because you could prompt the AI to particularly try and take perspectives. And hopefully, you'll get some ideas coming out of that, that you may not have generated yourselves. You can use standard categories.
So, there were some on the screen that you saw there. But also, if you're not sure, you can start with the go-to ones of people, process, environment, for example, or tools. And as you go through the process, you might want to decide to tweak things around, and that's okay.
You can also use those five wires, if you want, during the conversation to probe a bit deeper and get a bit more clarity about, actually, is this just a symptom, or is this the cause? And you get a bit of, it really progresses thinking that way as well. I think having that visual really helps with telling the story. And now I've got a picture, you know, so what? What are we going to do about it? How do we then talk about framing it up? And so, that talks about common challenge number five, which is struggling to tell your story.
And so, one thing as consultants, we often work alongside subject matter experts, and they normally know more about a topic than we ever will. However, a really common challenge we have is that we know this is an issue, but we're struggling to get traction. And so, my response to that is often, we're solving the wrong challenge.
So, the design challenge isn't, what could we do about X, this really thorny issue? It's, how do we create a decision? How do we get investment now? And how do we do whatever it is, or, you know, spend the time positioning for that? And so, my tip for that is that you must be able to describe your issue with any key context and the impacts in a sentence or two at most. So, you can have more than one of those. You can have sub ones if you want, but you really need to be able to put your main problem on a t-shirt.
So, really think short, sharp. And so, going back to that silicosis example. So, one of the things that really shifted the dial in terms of the messaging was that we created a point of reference to well-known issues that are regulated.
So, things like asbestos, deep sea diving, you know, things that we know and accept as regulated. You could then create this sort of mental model where it's like, oh, maybe it is okay to also regulate this incredibly harmful thing. And so, just simple things to try and understand why people are struggling to make a decision, which is often from really valid reasons, like we don't want another piece of red tape, we don't want more cost, etc.
So, just trying to take that view about how is this message going to be received and how do we then position the right message, solve the right challenge. Yeah, 100%, you know, defining your problem is only sort of part of the challenge. You know, you do need to be able to communicate it really well.
And so, as you've gone through the process, you've probably gone through a bit of a mental process in order to get to the conclusions that you have. But the people you're presenting your ideas to, they haven't, right? And so, you're going to be wanting to think about how to communicate in a way that essentially takes them through the journey, you know, trying to really understand the rationale and how you got to where you got there. And I know a lot of people find it frustrating, they put a lot of work into something, create these really well-thought-out documents that end up just sitting on this shelf somewhere and don't get the traction, and that's really disappointing.
So, I want to move beyond that. So, a few things that I thought could be quite useful, just a few tips from me here. One is to use your organisation's standard format for expressing information unless you believe an alternative is required.
And I'm open to alternatives, absolutely, I think that can be a really good thing to do. But what you want to make sure that you're doing is if someone's reading your content, they're really engaging with the content and not the format. And sometimes when you're changing up the format, you know, they're having to spend headspace trying to interpret that, and so you want to minimise that.
And certainly as part of your package, having a one-page summary is a really, really good idea. We haven't talked about it, but one of the really common tools that get used in the area of problem definition is investment logic mapping, and it's got a really good one-page diagram that I like. And one of the things that's quite good about it, as well as helping you get really sharp problem statements, right, is it gets you to really kind of weight things, like weight your problem statements, and then you exclude the things which are kind of a little bit low level, right, so if something's only, you know, 5 or 10% of contributing to the problem, it might get, you know, removed, and so that helps to make sure that in the one-pager there's not superfluous, so it gets that attention really focused.
A final tip is in the plain language inverted pyramid structure, this goes, reminds me a bit of what Jason was just talking about, but just make sure that you've got your most important information right up front, right, and then you follow the explanation below that. So just think of one of those news stories where you've got some headlines at the top, which kind of give you the real key messages, and then it gets expanded. Just make sure that if all your reader sees is that initial bit, it really grabs them.
Yeah, couldn't agree more about the importance of storytelling. It's such an important skill for good problem definition. So I always like to think of storytelling as it relates to problem definition around helping people paint this kind of mental picture of the issue that they can carry with them in their head and relate to any or all parts of the project.
For instance, you know, if someone who has absolutely no problem paying their energy bill, it's going to be very hard for them to empathise with someone experiencing energy poverty, right, but bringing some of those stories that you've gathered through your field work into the organisation and allowing them to understand or hear and understand and kind of soak in those allows them to develop some empathy with the challenge, and as I experienced in this particular piece of work, develop a real personal attachment to the issue. We included a few suggested story frames in the attached slide, which I think you're looking at now, but my personal favourite one is the design thinking story structure. It's formed a very, it's a very simple structure, but it talks about we met, which is a quick user description, you know, who did you talk to? We were amazed to discover, which is the standout observation, what was the piece of information that really stood out for you, kind of made you mentally go, aha, you know, or that's interesting.
We wonder if that means what was the resulting insight from that piece of information that you observed, and what it would be game changing to, so articulating what a great outcome would look like. What's the vision of a great outcome? That's cool. All right, team, we're coming to the end of today's session, so it's gone by very quickly, but before we move on to questions, Jace, Jeremy, is there anything else that you'd like to add? One last tidbit, perhaps? I did talk about it, but I really think the benefit of going down to first principles, so really work to go all the way down to articulate why your organisation exists, what you're doing, and then work your way back up to the problem, so you can, you get a scoped problem definition, but you do have that understanding of the context, which you can then, you know, either include or exclude, but you can then have a really good basis for your problem definition, which, you know, comes from the analysis.
Yeah, cool, cool, nice. I guess for me, it's, you know, it's that idea, I guess, between stimulus and response, there's a bit of a gap, and what you choose to do in that gap, and I think your brain is going to just jump you into solutions, it's the default pathway, but it's about trying to interrupt that, and just be really conscious to say, tell yourself at that time, actually, despite what I'm feeling right now, I actually don't have all the answers, and I won't understand the full picture, and unless I do some more work, so I need to slow down, and really think through the challenge, and I think that's probably the number one thing for me. And my last comment is, again, reinforcing the importance of adopting and maintaining that user focus.
It's so critical for successful problem definition, you know, and my favourite way, as you know, is to get out into the field, and gather those user stories, and use them to help define the actual challenge you need to solve, instead of the one you think you need to solve for. Okay, team, that's it, five problem definitions, and what you might be able to do about them. We're going to now jump into questions, not solutions, but before we do, we'd love to catch up with anyone who's facing a gnarly problem, and help you define it.
Right, let's get to those questions. Okay, first question that came into us in the registration process was, a number of people talked about limited time and resourcing, so a question is, what's the minimum viable approach to problem definition? Who'd like to grab that one? I mean, I love, I love, it's actually really good that you mention it, because I just love the whole concept of MVP, you know, why make big bets when you can make smaller bets? It's about, you know, your minimum viable product, and it does depend particularly on your situation, but if you have an ability to take an iterative approach, like in my world, with business change, often this is something which is realistic, and it can be done. It's good to really start smart, and if anyone was listening to my chat a few months ago with Darcy Meltzop around this, we talked about it.
So starting smart, making small moves can actually help build the capability team, get momentum, and help get evidence. So if there is a way that you can do things in an iterative way, which enables you to collect some data, and then you can inspect it, and adapt, and then move on, that's a really good approach. But also I would say, you know, we're pretty good at judgement.
For each situation, it's going to be really different, and it depends on, I guess, the stakes, right? Like how big a deal is it? So for some problems, it may be as simple as just, you know, getting people together for an hour or two, and just working through some structured exercises just to get you going, and that would constitute a MVP, but for some of the more chunky policy things, you know, you do need to do a bit more than that. I know you can just commit a little bit of effort to getting something moving. Like, you know, there's often a, I don't know if fear is the right word, but a resistance to bringing people into that problem stage.
And I do think, you know, you can do it in ways that don't build up the expectations too much, which I think often drives that hesitation. But just starting that process of committing to we're going to spend a bit of time working out the problem, we're going to run a couple of user groups, we might do a survey, like just start, I think, is probably the big one. You may not be able to commit to full co-design, but just at least the commitment to we're going to spend a little bit of effort on problem definition, maybe all it needs to get some things going.
In design we have a name for that, it's called having a biassed action. So basically what it talks about is, and I think it's a really great mindset to adopt in this particular instance, but it's essentially saying, if in doubt, act. You know, so if you're not sure of your problem definition, you could try it out on a small sample, you know, get some extra feedback from people to help refine it, because otherwise you run quite a serious risk of never starting, you're never going to be in a position of having perfect information.
So you need to try and test a few things, and if you're not 100% sure, or not even 100% sure, even if you're not 60% sure, you can always get a little bit more information, but don't wait until that 100% because you'll always be waiting. That culture thing around being, it's okay to reframe your problem as you're going, so getting, I guess, being explicit that you might need to do that and just being okay with it, I think, helps as well. Like, we're not going to get this perfect, you know, with a couple of us in a room, you know, it's just, you're going to have to refine it.
Yeah, and if you take a leaf out of, I guess, something that's a little bit different, if you think about, say, software development, well, you know, one thing I learned in that field is that user requirements evolve over time. So what a person thinks they want at the beginning is actually quite different over time, and then you're in an environment which changes, right? So just as you guys are both talking, have talked about earlier, you know, the world changes, requirements can change, and so, you know, it's about having that adaptability and faith in the process, and I guess it's a bit like having a growth mindset to problem solving. Okay, we've had, gosh, we've just had a screen flick up with a whole lot of live questions, there's a lot in there.
There's a question there from Diego, do you have any advice for navigating situations where investors prioritise outcomes over a deeper understanding of the problem? Yeah, look, I might take this one, Diego, hopefully that you'll find this useful, but I think the key thing around this situation is that it's, to quote an old saying, it's like, measure twice, cut once, and I think the situation here is that if you prioritise outcomes over knowing what the problem is first, you run a really much higher chance of having a miss at the end. So actually, reinforcing for those investors that you need to take the time to establish what it is to have the problem clearly defined, while it might take a little bit of extra time upfront, will actually result in a lot less time and expense and resources down the track. So it's not an easy one to have the conversation with.
In fact, in a previous role, I tried to have that conversation, they weren't investors, but I had people that were responsible for the project that I was assisting. And they thought they knew what they needed to do. And so they actually pushed the outcome, they pushed for the solution.
And in the end, what I did was I actually had to say, okay, well, you go for it and see how it pans out. It didn't work. And so then they came back to me and asked for some assistance to try and redefine what they needed to do.
You know, it was a harsh lesson, but sometimes I like to use that story as an example of why it's so important to have a good, well defined problem to start with. Because if you jump to outcomes or solutions, you're in a real situation of having a big miss. Hopefully that was useful.
I noticed there was another question up there from Eamon about an organisation facing a big budget cut by their funding provider, but the expectations haven't seemed to change in terms of what they need to do and what tools can they use. So you might be interested in, we recently did, I was involved with a couple of recent webinars. One was about efficiency unleash.
Another one was about continuous improvement. They are good resources that you could have a look at. They're on the Alan and Clyde website.
So that's that. But certainly I'd also be more than happy to talk to you after this about it to talk about the tools. And in terms of what we talked about today, though, if I go back to that six boxes tool, that certainly is something that you could bring into the conversation.
But in terms of the bigger picture, there's all sorts of different tools. So I'd suggest we get in touch. Now there's a question around working backwards from a political decision to the narrative that supports it and any top tips for reversing the problem definition process to make a solution seem authentically amazing.
I think a lot of that depends on how cynical you want to be. So there is ways, especially from that storytelling slide, to take whatever solution and really cynically back engineer it. I think that the risk of that is you end up with an internally consistent cabinet paper or whatever that tells the story and you can't really argue with the assessment criteria.
But it's not potentially going to solve the right thing and grips things. I think there's one part is that you can use this process to make what you are already doing better. But the much better one is that if you do manage to have that conversation to just, even if it's introducing the next problem or the thing as well, to just try and get that commitment to working on the things that are actually going to shift the dial.
And so doing things like getting the user experiences, getting a bit more information, getting some more data to explain why, yes, we can solve this. And that's another design thinking tenet is like, don't say no, you say yes, and or some of those sorts of things. So it is a really tricky one.
And as Griff talked about a lot, jumping to solutions is really, really common. So the more you can get into that problem stage, the more you can bring in the user experience, the more likely you'll get a challenge or a problem that will be compelling to that decision maker that you might be able to either expand the solution or do something in the future or do something alongside. There's a question here from Garrick.
Garrick asks, how to deal with a situation where the CEO or a minister is a solution jumper, and has essentially decided on a solution before going through the process? Yeah, I think we touched on that a little bit, but I think it's common. I think you do owe it to that person to try and be as free and frank with their advice, even if you disregard it. And then I think the key thing is like, if you do have compelling data and compelling information and user experiences that can help to shift, I think that's often the way.
Like bring something new to the table. How do you create that, what do we call it, the oh shit moment of like, yeah, we found this data, we found this user experience, we have this great narrative, whatever it is, that can help to twist the lamppost, go around the other side a little bit, get them to come on that journey. But bringing them on the journey is absolutely key.
Because we've all had, I mean, I certainly have had things which I've adamantly been committed to, and thinking, yeah, this is the right way. And then someone's come and somehow I've discovered information, and then I've gone, oh, actually, I need to pivot here. And maybe I'm unusual, but that's happened many times in my life.
And I'd like to think that people of the colour of our politicians, I know that there's all sorts of different drivers and things. But you know, I like to think that everyone's attitudes will shift and mature and so forth. And maybe it's just the fact that they seem fixed at the moment is because the ideas or whatever hasn't been presented in the right way.
So, you know, I do think that there is a duty to provide that full and free and frank advice. I also just in terms of that similar comment before, just about the enthusiasm where they're kind of told, well, this is what we're going to do, and you have to kind of reverse engineer it. I am very conscious of the fact that people are far more connected to ideas that they have sort of generated.
If you just get told this is what you're doing, so I totally understand how that undermines motivation. And so the question is, you know, for me is like, well, is there any scope for there to, you know, any options in there where you can have more of that creative connection where they can have a degree, right? Maybe there's a scope and saying, you need to do this, but maybe you can be done different ways. And, you know, you can use the people that they can actually, you run the process in a way that at least they can get some buy in there.
But it is a really difficult challenge, I accept. Yeah. Damien's asked about could the five why's be adapted to why, why, why, why now, why not? And I think, so absolutely, like that makes a lot of sense.
And with that t-shirt comment around how do you make this problem definition, like snappy and sharp, like that why, that what's the trigger right now, you know, my legislation is outdated. So, you know, it's like, what's the impact? And why are you telling me about it now? Because I've got 50 other things I could spend that time and effort on. So that why now, that trigger for action is super, super important.
And it's often one of the really key things to try and get, you know, the problem definition, the decision maker over the line on so really, yeah, so do agree. Yeah, that's great. And there are other variants like there's the, what was it, five W's and one, you know, like the who, why, where, what, when, you know, there are different things you can use as well that can be helpful.
And happy to talk more about those if you want to reach out to us. Hey, there was also a question from someone called Ronald, who's after literature sources on the models discussed. So I can't necessarily talk to all of them.
But I do know certainly for the ones that I discussed, as I said, the six boxes has some really strong backing in terms of science and so forth. And if you go to that site, sixboxes.com, you can find some really, really strong stuff there, which is fantastic. The fishbone diagram has been around a really long time as well.
I don't have any sources right off the top of that, but it shouldn't be very hard to find a little bit more about how it evolved and where it came from and so forth. And particularly on the line of sight, Ronald, I'd be more than happy to have a chat to you about that. It was more of a kind of a practical tool that's been developed over the years of design practise.
So very happy to talk to you about that and how I've applied that in a number of instances and give you some tips about how you might do that at your end as well. The griff line of sight tool. I'm not sure it's a griff line of sight tool, but it's certainly one that's been, you know, developed over a number of years by and used by different people.
So yeah, cool. All right. Look, I think that's probably a good place to wrap up.
Thank you so much for staying on and for all of your thoughtful questions. We really enjoyed having those. This is the kind of discussion that makes these sessions really valuable to everyone.
So for those of you that did throw us a question, thanks. It was much appreciated. For those of you who are joining the Credible Evaluations webinar, I hope you enjoy the session.
And remember, if today's discussion sparks any kind of thoughts or thinking for you on your own work, we're always happy to continue the conversation. Please just reach out. Thanks again for joining us.
We really appreciate it. Have a great rest of your day, everyone. Ka kite.
Ka kite.
