It’s happened so many times it’s cliché. IT gathers all the requirements for a new project. Disappears for six months to a year to get it done, finally delivers it, only for the customer to say:
“Ok, now I know what I want”
The team spent so much time focusing on implementing the solution, they missed finding the right problem. People often misunderstand Jeff Sutherland’s book Scrum:The Art of Doing Twice the Work in Half the Time and come to Agile looking for greater efficiency. This leads to a focus on velocity – how can we get teams to produce more items faster. What they may not realize is when you focus on working faster, you assume:
- You understand the customer
- You know what the problem is and why it’s happening
- You’ve already found the best solution
As I mentioned in The Power of NotKnowing, until you hear it put that way, you may not realize you even had all those assumptions. Too many teams find out way too late, they got it wrong. It doesn’t matter how fast you drive if you’re going the wrong direction. So before we speed the team up we need to ask:
- How do I make sure my teams understand my customers, so they know what problems to focus on?
- How do we make sure we understand the problem, so we build the right solution?
- How do I help teams get quick feedback from customers to verify they got it right?
Understanding Customers
Let’s start with understanding customers. While we leverage Agile
principles for how to get the work done, design thinking is a better place when it comes to understanding customers and their problems. If you haven’t heard of design thinking, it’s well worth checking out IDEO’s page. In a nutshell, it’s focused on using designers’ tools to develop innovative solutions by focusing on the people who will use them.
The first step of the design thinking process is empathizing with users. We think of understanding users, but design thinking takes it a step further. We need to see the world through their eyes. To get a perspective on the power of empathy, it’s worth taking a moment to watch this four-minute clip from the Cleveland Clinic.
In Playing to Win, Lafley provides an example from P&G who are experts at designing solutions that fit customer needs. Working on a razor solution for India, the company sent designers on site to see what customers’ lives were like. A new designer protested, saying they had Indian neighbors, why take the trip. However, after seeing men with no running water, shaving in cold water from a cup, the team came back with an innovative product that quickly grabbed market share.
The closer teams are to customers, the better they will understand them, and the better they will be at identifying problems. This is one of the areas where a little bit of investment will pay large dividends in understanding where teams are currently missing the mark, and where to focus.
Remember, we are not trying to solve technology problems, management problems, or efficiency problems. We are trying to solve human problems. When you understand the people, you’ll begin to see the real problems.
Understanding the Problem
Once we understand which problems to focus on, the next step is understanding the root cause. We’ll lean on design thinking again, since defining the problem is the next step in that process.
Humans love solving problems. We love it so much, we often interrupt with a solution at the first mention of a problem, without realizing we may not understand the problem at all. Einstein is attributed to the quote “If I had one hour to solve a problem, I would spend fifty-five minutes defining the problem and five minutes solving it” (not actually his, but still a great quote).
To help us focus our efforts in the right place, design thinking uses the double diamond design process (see below). The point of this diagram is that the two boxes are the same size since you should spend the same amount of time understanding the problem as you do trying to solve it. In many cases, as the Einstein quote alludes, understanding the problem means you need a lot less time to find a solution.
You can google root cause analysis for a number of tools to help in understanding the problem. Five whys is a simple one to use (and let’s you channel your inner four year old). While it can take some investigation, the hard part about finding the problem usually isn’t understanding what to do. It’s realizing that we skipped the step and taking the time to do it.
Getting Quick Feedback
For quick feedback, we’ll swing back to Agile. As I mentioned, business leaders often come to Agile looking for efficiency, but finding out if you’re headed in the right direction is where Agile shines. The best way to test if you have the right idea is to give it real customers to have them try it and provide feedback. The faster you do this, the less time you waste on bad ideas.
The key is you actually have to give it to users. Teams often implement Agile practices, but miss out on the real value. For example:
- If you keep your waterfall structure, but break it out into sprints, delivering the design in the first sprint won’t tell you if you’re building the right product. Instead, think about the smallest prototype you can get in front of a customer. Build that, and then iterate from there. People think of minimum viable product (MVP) as the smallest thing someone will use, but it really should be the smallest thing you can get in front of a customer to get feedback.
- If you build code, hold it in a test environment until the next release, and never show it to customers, you’re again missing out on valuable feedback. Even if your environment doesn’t let you do A/B releases, and you need to hold off on full releases, work with beta customers who will be willing to go look at the product in test to tell you what they think.
Circling back on the loop of understanding customers, you need to get that feedback. If you can, the best way is to watch them use it. In traditional project management approaches, we think about creating the whole product before showing it to anyone. The key to changing the way you design your work and starting to get an Agile mindset is to realize you may not understand the problem, so focus on what you want customers to test and how you can get it in front of them quickly.
Conclusion
As I mentioned in Developing an Agile Mindset, Agile principles aren’t new. They are simply building on good management principles that have been created over the last hundred years. The good news is the concepts also aren’t complex. Anyone can use them. It does take some discipline to invest the time, but it’s not even a large investment when you look comparatively at what we do today (especially looking at time wasted on building the wrong items).
So before your next strategy session, take an afternoon, go sit with an end user (no not the person buying the software or product, the one using it). See what they’re doing and take the time to understand why. The investment will change the way you think about your customers and products in a powerful way. Make it a habit every sprint to give them something new and have a real conversation about what they think. It will be some of the best time you ever invest, and he changes will leave you wondering what other assumptions you’re taking for granted.
Seen your own project failure or have an insight – leave a comment below.