Problem Solving & Kobayashi Maru
Over on my post Do constraints help problem solving, Aaron asked:
I’m currently completing a dissertation titled Development in Product Design is driven by a response to changing constraints rather than innovation for my 3rd year BA Product Design course. You have stated that constraints can be eliminated on purpose, I can understand how they can be created but not eliminated? have you got any example of this in practice?
The best attitude when trying to solve problems is everything is negotiable. Just because someone says the car they want you to design must be red and ten feet tall, or done by Friday doesn’t mean it actually needs to be those things. Most constraints people give are made up: they haven’t been rigorously examined to find the real boundaries.
Maybe instead of being ten feet tall, what they really want is a car they can fit comfortably in, given that the client is Shaquille O’neal.
And perhaps it’s not a red car they want, but just a car that looks cooler than their neighbors car.
Or instead of it all being done Friday, only one important part needs to be done, but the rest can be done by Monday.
People confuse being specific with being accurate. Having details and numbers doesn’t mean you understand why those things are the right choices.
The challenge in creative work, especially with clients, is how to explore their constraints without annoying them. And then get them to happily acknowledge these are the true problems, rather than assuming their description of their problems is sufficient. The reason why so many projects fail is the lack of this skill on all sides: clients, executives, designers, engineers and customers all stink at this process, and dismiss it as irrelevant.
The fancy word for this is requirements elicitation. But it really just means thinking hard and carefully about requirements, understanding they are a kind of design unto themselves. Someone has to diligently sort through those that contradict, and identify those that are poorly formed or unnecessary. Prototyping and sketching helps sort this out, but that’s just part of the process.
The best book I’ve ever seen on this is Exploring Requirements, By Weinberg. It should be required reading for anyone who solves problems for anyone else.
But the big problem is, of the few phrases more boring in this world than project management, requirements gathering is definitely one of them. It needs a slicker name. I hate jargon but I’d be all for something snazzy that gets them to care more about this kind of thinking. (Require-magic? Constraint-O-Rama? Hmmm).
Sometimes you can find a way to make two different constraints reduce down to one, making the problem simpler to solve. A constraint (e.g. requirement) might not be eliminated, but can be bent, shifted, twisted, rephrased, or entirely manipulated (See Kobyiash Maru) to serve your purposes.
A favorite example: for decades the problem with bringing the internet into developing countries was the expense of digging tunnels to put in power, phone and cable lines. The advent of cell phones, where towers are built above ground and no wires are needed, eliminated the constraints around digging and cabling. For many people in the world today their first phones, and first web browsers, are cell phones. A constraint was entirely eliminated by design.
Good ideas can sometimes eliminate seemingly immovable constraints.
I apply a similar heuristic, although I delineate between physics and agreements. Too often we confuse constraints in the latter category for the former, so to set the record straight: you can’t negotiate with physics. You can and arguably should negotiate agreements on an ongoing basis.
As you also point out, some physical constraints are bound by technology or simply paradigmatic, and we equally often conflate the result with the method, or rather what we want to happen with how we think it can be achieved. When we isolate the goal, many more candidate tasks often come out of the woodwork, or at the very least.
In giving this category of problem some careful thought over a few years I have found that our business language tends to muddle the ideas of goals, tasks and targets in a way that confuses the autonomy of the actors and does not account for the inherent complexity of any particular activity.
Consider that a goal is just an abstract state that is desirable. It may be my goal to become a multi-millionaire. The abstract task, the method by which I will become a multi-millionaire, has more permutations than there are atoms in the universe. If I introduce a target, that is, two million dollars (to qualify as multi) by the end of next week, that sharply cuts the possible methods by which I can acquire the money. And then there are side effects. The only methods I can possibly conceive of acquiring two million dollars by the end of next week carry with them a high risk of failure and/or a number of inexorable side effects (like law enforcement). So it raises the question: what was I trying to do again?
Ack, second paragraph:
Great post Scott.
Put slightly differently: when many people make a request, they are often actually proposing a solution to an unstated problem. (“Can you build me a red car?” in your example is a possible solution to “I need a mode of transportation that gets noticed.”) A sophisticated client will strive to state the problem, while a sophisticated designer will be able to perceive that the solution isn’t the true request.
The word I’ve seen is “Discovery.” It’s sexier than “requirements definition,” and theoretically comes before it, but the new word doesn’t solve the underlying problem ;).
I just spent an hour thinking over what you’ve written in this post, and it’s not just because I’m a Trekkie.
Discovering the real problem behind a requested feature is something I must deal with every day, being in sales and in project management, and being interested in NLP, too (NLP has practical tactics and hands-on solutions for discovering what really lies beneath a request).
I also thought of some pretty creative ways to rescue Kobayashi Maru, not get myself and my crew killed and not start a war with Klingons – which might actually work :-)
What I’m saying is: thank you for a great post.
Awesome post, dude! One of the things you are explicitly taught as an attorney or a physician is that what a client/patient *tells* you is the problem they need solved is only the beginning of the process of figuring out what they really need. Corollary to this that I have learned is that one of the most valuable rhetorical stances to take with someone whose needs you are exploring is an iterative process of listening, and then restating using language like, “Am I understanding you correctly that you want/need X?”
Good post. I’m a Weinberg/Gauss fan as well. One technique that helps soften “constraints” is to reframe them as “assumptions”. People get less grumpy when you challenge their assumptions.