Understanding Design Thinking, Lean, and Agile

My book of the same title is available free from O'Reilly media. Read the excerpt below and get a taste of what it's all about.

Despite its title, this book is really about ability, learning, and adapting. Design thinking, Lean, and Agile are mindsets that, when practiced, help organizations develop new competencies. We learn to tackle problems and explore possibilities. We strive to make every action a learning opportunity for making better decisions. We put learning to work as we pursue outcomes in a way that’s optimized for adapting to constant change. More than following steps, procedures, or instructions, this report describes the mindsets and ways of working that help teams to think differently, practice new skills, and develop new abilities.

Popular culture depicts designers as precious snowflakes. In the movies, developers are socially inept propeller heads. And we all like to joke about bean-counting middle managers and executives who are asleep at the wheel. All of them are petrified of being disrupted by Silicon Valley’s hoodie-wearing startups.

Convention is dead in the modern age—there are no rules, and job roles are so last century. It’s no wonder people are so confused about how to do software better.

These are exaggerated generalizations, I know, but they do paint a picture of the mess we face when working together to build stuff that matters. Creating digital products and services is a pursuit that requires collaboration across many disciplines. Technology, design, and business all have their own kinds of architects. Strategy has different flavors, from corporate to customer to technology. Products require design, software is engineered, and someone needs to run the entire operation.

Design thinking, Lean, and Agile are prominent mindsets among product development teams today. Each mindset brings its own kind of value to the product development life cycle (see Figure 1). And although they come from different origins—industrial design, manufacturing, and software development—they share many similarities and are complementary and compatible with each other.

Design thinking, lean, and agile

At a distance, design thinking is a mindset for exploring complex problems or finding opportunities in a world full of uncertainty. It’s a search for meaning, usually focusing on human needs and experience. Using intuitive and abductive reasoning, design thinking explores and questions what is, and then imagines what could be with innovative and inventive future solutions.

The Lean mindset is a management philosophy that embraces scientific thinking to explore how right our beliefs and assumptions are while improving a system. Lean practitioners use the deliberate practice of testing their hypotheses through action, observing what actually happens, and making adjustments based on the differences observed. It’s how organizations set their course, learn by doing, and decide what to do next on their journey to achieve outcomes.

The heart of Agile is building great software solutions that adapt gracefully to changing needs. Agile begins with a problem—not a requirement—and delivers an elegant solution. The Agile mindset acknowledges that the right solution today might not be the right solution tomorrow. It’s rapid, iterative, easily adapted, and focused on quality through continuous improvement.

Download it for free from O'Reilly Media in PDF, ePub, or Mobi format. 

Add it on Goodreads

Understanding Design Thinking, Lean, and Agile Understanding Design Thinking, Lean, and Agile
reviews: 1
ratings: 7 (avg rating 4.57)

Finding the fastest path to feedback

Asking better questions and learning to facilitate simple customer interviews is one of the fastest ways to bring customer-centred design into the boardroom. Customer learning is a powerful for developing strategy, and it’s not just their wants and needs. Learning their motivation, attitudes and behaviour helps to define products and services that have a chance of succeeding. Yet, many leaders choose to forego early opportunities to learn from customers because...

“There’s no time for that” 
“We already know our customers”
“The marketing and customer insights team always do all of the research”
“We don’t have the right skills to do it properly”

While sometimes those are reasonable concerns, too often, it means customer insight is delayed so much that it becomes impotent. The purpose of research is to learn something to inform a decision about what to do next. It gives us confidence to continue, or a reason to explore new lines of enquiry. It’s how we find a path, and shape our beliefs about how we’re going to win. Most importantly, it’s helps decide where to invest. Leaders need research that helps them learn fast, make decisions, and keep moving. 

The purpose of research is to learn something to inform a decision about what to do next.

Expert researchers have lots of ways to do the best research. We can be confident in their analysis, and those neat summary reports are a terrific reference. The trouble is that thoroughness takes precious time - a scarce resource for most teams. Insight that arrive weeks or months after the question is often irrelevant. Not because it’s wrong, but because the product team has already moved on to new questions to find answers to. Those questions need new research! And so it goes ad infinitum. 

You can break the cycle by doing your own research in hours not weeks. Basic design research technique is a powerful tool that is easily learned. With some simple instruction and a little guidance, product teams can 10x their customer insight capability by connecting decision makers directly with customers. 

Here’s how to get started.

Find better questions

Before asking questions, we need an idea of what answers we’re looking for. We need to design questions that push the conversation in a useful direction. Otherwise, we may have a lovely chat, but mightn’t learn anything that helps determine if we’re on the right track. 

