So many times, I’ve heard that round about 50–70 % of all software features are rarely or never used. In the Cloud we can now even measure it. As a developer, I think: “Damn it! So much time spent cracking the code and then no one is using our features. We could have spent 2–3 days each week at a pool or playing chess instead while achieving the same outcome.” Of course, software developers enjoy writing code, but they don’t like to waste their time after all!
As a Product Owner, I’m in charge of the Product Backlog. If users are NOT using a feature, then I have failed as a Product Owner. Right? Wait a minute! Aren’t there feedback loops incorporated into Scrum to correct course? Yes, but maybe there is a way to reduce waste from the get-go?
In Scrum, a Product Goal is the minimal thing that a Scrum Team needs to get started and work on the Product Backlog. How do we come up with Product Backlog items? Of course, the Scrum framework isn’t prescriptive and thus doesn’t say how to do it. However, this is a puzzle piece that could make a difference in how much time a Scrum Team wastes and how creative they are.
Let us examine the following example by Don Reinertsen: “Customers told us that they wanted suitcases that were easy to carry and asked us to make them lightweight. We did this, but they rejected our elegant designs and bought the heavier designs of our competitors — the ones with wheels on them!”
What went wrong? The Product Owner or Developers could have written Product Backlog items like this:
As a traveler, I want alloy suitcases so that the suitcases are lighter
This is a solution driven approach, which limits the solution space and doesn’t really reflect the underlying needs of the users. Unfortunately, users often tell us solutions and not their needs.
What could the Product Backlog item be if it were driven by empathy and the underlying users’ needs?
As a traveler, I want to carry less so that I’m less exhausted
Now, the solution space is wide open which makes the life of the Scrum Team a bit harder because they need to explore options. On the other side, optionality is good because it allows you to optimize TCO and choose the best solution for your users’ context. In our example, an alloy design probably makes the production of the suitcases much more expensive than the wheels. Even if the alloy suitcase is extremely light, the user influences the overall suitcase weight with the weight of the content. Thus, the alloy suitcase might not even work with heavy suitcase content while wheels might always work.
Lesson 1) if (potential) customers or (potential) users are talking about desired solutions, then explore the underlying needs.
In Design Thinking we create choices before we make decisions. This is a crucial difference between the way analytically trained professionals and professional designers work. As a mathematician or a computer scientist or natural scientist, I have learnt to steer to ONE solution through analysis. Designers create options, combine the best of various prototypes and then come up with a solution that satisfies the user’s needs and works for the user’s context.
What is a good way to explore the needs and create options? Actually, that is often much easier than you might think. However, the Scrum Team members need to leave their office building and go to the users. And that might be scary for some shy developers. 
Let us look again at the suitcase example. If you go to the airport, then you see typical user behavior like putting suitcases on trolleys. The inspiration is right there: “wheels underneath suitcases”. Very likely, this kind of inspiration is not available in the office of the Scrum Team.
Lesson 2) leave the building and get inspiration from the user’s context and the user’s behaviors.
It goes without saying that this article doesn’t intend to simplify Design Thinking down to the two lessons learnt above. Design Thinking is a human-centered complementary practice. On the other hand, Scrum Teams often have an existing product and “just” need to add features. For that purpose, those lessons might be helpful to get started on a journey for more creativity. However, a next step for Scrum Team members could be to learn how to interview users, create personas and synthesize research results, etc. Lucky Scrum Teams have team members on board with design skills who may bring those complementary practices to the table.