We often have good ideas about things to improve and how to improve them—introducing a new tool, changing the way we do something, adjusting a procedure, and so on. But in a work environment we usually can’t make unilateral decisions on things, so the next step after having the idea is to persuade some other people that we should do it.
And when persuading people of new ideas—whether verbally or in written documents—it’s really important to be clear about the problem we’re trying to solve. There are lots of reasons for this.
If we’re proposing a change to the way people work, then being clear about the problem is important because (generally speaking) people don’t like change. So in these circumstances, not only is it important to be clear about the problem, it’s also important that the people subject to the change agree that the problem really is a problem. There are many, many times when I’ve proposed—and implemented—changes in teams’ working practices, and it only works when those changes are based in problems people agree they want to solve. These problems might be about unrealistic expectations, inability to learn new skills, or something else. Each team is different.
If we’re talking about, say, making a technological change, or some other less sensitive issue, then there are other reasons to be clear about the problem we’re trying to solve.
One of these reasons is that during any debate, alternative solutions might be proposed. These might be slight adjustments to the original idea, or something very different. In any event, it’s entirely possible the alternative idea doesn’t actually address the problem in question. But if we’ve not stated the problem in the first place then that won’t be obvious to anyone. We might not even have been clear or honest with ourselves what the original problem was, in which case we’ll be left expressing frustration with the alternative idea but not being very articulate about it.
Even if we do think we know what the problem is, and even if we think it’s obvious, it’s still a good idea to communicate it to others. If we don’t there’s a danger they will look at the idea and think it solves a slightly different problem. And then, again, we open ourselves up to unexpressed frustrations—people debating the merits of a solution without realising they disagree on the problem it’s trying to solve.
And that brings us to one more reason to be clear about the problem: others might disagree disagree that the problem you see is the right problem to solve. They may see things differently from you; they may have different experiences, or just work differently; they may spot that you’ve made one or two unjustified assumptions. This is no bad thing. Getting aligned with people is important in order to work together successfully.
2 thoughts on “State the problem for any solution”
First develop the problem, and then the solution, and then check whether the solution actually (and how well) solves the problem.
Otherwise we probably will be developing a great solution for the wrong problem.
“Develop the problem” is a really useful phrase, and new to me. In the world of product development (these days) this is what the “discovery” phase is supposed to do. But “develop the problem” is a way of expressing the idea more generally. Thanks.
Comments are closed.