solution-based approach vs. problem-based approach


image by flickr artist, Dunechaser

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.

,

  1. #1 by Joe T. on 16 August 2010 - 8:46 am

    Reminds me of something Henry Ford said: “If I asked people what they wanted, they would have said ‘A faster horse.’”

  2. #2 by Gianpaolo Baglione on 17 August 2010 - 2:01 am

    It’s a fine line. it depends on what you’re selling, really.Consultants sell services, so the solution really is the product because people are adaptable. On the other hand, if I am selling you a widget, Mr. Customer, my widget can really only do so many things right now, no matter how flexible my company might be. By your analogy, Churchill realized he had the wrong product, not that his service was inadequate. He didn’t need different bodies, he needed different widgets .

  3. #3 by john on 17 August 2010 - 10:57 pm

    i think the approach should be the same for either consultants or for ‘manufacturing’.
    consultants sell people and their abilities — or they should at least. that’s where i feel the trap is. it’s easy to produce some kind of a tool, program, or capability for one client and try to market it to others — without fully understanding what their problem is. maybe that is indeed the best mission analysis tool available in the marketplace, but is it the right mission analysis tool?
    and for manufacturing, i see it the same. there is no perfect computer. there are different computers for different people. this TED talk from malcolm gladwell explains it. if you set out to do one thing — build the best widget possible — you’re going to fail because you’re not understanding the problem. that, being, not everyone wants the best widget.

(will not be published)