Understand the problem. Truly.
Picture from Gerd Altmann at Pixabay

Understand the problem. Truly.

It is highly relevant to truly understand a given problem before you determine a solution. This sounds totally obvious if not even a bit silly. How would anyone be able to work on a problem that is not understood? But it becomes less silly if we re-phrase things a little bit.

So far the wording implied a somewhat binary view: Either the problem is understood or not. But in reality very little is truly binary. So instead we could say that the level of understanding of a problem is the primary driver for the outcome of the attempt to solve it. That still sounds pretty obvious (better than silly, though).

The next stage in dissecting would be to say that a problem needs to be understood well enough to find a sufficient solution. And here it starts getting interesting, since we basically have an equation with two variables.

The first is about being “sufficient”. Because of resource constraints most problems will be approached with the aim to apply only a “just good enough” solution. In my profession (software engineering) this usually means a quick fix rather than a clean approach with refactoring and all the other good stuff.

What I personally consider more impactful, though, is the “well enough”. Many people I have met so far, do happily go for the first explanation of a problem and consider it a sufficient basis for determining how it should be approached. But in most cases this means only that the symptom has been identified correctly. Neither has the direct cause for the symptom been found, nor the root cause. I see several reasons why people jump onto the “obvious” reason so eagerly rather than to dig in.

  • Different layers: Like in medicine the symptom, the direct cause, the indirect cause(s), and the root cause can be in different “hemispheres”. In business this could be customer churn, caused by bad customer support, caused by a missing link in a process, caused by misalignment of two separate organizational units, caused by personal animosity between their bosses.
  • Motivation and personal objectives: Unless people have a mind that genuinely strives for perfectionism, they will factor in their personal objectives to determine how much energy to put into something. And in most cases this simply means to invest as little effort as possible.
  • Importance not considered high enough: While the personal objectives point above is, at its core, about a selfish decision to optimize personal gain, this is about a perceived objective lack of importance. If I genuinely believe that something is more or less irrelevant, why would I bother (irrespective of personal gain)?
  • Happiness to have found anything: This is basically about impulse control. Rather than exert self-control and think about whether or not there might be other and/or additional aspects, people simply jump onto the first thing that comes their way.
  • Lack of knowledge: The difference to the happiness point is purely the motivation. While the result is the same, the reason here is sheer necessity, since people do not know enough on the subject. So they are just glad to have come up with something at all.

When you follow the line of argument, you will have the fundamental reason why larger organizations so often struggle to solve simple challenges in a proper way. Instead you will mostly see a myriad of changes that are applied, at best, with local optimization in mind. The latter, unfortunately, means that you are almost always moving further away from a global optimum. What good is it for a company if one department improves the financial bottom line of the current quarter at the expense of disgruntled customers that spread the word?

I don't want to advocate that nothing but perfection should be applied. But going for something that is just good enough right now, is a very different game, if you know what the proper solution would be. You have made a conscious decision and can take it from there.

Chris Ross

Gartner Analyst - Chief Marketing Officer

1 年

I make this point about ensuring a deep understanding of the problem almost every day to clients. Nice post.

Andreas Reuther

Making customers successful and building great teams

3 年

Nice work

要查看或添加评论,请登录

Christoph Jahn的更多文章

  • Unique IDs in programming

    Unique IDs in programming

    Most people have probably come across what is usually called a UUID (universally unique ID) while using software. UUIDs…

    9 条评论
  • Staff communication. Successful!

    Staff communication. Successful!

    Do you have the challenge that your communication does not reach your staff? People telling you "I never heard about…

  • The limits of conventional wisdom

    The limits of conventional wisdom

    In discussions you often hear things that fall into the category of “conventional wisdom” or best practice. I have…

    1 条评论
  • Legacy software: Better than its reputation

    Legacy software: Better than its reputation

    All the time I hear people talk like "this is legacy software". And they do that as if it were a bad thing.

    12 条评论
  • The conflict of values and goals

    The conflict of values and goals

    Compared to ten or twenty years ago, many organizations put a lot of emphasis on values these days. Many of them also…

    3 条评论
  • Finding topics for great conversations with your customer

    Finding topics for great conversations with your customer

    Are you also always looking for topics to have a good conversation with your customer? Why don't you let the customer…

    3 条评论
  • Thoughts on (personal) branding

    Thoughts on (personal) branding

    In recent weeks and months I have come across a number of online articles and posts that covered various aspects of…

    7 条评论
  • How to give a presentation

    How to give a presentation

    “Everybody who loves attending presentations, raise your hand! No one? Hey, come on. …… Still nobody?” Ok, so why is it…

    14 条评论
  • You are not faster with an 80% solution

    You are not faster with an 80% solution

    When the schedule is tight for a software development project, one of the first things non-technical people…

    1 条评论
  • One secret of good demos

    One secret of good demos

    Nobody would argue that preparing a demo for a software product is not important. But one aspect for doing so is often…

    3 条评论

社区洞察

其他会员也浏览了