Everyone loves a quadrant model. They work because they’re simple. This one helps break down our beliefs and identify the underlying assumptions in our thinking. Those assumptions are then translated into questions that become the foundation of enquiry during customer interviews.

You’re a digital director at a personal investment company. Your competitors all have robo-advisory services, and the executive leadership team feels they ought to have one too. There are three months and $2M to make it so. 

The solution is a robo-advisory service. We think it solves the customer job of managing a personal investment portfolio. What assumptions have we made? Traditional advisory services are out of reach. People will trust automated advice enough to make financial decisions. They’re willing to pay something for the service. Now we can design questions to find out if that’s true, and understand why or why not.

This simple approach is powerful because it’s flexible. You can start from anywhere - problems, solutions, assumptions or questions - and elaborate your thinking. It’s common start with a solution, and elaborate on the problem it solves. It’s easy to then identify implied assumptions, and these lead us to the questions that will help us learn from customers. As adoption for Design Thinking continues, more and more start with the problem, and then elaborate solutions, assumptions and questions.

With questions to answer, it’s time to talk to customers.

Do simple interviews

Talking with people is a great way to find out whether your ideas are worthwhile or hypotheses hold water. A professional researcher might do better interviews, but most people are capable of research that is good enough. You don’t need a certification to be an empathetic listener. Remember, it only needs to be good enough to inform a decision about what to do next. A lot of the time, the next thing is to explore a new question. It’s a quest for learning, not a quest for certainty, so the consequences of being ‘wrong’ are relatively low.

Interviewing is a quest for learning, not a quest for certainty, so the consequences of being ‘wrong’ are relatively low.

Just have a go, you’ll be surprised at how quickly you become competent. Follow these tips to get started.

1. Ask open, probing questions

Keep your questions open, not closed. You’re goal is to keep the participant talking. Meaning and insight is most often found in the stories that surround someone’s experience, not just the final outcome. 

You’re working with Transport for London to improve the commuter experience. Knowing that Alessandra doesn’t like catching the train is a piece data. You can collect it by asking “do you like catching the train?”. That information is meaningless. 

There’s more to learn by asking open questions, like “tell me about your experiences in travelling on trains”. You’ll likely get a more meaningful response. Alessandra might tell you about a seedy passenger with wandering eyes. It was an uncomfortable journey, and when this creeper alighted at Alessandra’s home station, she hesitated, feeling vulnerable, and decided to stay on the train for safety. This information is now much more meaningful, and might contribute to solutions that help travellers stay safe while commuting.

If you’re stuck for a question, or need a few seconds to gather your thoughts, try one of these:

Like this... Not like this...
Ask open questions
  • Tell me about a time when…
  • Talk to me about what it was like to…
  • Tell me about how that happened.
  • Are you happy with how that went?
  • Did you get everything that that you needed?
  • Is there anything else that’s noteworthy?
Ask probing questions
(instead of affirmative questions)
  • What do you think caused you to do that?
  • What were you thinking when...?
  • how did it make you feel when…?
  • Was it the cancelled transaction that caused you to get frustrated?
  • And this made you feel angry, didn’t it?
  • You thought that was rubbish, didn’t you?

2. Use description to set the scene

Using believable scenarios helps to prime people to think more deeply about how they might respond in a given situation. Its detail that might be skipped over otherwise. Even though we can’t rely on how people say they will behave, describing a scenario gives a chance that we’ll connect, and learn what people really think. 

Don’t reveal an idea and ask for opinion. That’s conjecture. It’s much better to set a relatable scenario; describe a solution; observe the reaction; and ask further probing questions to better understand it. This works well in many situations, but is especially useful when combined with sketches, prototypes or other visual props that people can interact with. 

3. Use props to observe reactions

Using simplistic sketches is a fast and effective way to start testing assumptions. You’ve set the scenario, now show a solution as a sketch or rough wireframe and observe what happens next. So much can be learned by watching, not just listening. 

So much can be learned by watching, not just listening.

You’re testing a new proposition in a booking service that uses economies of scale to acquire new paying customers by offering group discounts. Success relies in-part on a belief that customers will tolerate a few extra steps and some social sharing to qualify for a small discount.

A picture is worth a thousand words. 

GroupBooking _v1.JPG

What do you understand this to be? Tell me what sense you make of it? What would you do now? What might you do if…? What’s your expectation about what happens next? And so on. 

The concept is now tangible and relatable. These visual props give people something more specific to share their thoughts about.

