there’s a distinct difference between a solution-based approach and a problem-based approach. let me give you an example of what i mean.
i was watching a show on pbs that was talking about battleground mobility â€” from the time of egyptian chariots through to today’s modern, technologically advanced tanks. i found the bit about the development of the tank to be quite interesting.
during the first world war, trench warfare had become the status quo. miles and miles of fronts in europe and russia covered in 6ft wide trenches. it made fighting a conventional land battle extremely deadly, and the allies were finding out just how difficult it would be to take down the german war machine. until a technologically curious winston churchill had an idea.
churchill had seen armored cars and thought about how they could be implemented to provide cover for infantry forces whilst they attacked the german trenches. “little willie” was born. after some unsuccessful attempts where “little willie” ran into a few ditches and couldn’t climb its way back out, it was modified into “the flying scotsman” which solved those issues. the mark II was utilized to some success on the battlefield and helped to spur the innovations which have led to today’s marvels of engineering.
the developers of the first tank took a problem-based approach. problem: “these 6ft wide trenches are literally killing us!” to answer that problem, they needed an armored vehicle that could ride over muddy grounds, that could get itself in and out of ditches, and could traverse a 6ft gap in the ground with no issues. it was that approach which led to the development of the british mark I, mark II, and the entire lineage of tanks from every nation around the world. but if you had asked the generals in charge of fighting that war what their solution would be to winning the battle, they’d most certainly have said, “we need more troops! every man that jumps out of our trenches is getting killed.”
you’re asking the wrong question when you take a solution-based approach. “what do you need?” it lends itself to the wrong line of thinking because people don’t always know what they need, they only think they do or â€” worse yet â€” think they know what they want. as consultants, when we take a solution-based approach, often times we end up developing systems and solutions that provide little to no value. the best way to combat that is through approaching clients in a different way.
don’t ask what people need. don’t ask what people want. ask them what they do. interview them, and interview a handful of them. what do you do every day? what reports do you have to provide on a regular basis? what outcome are you looking for? what tools do you have available to you right now? how long does it currently take you to accomplish your tasks?
after you interview your clients, cross-reference what they gave for their answers. you’ll find the problem underneath it all. and from there â€” knowing the problem and all the other factors that may constrain your solution(s) â€” you can start to formulate a strategy for the way ahead.
just look out for the ditches.