When what we ask for is not what we get, and what we get is not what we need

Great teams deliver great products by solving problems their customers had but didn't fully express, in ways they didn't imagine possible.

To deliver truly great products, software or otherwise, we need to go beyond what the customers or users ask for. We need to discover, understand and deliver what they really need.

“If I had asked people what they wanted, they would have said faster horses.”

- Henry Ford (apocryphal)

But understanding the needs of our customers, and figuring out what could really help them, is not simple. While users are happy to talk about solutions that they think will fix their problems, they rarely talk about the underlying problems they are trying to fix. After all, if users could always explain exactly what they needed, we wouldn't need disciplines such as Product Management and Requirements Analysis.

And even when we do understand what our customers need, delivering a solution they will love is another matter entirely. In many, many, projects, the features we deliver are neither what the users asked for, nor what they really need.

What we ask for is not what we need, but what we get isn't what we need either.

In the rest of this article, we will look at this disconnect, and see what we can do to align these circles more closely.

When what we ask for is not what we need

Suppose I want a new kitchen. If I give the builder a detailed description of the layout, down to the colour of the bench, the height of the fridge and the make of the stove, I won't get a great kitchen. I might get the kitchen I ask for, but it won't be the kitchen I need. I'm no interior designer and know nothing of the latest trends in culinary appliances, or of the finer points of kitchen layouts.

A good kitchen maker would not accept my requests no-questions-asked. She will ask me about my budget, tastes, preferences and constraints. She will ask me if I expect to entertain large groups, or have breakfast in the kitchen. And as a specialist, she will be able to propose a few appropriate options.

We are all kitchen makers

In software development, the team are the kitchen makers. They have some experience in building kitchens, and know the correct pipes and fittings to use and all the pros and cons of the various brands on the market. What they don't know is how the home owners intend to use the kitchen.

But in many organisations, teams and cultures, teams treat requests from the business, or from business analysts, as unquestionable sources of truth. After all, the business should know what they want, shouldn't they?

Business sponsors almost always know what they want to achieve. They should be able to explain how the project will benefit the organisation (for example, by saving time or increasing revenue). And they will have some ideas about the features they would like to see.

What the business needs is more valuable than what the business wants

Like good kitchen makers, the development team will not serve the business well if they implement every feature without question. Where the team can really add value is by helping the business sponsor find the best way to achieve their goals. And this may or may not involve the exact features the business initially asked for.

For example, suppose we are building a web application. The product owner might start by asking for a login screen with a username and password. But when we talk through why they want a login screen, we might discover that what the users really want is just to be able to access their accounts securely. And there are many ways to deliver this capability without a clunky old-fashioned login form.

The job of a professional team is not simply to deliver what the customer asks for. It is to understand what the customer needs, and to reconcile this with what can be delivered. The customer will generally ask for a specific solution - they will tell us What to do, and How to do it. We need to identify where the value is coming from (the "Why"), and to explore the breadth of options available that could deliver this value more effectively.

When what we get is not what we asked for

Communication, both with stakeholders and within the team, is the cornerstone of good software development. But it's incredibly hard to get right. Between 44 and 80 percent of all defects are caused by unclear, ambiguous or incorrect requirements. We have a terrible record for delivering software that fails to match what the customer originally asked for.

Maybe if we spent a little more effort upfront to  understanding the business problem, then all of our problems would be solved? Business analysts work very hard to understand what the customer needs, and to translate this into terms the development team can work with. But the history of IT has shown how hard this is to do in practice. Specifications documents are not a great way to transmit information about business needs. Written documents just contains too much scope for ambiguity and misinterpretation.

But there is a deeper problem afoot. Even if business analysts could fully understand and convey the asks of the business, we are assuming that the business themselves know what they need. And as we saw in the previous section, this is a very risky assumption to make indeed.

When what we get is not what we need

If a team delivers a killer feature that the business love, the business will rarely complain about it not being in the specs. The real problem of not delivering is not when we don't deliver what the business asked for, but when we don't deliver what they need.

Unwanted features represent wasted effort

And if we don't focus on identifying and delivering features that the business do need, we will inevitably deliver things that they don't. Some studies have found that 50-60% of code delivered into production for large projects is never executed. Sometimes it is misunderstood features that need to be modified or reworked before they become really useful for the business. Sometimes it is just features that do the job, but in an overly-complicated way.

But not all waste is bad. Some waste is even desirable. Just as Kanban teaches us not to aim for 100% utilisation of team members, we should not aim to get all of the features we deliver right first time round. If you are not failing to deliver some features, or if you are not getting some negative (or "constructive") feedback on what you deliver, than you learn very little.  If you want to stay competitive, you need to be continually learning.

But not all waste is bad

In fact there are two types of waste: positive waste and negative waste. Unused features are negative waste. These features create unnecessary delays and costs for little or no business gain. Worse still, they prevent us from working on those high value features that would delight the customer.

Positive waste is work that doesn't make it into production, but that allows us to deliver a better product, or to work more efficiently, in the longer term. A great example of positive waste is experimentation, when we try something out to see what would work best. Experimentation is learning: the code might be thrown away, but the learning stays. And teams that deliver great products tend to do a lot of experimentation.

Projects are journeys of discovery. Our understanding of what we need, and how we can deliver features that meet these needs, evolves throughout the life of the project. Trying things out is an essential part of this process.

So what's a team to do?

Silver Bullets do not exist, but there are a few principles that successful teams generally apply to help align what get delivered with what the business actually need.

• They focus on building a deep shared understanding of the customer needs, across the entire team. They challenge the requirements at every stage to get a deeper understanding of the underlying business needs. Collaborative requirements discovery and definition practices such as Behaviour Driven Development are a great way to do this.
• They get feedback and validation early and often, which helps them figure out if they have really understood the customer needs, and more importantly, whether what they deliver is valuable or not. These teams deploy and demo new features often. Automated acceptance tests help them to verify the features they deliver. Carefully chosen and agreed production metrics let them see if a feature is actually delivering the value they expected.
• They celebrate learning and experimentation. In these teams, "what should we learn next" is just as important a question as "what should we build next".

Aligning the three circles is not easy. But getting the alignment right is one of the secrets to delivering products that benefit the business and delight the customer.

READY TO LEARN MORE

Discover How To Build Test Automation Frameworks For Agile Projects From Scratch Fast

Learn to do test automation at scale faster and more effectively in today's agile environments using a proven approach that speeds up both you and your team, without forgetting essential scenarios OR missing deadlines.

Download the Flipped Testing handbook today!