It is disheartening to see so many problem-less projects, with a solution – be it a technology, a policy, a feature, an intervention or training – being developed before there is an articulation, common understanding or qualification of the (real) problem it’s meant to solve.
More often than not, failure is not a result of poorly executed solutions but a result of poorly defined problems. You could argue that the pareto-principle applies here: 80% of the ‘new’ innovation work you/r organisation is doing is probably solving the wrong problems.
Before outlining the job spec of Head of Problems, I’ll reflect and connect four dots, a mix of observations, frustrations, and insights, which, when connected together, were the catalyst for penning this post.
Dot one – Deconstructing the Chief Innovation Officer role: There is no shortage of quirky job titles out there – from innovation guerilla to innovation designer – but very few are well defined and in relation to other existing roles. One of the initial reasons I started writing these posts was because I saw the typical tenure of Chief Innovation Officer lasting on average 18 months. I hypothesise that one reason for this is that this one role is trying to do too much. An alternative view is to deconstruct the chief innovation officer role into key roles, best seen as a funnel, to make success not just possible, but more probable.
● The Head of Problems’ job is to identify, qualify and build an engaged community around the problem hypotheses.
● The Head of Experimentation’s job is to take the problem hypotheses and run multiple experiments with either a PoC, pilot, prototype, or MVP.
● The Head of Innovation’s job is to take the successful experiments and scaffold them into a sustainable solution.
● The Head of Blitzscaling’s job (source: Reid Hoffman) is to scale fast.
Each of these roles require different skill-sets, mindsets, KPIs, resources, and methodologies.
Of course, there are also risks and concerns with this configuration, too. Most notably, around the handovers. I don’t see these as distinct functions but as distinct roles within the same team, therefore avoiding any hard-handover. There is also a wider question of who they all report to. And, I would argue that they need to report to a Chief Growth Officer (but that’s for another post). Finally, there is a concern that most organisations won’t be able to create the business case for all these ‘new’ roles. But what’s the alternative, keep going with high rates of innovation failure and low ROI?
Dot two – We are not incentivised to spend enough time in the problem space: Having had the pleasure and the pain of many failed (and a few successful) projects, strategy offsites, tech platforms, and community building initiatives, on reflection the failures occurred because we paid lip service to the problem, and moved quickly into the solution space (thinking, doing, drafting, creating). We’re not rewarded, supported, or evaluated on how well we define a problem. It can be perceived as not ‘action-oriented’ enough. We’re judged on how quickly we can move to the solution phase and into the real world – even when most of what we put out there will later fail, partly because we didn’t define the (right) problem to solve.
Dot three – We don’t like the word ‘problem’: ‘Problem’ sounds negative. Too much ‘problem’ talk makes you sound like a pessimist. Some may suggest the softer language of challenges or aspirational language of opportunities. I would say the latter language is best reserved for the ‘solution developers’. The ‘problem developers’ need to have uncomfortable conversations others are not willing to have. As Brian Bates’ research outlined, the more successful architects had the trait of ‘playing’ with the problems more than the ‘average’ architects who jumped faster into designing solutions: “It was almost childlike, like when a child gets utterly absorbed in a problem.”
The framing and choice of words matter. I would argue that:
● An unfulfilled (customer) need, if significant, is a problem.
● An opportunity, especially if it’s a high value one, not capitalised on, is a problem. Going after an opportunity not rooted in a validated problem is a recipe for failure.
● A challenge is a problem.
● A pain-point is a problem.
● A missed target can be a symptom of a broader problem.
Tristan raises an interesting point – if people are not trying to solve it, then it’s not really a problem. Essentially, we shouldn’t be cavalier in our use of the word ‘problem’. Yet, I feel that it’s our job to sell the problem by articulating the consequences of not solving it. Only when the consequences are significant does it become a problem.
As Judy-Estrin notes “A problem without a name cannot command attention, understanding, or resources—three essential ingredients of change.”
Dot four – Pitch problems downstream: On reflection, after many years in many different types of organisations, I realise that we spend an inordinate amount of time and mental energy selling concepts, ideas, and solutions higher up the chain (to executives). Most of the time we have no real clue what ideas will stick, and which ones will fail to yield any traction. Even if my immediate boss likes the idea, it usually goes up at least two to three levels. Each time you massage and craft the problem so that it looks good internally it gets further removed from reality. And the ideas that do stick often don’t end up having much of an impact because they are inherently safe. I propose that we do the reverse. Executives, as owners of the strategic problems, should pitch problems and then invite teams (inside and outside the organisation) to solve them.
Now, for the job spec.
The Head of Problems’ job is to create a repeatable process, to a) identify, b) qualify, and c) build a community around the problems
Ultimately, the goal for Head of Problems is to develop a good ‘customer-problem-company’ fit. That is to say, to defineproblems that customers have which the company is uniquely positioned to go after.
Before going into detail, let’s play devil’s advocate for a moment:
To emphasise, all three jobs of identifying, qualifying, and building an engaged community around the problems is needed – not as a one-time activity but a daily effort. Hence, the need for a role to build the structures, incentives, and processes that will enable these three jobs to run effectively. This role is by no means easy. It requires a different mindset from one that is required to validate solutions.
Problems are everywhere. And, much has already been written on techniques and tools, from design thinking to customer journey mapping to ethnographic research, to help identify them. The job of the Head of Problems is to break the current habits of problem-definition as a one-off activity and create a repeatable system for identifying problems. Problems must be sought in a wide variety of places:
● Find problems that are hidden and locked in data – data from call centres, complaints, churn, and website forums. In this article, the hotel uses data to find problems (and humans to fix them).
● Find problems by going through the experience(s) of products daily (not just quarterly). They can be found in the waiting queues, with the pre and post failures of products/solutions.
● Find problems through people who’ve found workarounds. The positive deviance examples.
● Find problems in the collective intelligence of staff. Instead of the ‘submit your idea’ website, give them tools to ‘identify the problem’. Because the person framing the problem is not attached, required, or incentivised to come up with solutions, then the theory goes they will ask better questions by listening and observing.
● Find problems directly from existing customers. Not by giving them a 50-question survey but by asking powerful questions such as ‘what’s one thing that you would change?’ Or, create ‘customer incubators’.
● Find problems from an external community. Within the organisation there will always be inherent internal biases and constraints, which limit the view of the problems and subsequent solutions. The Head of Problems can source externals such as entrepreneurs-in-residence to identify the problems, without the organisation-first lens.
This identification process is inherently messy, non-linear, and uncertain – not knowing when and where the next strategic problem will be uncovered.
Problem identification also includes ‘framing of the problem’. There is no single right way to do this, but the starting point is crucial. It is a strong determinant of whether you will get an incremental solution or a ‘10x’ disruptive solution at the end. “In most cases people solve problems by copying what other people do with slight variations,” Musk told us. “I operate on the physics approach of analysis by first principles, where you boil things down to the most fundamental truths in a particular area and then you reason up from there.”
As Head of Problems, once you’ve created a repeatable process to identify problems, the next step is to qualify the problems. Very few of us are good judges of solutions that are pitched to us. Especially solutions that are conjecture, hypotheses, and require a few mental leaps to visualise success. With problem qualification, it’s a lot easier to be objective about the problem and therefore pick higher potential urgent and important problems to be solved.
There is no single perfect tool to qualify problems. There are others who have written about this, so here I’ll merely highlight three additional tools: problem-spider, problem-hypotheses, and problem-portfolio.
The Head of Problems should be asking questions that touch on all these dimensions, to get a holistic understanding of the problem.
The problem-spider is a visual representation of how confident you feel that you have the answers along each of the dimensions. On the right-hand side is the external views of the problem and on the left the internal views. The further out the placement of the dot, the more evidence you have to back it up.
Customer view – a customer backwards view:
● Frequency of it – Does this problem occur on a daily, monthly or infrequent basis?
● Cost of solving the problem – How much effort is currently spent on the unsolved problem? Do customers/users put together a partial solution to minimise the problem or solve it by making a workaround that compromises on cost, quality, time, usability, etc.? What are the costs of existing solutions (including manual workarounds, competitors etc.)?
● Cost of not solving it today – Quantify the consequences of this problem not being solved from the customers’ perspective.
● Actively solving it – Identify a particular use-case not a generic definition of the problem. It’s a lot cheaper to sell the solution that solves the problem to a user than to educate the user about the problem in the first place.
● How long it takes to solve the problem – The problem may occur daily, but if it only takes a minute to solve it is less important than spending 15 minutes every day on a problem. Time is one measure. You may look at other measures.
Org view – an organisation-forward view:
● Urgency of solving it – What’s the level of urgency, in terms of existing strategy alignment, resource allocation, prioritisation, etc. to solve this problem?
● Cost of solving it – What’s the internal cost to staff and budget to at least begin experimenting to solve this problem?
● Total addressable problem – How big is the market size for this particular problem? Is it significantly large enough for a CxO for a Business Unit Director, a product manager, or sales staff to care about?
● Feasibility of solving it – How feasible is it in terms of existing skill sets, mindsets, networks etc. to prioritise solving it?
● Complexity of problem – Does it require one person to buy and use or is it more complicated, e.g. a buyer, user, influencers. These are all different people.
This is a living breathing visual. If it’s not being updated throughout all the phases of solution development, then its impact is reduced.
Getting to this relatively simple view of the problem involves doing uncomfortable and sometimes time-consuming activities. For example, living or ‘apprenticing with the problem’, solving the problem with pure human intervention (no product/service development), and post-mortems of past failures and pre-mortems of the current problem definition.
There is never a one right view or frame of the problem. The Head of Problems can use the problem-matrix (below) to frame the problem from different perspectives – mapping different levels of risk (what should be tested first during the search rather than at the start or scale stage) with different types of problem hypotheses (desirability, feasibility, viability, efficacy, etc.).
As Peter Drucker said: “There is nothing so useless as doing efficiently that which should not be done at all.” As Head of Problems, once you’ve qualified problems, you need to develop a problem portfolio. Categorise problems according to core, adjacent, and disruptive customer needs, rank them according to value, strategic alignment, etc. A tool for this will be shared in my forthcoming book.
Finally, the third part of the job spec is to resource the problem with a community, a diverse set of ‘who’, vested in the problem. It’s not enough for the Head of Problems to ‘fall in love with the problem, not the solution’, a whole community needs to, too. All too often the reason why the solution-developers don’t spend time with customers/users is because it’s outside of their habits and norms, or they are not easily accessible.
Internal community: In every one of our organisations we are faced with many orphan problems – those that continue to persist because they have no owner. The job of Head of Problems is not just to find an executive ‘problem sponsor’, but also to build an internal community around the problem. They can find ‘problem advocates’ whose role tangentially can be impacted if the problem is solved, ‘problem followers’ who are keen to see it progress and will jump in when there is traction, or ‘problem blockers’, etc. Each of these will advance the problem thesis and eventually solve it through different conversations.
Problem-solving (external) networks: Too often when trying to solve a complex problem, the necessary skill sets, mindsets, permissions, etc. won’t all be available in-house. The Head of Problems’ job is to build or harness the value of networks which form around problems. Networks made up of people from public and private organisations of all sizes.
Customer community: Tristan is astute in his observation that “When entrepreneurs start talking about problems, they stop talking about people”. That’s why the Head of Problems’ job is to ensure that customers facing the problem, most likely the early adopters, are easily accessible and part of the journey at the beginning and not just the end when trying to sell the solution to them.
In summary, the Head of Problems’ job is to create a repeatable process to a) identify, b) qualify, and c) build a community around the problems that are worth solving.
Source : https://www.linkedin.com/pulse/why-every-organisation-needs-head-problems-zevae-m-zaheer/