Don’t start with the chair: how to be a better problem solver.

The best things in life are not free. Relationships, raising children, building a career or becoming better at a sport or hobby all require hard work. Problem solving is no different.

Image by Julian Connor

“If we need to deliver a monkey, stood on a chair, reciting Shakespeare, most teams would start by building a chair” @Mark Cohen, Domain CTO, talking about solving problems the wrong way at a recent all hands.

This is the intuitive way to approach a problem — take the problem as stated, work on the simplest elements first and figure out the more complex elements as you go. As you build, you explore more complex elements of the problem through detailed research and analysis. You develop a range of options and based on your research make decisions on which is best. You then start working on the monkey, and realise it is much harder than first imagined. Your timelines blow out, but you already have momentum and significant time and effort already invested in the output. Politically you cannot stop, and so you persevere, throwing good money after bad.

Problem solving, or combining facts and structure to find answers, is a core determinant of our success as a species. It has driven us to develop technology from fire to agriculture to electricity to the internet. It is perhaps the most impactful of all our abilities, and the killer skill everyone who works in product, be they product manager, designer or in tech, must hone. However, effective problem solving is not intuitive. ‘Starting with the chair’ can stymie an organisation’s ability to move quickly and with confidence because:

• It’s wasteful of effort and resources, as you boil the ocean looking for an answer
• It takes a long time, because you need volumes of data and analysis to find an answer
• It’s exposed to shifting priorities and condensing organisational timelines, which can result in a project being scrapped or deprioritised, or an immediate answer demanded when only half the work is done
• It back-loads the problem solving process, leaving a sting in the tail

But, it doesn’t have to be this way.

Hypotheses led, iterative problem solving

When you solve problems for a living, you naturally find a way to make the process quicker so you can solve more problems in a smaller period of time. At the start of my career, as the co-founded of a start-up, it was imperative to solve the hardest problems first, because we only had a short runway. This put me on a path, which I have since honed during my time as both a strategy consultant and a product manager, to a four step problem solving process. This approach has consistently helped me avoid ‘starting with the chair’ and the issues the intuitive approach to problem solving often bring.

Iterative, hypothesis led, problem solving.

Step 1: Reframe the problem more critically

What problem are you really trying to solve?

What problem are we really trying to solve? What outcome are we trying to achieve? Why? For example, a legacy publisher might frame their problem as “we need to stop losing money”. With this problem, the organisation might continue to invest and push in existing revenue streams (ads, classifieds, print sales). These actions are the chair — the easy step to show progress — without addressing the monkey in the room. Taking a step back, we could instead reframe our problem as “we have a legacy business model which cannot be effectively monetised in a digital age”. Framing the problem this way, we get closer to the monkey: the need for a new business model.

Step 2: Hypothesise possible solutions

Boundless creativity, methodical focus

With a reframed problem in mind, its time to generate a bunch of ideas. This is the period of creativity and imagination. Start with the widest possible view: imagine you are 10,000 kilometres high and anything is possible. I like mind maps, brainstorms and workshops for this phase, as these help cast a wide net and create an open forum for any idea — you can always refine them later.

Step 3: Identify the biggest and riskiest assumptions

With our ideas in hand, we need to assess the hypotheses to identify the biggest and riskiest assumptions. Classic approaches such as DuPont trees to 5 whys are helpful at this stage to really examine each hypothesis. For example, if we believe launching a new channel (eg. email, app, Instagram etc.) will drive retention, we might break it down as follows:

Illustrative DuPont tree for email channel growth

We can then investigate some of the big assumptions such as:

• Our customers actually use the channel (demand)
• We can deliver something our customers want in the channel (value)
• We can effectively opt customers into our offering (acquisition)
• The new channel will deliver incremental value and not just cannibalise other channels (viability)

Step 4: Test through sceptical triangulation

We should strive to judge the merits of an idea, or the truth behind an assumption, based on facts. Fortunately, there are many, many sources of facts available, including:

• User analytics, from custom data warehouses to Google analytics
• Sales data from acquisition, churn and retention rates to rep and channel productivity metrics
• Finance data, such as profitability, revenue and costs
• The competitive landscape, from competitor activities to broader shifts in the market and landscape
• Customer and user feedback, from support, sales or in response to surveys and interviews
• User and customer research such as interviews, workshops and focus groups
• Surveys and quantitative user research
• Internal discussions with other teams who have tackled similar problems before
• Prototypes, fake door tests and a/b tests

However, obtaining facts blindly is of no use. A process of sceptical triangulation allows us to effectively leverage these facts to find answers.

Let’s break this down. I am sceptical because a healthy dose of cynicism helps temper enthusiasm and jumping to an answer too quickly. I triangulate, because not only is it rare that a single data point can perfectly explain an assumption, but its also easy to become trapped in an overly complex model or data-set in search of perfection. Triangulation forces you to broaden your view to multiple data points from various sources to find a common theme. In my experience, it takes significantly less time and effort to obtain 5 simple data points which together validate/invalidate a hypothesis than 1 perfect data point which achieves the same goal.

Beyond the savings in effort, triangulation also yields a deeper level of insight. For example, an A/B test can tell you with confidence what a user is doing, but not why. Are you certain your significant result is because the user wants to use the feature, or is it because the button is ambiguous and doesn’t deliver what they expect, or is too close the back button and therefore frequently mis-clicked?

Keep the cycle going

After testing, while we have a better understanding of the problem space, that doesn’t mean we have an answer. We will need to repeat this cycle, reframing what we know based on our improved understanding and again tackling the biggest assumptions. We might run multiple iterations on the email example, from launch through optimisation, with the problem critically reframed each time. At one stage the focus might be on validating the demand or audience size, but as we get traction this might shift to high numbers of bounced/blocked emails, our churn rate, or low levels of engagement. With the problem critically rephrased each time to focus on the highest risk or biggest opportunity, our hypotheses and solutions will be different, but our framework to discover and deliver the answers is the same.

But… what happened to the monkey?

You tell me.

A lot of assumptions could be made about that monkey. Some of them might be killed off, and the rest may get tested. In product it’s our role to channel our focus towards areas of the highest impact. This may start at value: is a monkey reciting Shakespeare actually useful to anyone? But from those beginnings, morph into usability and feasibility (how can we do this? can it be a toy monkey?) as we continue to iterate on the problem. With each cycle, we are more enlightened, and are able to converge towards solutions which consistently yield impact with a high degree of confidence.