How would Socrates do as a Problem Solver?

This blog is dedicated to Socrates – and the method of getting to the essence of a problem by relentlessly working to strip the noise and focusing on the real ‘Why’ behind a problem. Do we always have the time and the ability to stay at a problem until clarity emerges?  Moreover, in the quest to get to the essence of a problem, do we run the risk of not thinking enough of the properties that might help in recognizing and describing the problem? In other words, is it always the best strategy to focus on the forest – what if the trees themselves are good enough?

And I don’t mean this as a metaphysical problem – these are important questions to explore.

Take a look at today’s world. VUCA describes it well (thank the Management Consultants for the acronym). Even as the VUCA rate (if there is one) goes up, it often happens that most enterprises cannot afford to throw the resources and time to solve for the essence of every problem – even more so for some of the large strategic problems ones. In fact, some of the large strategic problems often require in-flight transformation. Say, a company is changing its revenue model from the traditional Product (license fee) and Technical services (recurring revenues) to a SaaS model. This requires a gargantuan effort of not just re-defining the metrics (the easy part) but also re-imagining years of measurement systems and organizational culture even as both of these revenue models need to be executed in parallel over multiple years. Would this still make it a transformational program in the conventional sense?

All this begs the question – should we re-imagine problem solving from the classical Socratic method? Here are a few thoughts:

1. Learn to accept and work with limited information: Data sets will be messy, incomplete – and beyond a point, it is futile to expect clean data: let that not be a constraint. Digital marketplaces (e.g. eBay, Amazon) deal with this problem all the time. As they onboard hundreds of products on a daily basis, it is no longer possible for humans to classify and tag each product to the right assortment category. Intelligent systems ingest a variety of incomplete, difficult to standardize attributes (e.g. product description, data sheets, images etc.) to classify products into the best-fit category. Explore AI based methods to build robust, learning systems that ‘learn’ to work with messy data.
2. Don’t look for the most accurate answer: The world was never deterministic – it only took us a long time to accept the fundamental fact that nature was always probabilistic. And so is the solution space. Instead of waiting to get complete clarity, build probablistic solutions with a risk factor and allow for a continuous improvement mindset. This is a remarkable departure from the IT-led application development which is based on clear requirements. Only it is now we are beginning to accept that the real world doesn’t operate that way. In the Customer Service Organizations, reducing the Case MTTR (Mean Time to Resolution) is a key focus area for most organizations. This is a classic case for Augmented Intelligence Systems where a combination of machines and humans can make a big difference. The process of case triaging and resolution recommendation should be automated – with a risk or confidence factor, which in turn determines the human intervention points. This is a journey – as a starting point, deploy with algorithms start with a certain accuracy threshold and learn over time. Establish a strong cadence of refreshing the algorithms as the system learns over time. And in a virtuous cycle, these algorithms are continuously refined and based on the accuracy levels (i.e. risk assessment), the workflows for human intervention can be calibrated.
3. Given the current state of business, what is the next best action: The strategy consultant will paint a vision – be very suspicious when you hear the word ‘North Star’. Expect  the consultant to slip away around this time. In reality, the challenges are mostly about: given the current situation, what is the next best action out of a finite set of possibilities? And how do you know if you did indeed choose the right action? Much like moves in a chess match. Customer journey mapping is especially suited for this approach. Everyone wants a long-term customer journey roadmap defined to be able to invest in the right retention and growth strategies. Recall the days of CLTV (Customer Lifetime Value) as the key indicator that used to determine customer level engagement strategies. In a world of increasing choice and fickle customers, CLTV needs to be re-thought as CNBA – Customer Next Best Action.  Much like a chess move, this action recommendation should be probabilistic based on all available information. This should be coupled with two very important actions:
   1. Minimize the risk of a loss and leave the room for an upside:  The best chess players do not always play the safest moves – they take a series of calculated risks that not just minimize the losses but leave options to make big plays. The smartest marketers are replacing expensive 1-1 marketing with experimenting different digital offers (e.g. value-based, personalized bundles) and closely look for response rates.
   2. Build feedback loops into your design all the time: Just as the best chess players are willing to throw out their strategy and think afresh with every move by the opponent, be ready to change course based on customer or market feedback. In an omni-channel world, there are multiple ways to study customer behavior – even in B2B environments. Companies need to be very thoughtful of looking at multiple signals – both strong (e.g. telemetry, Service Requests) and weak (e.g. time to respond to a renewal proposal)
4. Portfolio vs. funnel approach: The traditional method of designing large programs and then putting them into a funnel (I.e. budget constraint) seems archaic in today’s environment. The overheads of this approach often results in confirmation bias – with middle managers figuring out ways to protect their budgets – which is mostly why fail-fast is a theoretical construct in most organizations. It may be better to think of a portfolio of quick turnaround ideas (6-8 weeks) and spawn mini-projects that create Proof of Production (POP) and not POCs. Pulling them off is easier said than done:
   1. Needs a strong engineering mindset: the path to scaling a POP should not be torturous. Designing for scale is just one part of this:  there needs to be a platform environment that enables rapid deployment (e.g. Google’s Kubernetes) and platform tools that enable easy deployment of software (e.g. Application Containers)
   2. Needs a strong Design of Experiments mindset: As multiple approaches are tried out, there needs to be a Field Testing platform (e.g. A/B testing) which allow for testing out solution alternatives in a rapid, rigorous way.

This is certainly not exhaustive – hopefully,  a good place to start. Above all, you need a decision-making architecture that is built on a bias for action; creates options at all times and has a keen quantified sense of risk.