In summary

Talking with customers isn’t just for research experts.  Embrace the entrepreneurial spirit, get out of the building, and find out straight from the people whether you’re thinking really adds up. Keep it simple and get involved. You’ll find that what you learn in one day talking with customers is more than you thought possible. Don’t do it once, do it always. And use what you learn to make better decisions faster. You’ve nothing to lose, and so much to gain.

They’ll be opportunities to do more thorough research later. As strategy evolves from initial learning, stakes are raised, investment increases, and experiments become more elaborate. That’s when to bring in the experts. They’ll have ways to increase confidence in any findings - often by using several methods to triangulate the results. Early on though, a general proximity to the truth is more important than precision.

 

 

Digital product development explained in 5 minutes

Here's 5 minute animated walkthrough of the why, what and how of digital product development using the Double Diamond. The high-level approach is very intentional and deliberate. How it's executed in practice is infinitely variable to suit specific needs. It's a way of thinking, not a process!

Product Strategy Constellations

I’m always looking for workshop methods that work. I have some favourites, but workshop facilitation is full of uncertainty. Nearly always, modification is needed, and most planned activities work better when we’re willing to stay loose. This time, the situation called for something completely new.

We needed something to cut through the noise. More than just a roadmap, we wanted to see relationships between parts in strategy. These parts included more than just software products. Operations, technology platforms, partnerships, business acquisitions, and software products all needed a place on the map. We wanted to create a visual model to show a single view. One reference for many teams.

All things considered, our visual model needs to:

  • Map relationships between all initiatives in a programme
  • Serve as a single view of strategy for many teams
  • Show both tactical and strategic activity in the same view
  • Show software initiatives alongside other kinds of work
  • Be easy to understand and update

We dreamed up the Strategy Constellation Map

A Strategy Constellation Map shows the relationship between elements of a product strategy and an overarching programme of initiatives.

A Strategy Constellation Map shows the relationship between elements of a product strategy and an overarching programme of initiatives.

Components of the Strategy Map

Components of the Strategy Map

Let's take a look at each part of the map in more detail.

Business Objectives

The map above shows business objectives representing a revenue funnel. The first two are about attracting and activating new customers. The third objective is about successful fulfilment of service - which in this case correlates with revenue generation. Your business objectives are probably different, but you get the idea.

When organised this way, it's easy to see all the things that contribute to an objective in one place. Scanning across the map helps us define ‘thin slices’ of value. That is, small chunks of work that deliver tangible benefit when done together. This is the work you want to do first. 

If you'd rather focus on just one objective, the map still helps. All relevant entities are shown together for easier prioritisation.

Product Roadmap

Here, product team can see how the work they do maps to the bigger-picture strategy (above the waterline). It’s an exploded view showing the roadmap for each item in the programme. The roadmap shows release horizons. Each horizon includes prioritised release candidates.

The product roadmap shown above has three release horizons:

  1. Now: Minimum functionality for basic provision of service. Some may call this the MVP.
  2. Next: Optimisation for a better customer experience.
  3. Later: Items for further consideration at a later time

Programme Initiatives

Above the waterline, all initiatives that make up programme of work are shown. These could be other products or services, changes to business processes, technology simplification, partnerships, new business models, and so on. Detail is less important. What we want to see is how these packages of work correlate with business objectives.

Visibility is the main goal here. Showing relationships makes it easier for teams to collaborate. And, it also reduced duplication. For example, a team working to optimise customer activations can easily see adjacent or related activity in the visual model.

Constellations show the relationship between entities

Constellations show the relationship between entities

 

Bringing it all together

Constellation maps connect product-level strategy to a programme-level view. Mapping theses relationships together with business objectives, we achieve a single view. Product teams can ‘look up’, and see the broader context of what they’re working towards. It’s just as useful for strategy teams to ‘look down’ for a snapshot of how product-level initiatives contribute to the bigger picture.

Limitations

These are great for product teams, because one-to-many relationships are clearly shown. One product, mapping to many entities in a big strategy. However, many-to-many relationships are not so easy. Things above the waterline (programme initiatives) may have a relationship with many entities in several product roadmaps. That's hard to show in a single view.

Constellation Maps work best when there are a handful of business objectives. Let’s say six or fewer. Any more than that, and mapping between entities becomes a bit silly, visually.

They're strongest as a visual model. For ongoing management of scope and dependencies, these maps would surely become cumbersome over time. Especially if there are many product roadmaps within one programme of work.

If this a useful visual model for you, I'd love to hear your thoughts in the comments!