Customer feedback is essential to software development. Without real world feedback, it’s difficult to improve the user experience.
Agile development helps by putting user feedback closer to the developer. Agile methodology enables a software product to be delivered in functional pieces, so those pieces can be reviewed both incrementally and in total. If done properly it can add value and efficiency to your overall objective. If done improperly it can drain resource cycles with little-to-zero gain.
To demonstrate this, I recently hit on a useful analogy, one that likens software development to running a restaurant. Here’s a table showing which software development roles correlate to those in a restaurant:
Let’s start with the software developer and restaurant chef, who have a lot in common. Both work behind closed doors, out of the customer’s sight. Both follow recipes for creating their products and both know how to spin variations on those recipes. Both must sample their product before delivering it to ensure high quality. And both must take the blame when the customer is dissatisfied.
Software product owners in many ways resemble restaurant servers. For one, they must communicate equally well with both customers/end users and chefs/developers. For another, both must try the product, either sampling the code or tasting the dish. Both must also understand whether a product can be tweaked, and if so, how. Finally, both must understand when an older product needs to be replaced.
How about software end users and restaurant customers? As the ones who receive the final product, they share several characteristics too. Sometimes they know exactly what they want, but sometimes they don’t. Many are happy to let the developer/chef work without their input. But when a product falls short of their expectations, their protests can be loud.
How does customer feedback help developers when end users are unhappy with the new software? Again, the analogy with a restaurant can help. Consider the following scenario:
A customer enters the restaurant, peruses the menu and orders. Later, the waiter brings their dinner and anxiously awaits their feedback.
“Is everything okay?” the waiter asks.
“Not really,” the customer replies. “The food is not hot enough.”
The waiter conveys this information to both the chef managing the kitchen and the dining-room manager: “Table 3 is unhappy. They say their food wasn’t hot enough.”
Later that evening, after the final customers have left, the dining-room manager calls a staff meeting to discuss that evening’s customer experience. “A customer received food that was not hot enough. This shouldn’t happen,” the manager says.
The team agrees to adopt a new objective:
All hot food should be served hot.
The chef knows the food was hot in the kitchen. Perhaps the food was not delivered quickly enough. So the kitchen and dining-room managers agree to explore three options: a heat lamp, microwave oven and new staff instructions.
The next time the customer comes to the restaurant, they order the same dish. When they are asked how their food was, they say, “The spicy chicken was O.K., but not as hot as I like it.” Lightbulb moment: the customer was talking about spice, not temperature. That’s easy to fix.
Customer feedback is easy to misinterpret. Once feedback is misinterpreted, and the customer is removed from the equation, it is near impossible to recover without wasted effort. Therefore, it’s important for developers and stakeholders to sample their product during the development process and not just after receiving negative feedback. Sometimes, if you take appropriate measures, a simple solution is close at hand.
So, in the course of developing your product, make sure to follow these simple but profound guidelines:
As a development team, make sure you are 100% empathetic with the customer and treat their feedback as if it was your own. When communicating with your team, make sure you’re explaining the objective, as the customer, so everybody understands not only the what but the why as well.