Using Design Thinking to Solve the Right Problem Well
DevOps and Agile are allowing technology teams to quickly find good solutions. However, it is also becoming all-too-easy to quickly find good solutions to the wrong problem.
We’ve all experienced great solutions to the wrong problem: Google Glass and banana slicers (below) both solve problems, but they are not necessarily solving ones that are meaningful for the intended customer.
A good solution to a non-problem, credit: Lean UX
Whilst our technology teams are getting better at solving problems quickly, how can they ensure they are solving the right problems - those that, once solved, will lead to positive outcomes for our customers and business?
The Challenge: Effectiveness vs. Efficiency
When coming up with good solutions, bear in mind the distinction between being efficient and being effective.
Efficiency is about doing things well, whereas effectiveness is about doing the right thing well.
Being effective is a non-negotiable aspect of coming up with a good solution. Paraphrasing Peter F. Drucker: there is nothing worse than delivering the wrong product to our customers well, as it will be entirely useless.
Being efficient is nice-to-have, once we know we are being effective!
“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions” -- Albert Einstein
Being effective requires a deeper understanding of the problem we’re attempting to solve. This is referred to as understanding the “problem space”, and stands in contrast to the “solution space” where we design and implement solutions to solve the problem. The problem space is where Einstein would spend 55 of his precious minutes, with only 5 minutes in the solution space.
Differentiating between the problem and solution space helps us be conscious of where we are focusing our efforts. It is tempting to begin our journey in the solution space, solving a perceived problem by first creating a solution and then releasing it to customers. We find only too late what we have created is an undesirable solution to an insubstantial customer problem.
When a team solves a problem by starting in the problem space and first understanding their customers’ problems, they minimise rework and maximise results, whilst also creating a sense of common purpose in the team. By the time they begin to craft a solution they have greater confidence that it relates to an important problem their customers are facing. Problem solving is - of course - not entirely linear. Teams will need to regularly return to the problem space as they progress in solving a problem.
Understanding the Problem
As Steve Blank reminds us, to be effective we must Get Out Of the Building (GOOB) and develop a real understanding of our customers’ problem, without operating on what we think their problem is. A true understanding of our customer’s problem exists only outside the organisation and in our customers’ minds. This is where Design Thinking - more specifically User Experience (UX) Design - can help us.
The first principle is that you must not fool yourself and you are the easiest person to fool. -- Richard Feynman
It is easy to confuse User Experience (UX) design and User Interface (UI) Design, so it’s worth quickly clarifying the difference before we continue.
UX design focuses on understanding the customer, their journey, the associated pain points and how that journey could be redesigned to remove those pain points. UI Design tends to focus on how to create intuitive and pixel-perfect user interfaces within that journey.
As an example: if UX design were to focus on the structural layout of a hotel - where the reception is, how you get to your room, how the keys work, the way you call room service - then UI design would focus on assembling the elements needed to support the experience: the choice of soft furnishings, furniture, the hotel bar lighting and the dress code of the staff.
Our Approach to the Solution
There are three dimensions of a ‘good’ solution: it must be desirable, viable and feasible.
Good products and services are desirable, feasible and viable. Adapted from IDEO’s How to Prototype a New Business.
When designing a product or service, we start by first focusing on ensuring it is desirable (i.e. effective, that is, ensuring it will solve a real customer problem on their terms). If a product is not desirable, it does not matter whether it is feasible or viable because it will be useless to the customer!
Design Thinking helps us ensure the product we design is desirable, by building our sense of the problem space, in particular the customer and their problem.
The Design Thinking (and related) tools we often deploy include:
- Objectives and Key Results (OKRs): a set of measurable goals that define direction without dictating how a problem is solved, e.g.: reduce current account customer attrition by 10%
- Customer Personas: a canvas that captures our shared understanding of our customer and their unmet needs
- Outcome-based Roadmap: a high-level plan indicating the order in which we will tackle the problem, and the outcomes (success measures) we expect to see
- Lean Canvas: a method to ensure the solution is compatible with wider business needs
Let’s bring these tools to life in a recent case study.
Case Study: Global Services Firm
De-risking a New Cloud-Based Product Launch
We recently helped a global services firm trial new software delivery practices for an upcoming product, allowing them to unlock the full value of cloud-based software development.
Whilst the firm was forward thinking in how they delivered software, we observed they had retained some waterfall practices. This meant that the first release would require 3-4 months to deliver to customers and for feedback to therefore be received. The product also held greater risk for the client as it was diverging away from their traditional business, so it was critical to help them be efficient by bringing forward this customer feedback and ensure they were effective (i.e. solving the right problem for its customers).
In order to best help the firm, we deployed practices underpinning five key principles:
- Get out of the building: Cease endless debate and instead rely on customer interactions to build empathy and validate understanding early and often.
- Bring feedback forward: Build short feedback loops into software delivery to surface risks early and allow continuous adaptation of the plan to maximise impact. Enable this by delivering software in small, incremental pieces that move from idea to production quickly.
- Diverge vs. converge: Be comfortable diverging and fully exploring the problem space, rather than prematurely converging on the wrong solution.
- Externalise work: Use whiteboards, virtual shared spaces, printouts and sticky notes to build a shared understanding of the problem with the team.
- Continuously improve our process: Ensure we sharpen our approach, simplify our processes and strengthen the team - using retrospectives as a common method.
Using Design Thinking
On joining our client, we extrapolated an understanding of their customer’s problem space from their requirements documents and short stakeholder interviews. Whilst it would have been helpful to have talked to their customers directly - and Get Out Of the Building - we wanted to start with what our client already knew given their extensive work.
Our understanding was played back to their teams in the form of a Customer Persona, Lean Canvas and Objectives and Key Results - artefacts which concisely articulated the best understanding of: what is the customer’s problem, what is most important to them in a solution, and how does the business therefore measure success of the solution?
Example Lean Persona, adapted from Lean UX
By presenting these artefacts back to the client using a virtual whiteboard we were able to build a shared understanding of the problem and the desired key results across their teams, providing a clear direction to the development team with buy-in from key stakeholders.
The key results were used with the development team to break down and prioritise the product roadmap into smaller pieces, which could be delivered in 1-2 week increments.
The Product Roadmap, focusing on delivering in small pieces and early integration - bringing technical feedback forward. Gherkin was used as a clear and common way of communicating desired system behaviour.
Delivering in small increments brings two types of feedback forward: technical feedback and customer feedback.
Technical feedback comes when a team integrates their code together and ensures it functions as expected across all tiers (front-end, back-end, etc). It often doesn’t! Shifting technical feedback forward often reduces the cost required to address it - the code is fresh in the teams’ mind, and they have likely not yet covered it with additional layers of code.
Customer feedback comes from the ability to get something - albeit small - into a customer’s hands early, and ensure it is providing the expected value. If it does not provide the expected value, we have an early opportunity to learn and adjust our product roadmap, whilst also updating our understanding of the customer in their Persona. Design Sprints are a method to further bring forward this feedback even before a single line of code is written.
Shifting these types of feedback forward - in conjunction with OKRs that are not coupled to a particular solution - allow a development team to constantly adapt their path as they learn.
Example of solution-agnostic Objectives and Key Results (OKRs)
The Result
By the end of our time with the client, they had formed a cross-functional team that could quickly and efficiently integrate and deliver small increments, bringing forward technical and customer feedback. This early and ongoing feedback would allow them to constantly improve the way they solved the problem for their customers - ensuring effectiveness would be maximised.
Summary
Design Thinking encourages us to take a step back into the problem space and ensure we maximise the effectiveness of products for our customers. We begin by understanding our customers and their problem, and constantly revise this understanding through continued customer interactions and feedback from frequent releases of small software increments.
Externalising our work assists us by building a shared understanding of our customers, and widely-accepted measures of success, ensuring our team is aligned. This allows them to pivot early as they shorten feedback loops with both the customer and their technology through early and frequent releases.
Effectiveness is too often stifled in organisations where project success is perceived as delivering the complete project on time, versus whether it truly solves the original problem.
However, by changing the rules of our game we can minimise rework and maximise results, benefiting everyone: our customers, our teams, our business and our shareholders.
References and Further Reading
- Measure What Matters: Writing OKRs (Article)
- IDEO: How to Prototype a New Business (Article)
- Lean Canvas: The 1-Page Business Plan (Article)
- Lean UX: Designing Good Products (Book)
- Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback (Book)
- Design Sprint: Solve Big Problems and Test New Ideas in Just Five Days (Book)
- Inspired: How to Create Products Customers Love (Book)
