Ness Point of View
My company is in the business of making better software and making software better. Every customer I talk to is in the midst of some initiative to have new/better/latest software solutions to offer their own customers or employees; they all expect an “Uber-like experience across the channels” if you can forgive my predictable reliance on the common parlance du jour. A regular frustration for those tasked with the ‘make our software better’ challenge is that everyone in the organization is a critic, but few ever get together to work on the answer – or even declare in a crisp, thoughtful, actionable phrase what exactly is the problem. What, specifically, needs to be better?
Too often I see activity (apparent action or maybe just Brownian motion?) geared towards a “solution” far in advance of nailing down precisely what the problem was in the first place. Our mothers could tell us about such folly. They popularized tried and trusted phrases that are part of the vernacular for good reason and help me here take a run at this issue: “Let’s not run before we walk, everyone.” “Let’s count to 10 before we react.” “Let’s not judge a book by its cover.” (We should open it and do some reading to find out more about what the book has to say).
And then there is this musing from a grand-daddy of perceptive insight (A. Einstein):
“If I were given one hour to save the planet, I would spend 59 minutes
defining the problem and one minute resolving it,” Albert Einstein.
(It’s not worth definitively sourcing that one to him in this brief note. The rest of the Internet will help with that).
It appears to me that changes to software are frequently made without first looking at the problem from all the angles which should be considered, before making the best (or least worst) decision on what to do next. There are many human traits that work against getting it right the first time, and companies should work methodically towards not allowing that wrongness to happen.
If you ask one person to resolve something, they are understandably predisposed to use their own experience, knowledge and skills to fix it. On a small scale that is often enough. But, if it was to launch a new account sign-up process for a mobile banking platform across the globe, you would never think that leaving one person to do it all was a good idea. They would be limited by the breadth of their own ability to consider all the challenges involved in such an endeavor. You need a cross-functional group of people to make a thoughtful plan and execute it with checks, balances, tests and validation of assumptions along the way. And then, you would quietly ask some unbiased users to double-double-check for you. Everyone can agree with that, right?
The main reason another/outside perspective will almost always help improve the outcome is because insiders don’t question the problem definition the way an outsider does. Being outside the system frequently helps the outsider view the system in a different way that the insider can’t imagine. Outsiders are capable of reframing the problem in a way that frequently brings new energy to the fun part of solving it. A confident outsider should bring the ability to ask “why?” in all the right places. It is often the killer question and can often leave the progenitor of a thinly-described problem statement floundering.
One powerful story which communicates well the need to reframe the problem is the ‘one about the Titanic:’
We often cannot see clearly what is in front of our very eyes, because we think of a thing in one way rather than another. When the Titanic was struck and lives were in danger, there was a mad scramble for the lifeboats. There weren’t enough of them, and 1500 people died. Logic declared: “Need to stay afloat. Lifeboat”. Passengers went straight to the Lifeboat solution rather than considering other ways of staying afloat. It’s easy to say “more haste, less speed” a century later, but if some calm and focused thinking had prevailed, many more lives could have potentially been preserved by staying afloat on the 400-foot iceberg which was next to them. It was flat, high above the water and floating. The Titanic took nearly three hours to sink and could have been steered alongside the iceberg where the cold (but afloat) passengers could have huddled together penguin-like and waited to be rescued. Us humans have a problem with “functional fixedness” where we can’t see beyond the fact that icebergs are a deadly hazard to boats (maybe more so after the Titanic, of course) rather than a massive floating lump of ice.
The team I am part of spends a lot of time with businesses some way through the ubiquitous digital transformation. These businesses are challenged from all sides with better/quicker/easier ways for customers to access the product or service they offer. A calm and thoughtful disposition is required (see Titanic anecdote above) to find a winning way. Much is made of where to start.
Doing the basics brilliantly is hard to argue with. And taking a customer centered view another.
However, one hundred years of pushing product out to the market is a hard habit to break for businesses built on that very bedrock over many years. They have no embedded reference behavior for listening and tweaking in a conversation with the audience – and that’s somewhat out of kilter with the social media narrative of our times. Financial services in particular have done very nicely from a combination of a) trust in the old school, b) customer inertia and c) lack of easily-comparable alternatives. But, the Internet has chewed through all that. Companies needing to transform must accurately define their problem statement or risk the ridicule of too many ill-fated solutions launched to “see what sticks.”
Which brings us back to spending time upfront defining the problem properly to get the best solution translated into easy-to-use software which feels “right” and delivers immediate value and utility to users. And the best, most-used solutions generate incredibly valuable usage data, which help companies measure and learn what to do more of – and what to shut down and do less of.
If you are serious about fighting off competition and staying ahead of the game, then defining the problem properly is important. To do it you need to have considered:
- What do customers think of the existing solution? (Have they already told us how to make it better, and we just weren’t listening properly?)
- What do our employees know needs to happen to make the existing solution better?
- Which other solutions out there do it better? (And how can we incorporate some of that into our solution?)
- What trends and behaviors online and on mobile and in other countries are developing into the norm? (Do they already do it on WeChat?)
- What are we hoping to achieve here, and how do we measure it to double check our cunning plan
The problem with most software is that most of this hasn’t been considered. Do the considering and solve the problem. And then try and make it better.