How to get client feedback into your dev process

In a world where customer experience is king, building customer feedback into the software delivery pipeline is vital.

There's no single rule book that sets out how this collaboration should operate. But here are four tips for how best to make use of client feedback throughout the software development process.

1. Prioritize transparency over early efficiency

An open channel of communication with customers is a must. The best way for a software development organization to establish this is to put in place a dedicated point of contact for the client. This might be a business analyst, who can relate requirements to the development team and feed back to the client any issues the developers might have.

This analyst should not parachute in after development has begun. By having the analyst sit with the development team at the start of a project, they can help to assess capacity, establish goals, and address any initial issues. This allows the analyst to set realistic client expectations about deployments from the outset.

The analyst also acts as a buffer between the developers and the client. When clients have a problem, they go directly to the analyst, who knows exactly what the developers are working on. This means that if a client request concerns a feature in development, the analyst can instruct the team to stop working on that feature and focus on another until a consensus is reached on a way forward.

This keeps the dev team focused on writing code, rather than being distracted by client communication at the expense of delivering software on time. At Finastra, the software vendor at which I work, when we began to follow this client feedback process we saw an increase in weekly engagements with clients, as well as an increase in usage of applications.

2. Build a client community

When delivering a product to multiple clients, give your users a platform on which they can establish a community, such as Chatter or Yammer, and on which they communicate feedback.

In this way, the community can become a self-servicing trouble-shooter, with peers educating one another. It also grows confidence in your service and builds trust, since you are conducting development in an open and honest way.

It also gives the development team another window into the common issues that users are coming up against. Based on the data gained from conversations about the product, perhaps regarding specific features, developers can constantly reassess their priorities and focus their energies accordingly. 

In my experience, there is a direct relationship between the number of community members and the frequency of queries about the features of older applications. As the former grows, the latter decreases, allowing for a greater focus on upcoming features.

Collaboration tools enable a level of transparency regarding workflows that cuts down the need for direct communication. But it's important to remember that these tools are useful only up to a point. If a client query extends beyond two emails, a direct phone call is the best means of addressing any issues.

3. Test often

The maturation of online analytics tools has rendered more traditional UX data-gathering exercises—such as asking clients to recall the features they like the most from multiple different designs—inefficient at scale. Using online tools, developers can now track user behavior live.

Monitoring how clients interact with your software provides crucial insight. For example, a user who keeps returning to the top-right corner of a web page might be looking for a way to exit that page, so this feature may need to be made more prominent.

Likewise, if you find that a customer has a habit of hovering in a specific area on a page where there is no live feature, you can assume the user is used to having a certain feature available in that space. Rather than waiting for feedback to reflect this desire, the development team can make a decision to test with features and assess how the customer responds.

Our developers value testing; we find that the more data we collect, the easier it is to focus on the top three items from the product backlog and road map, as agreed upon by the business analyst and client at the start of the project.   

4. Put a checkpoint system in place

Setting expectations from the outset is a must—and working in an agile way makes this easier.

By working with clients, the business analyst and the development team can establish the key objectives of the project, and also agree on smaller checkpoints that are desirable and achievable with every sprint. While key objectives will most likely stay the same, checkpoints can be moved or altered.

Take, for example, a scenario in which the client must present certain features to business stakeholders. The features may be constituent elements of a key objective, but what if the current sprint is not focused on these particular features? When working in agile, the development team does not have to grind to a halt because it is moving in a direction that is at odds with the immediate needs of the client; all that is required is a shift in direction.

So a checkpoint has been removed and another inserted, but the key objective, which is delivering the application as a whole, remains the same. It's all about balancing tactical steps to achieve strategic goals.

It is also important to keep the number of checkpoints under key objectives to a set number. Anything more than five is likely to cause the team to scramble and lose focus. Taking this approach with our team caused both morale and productivity to increase as the team became more focused. Since establishing this workflow, we have been hitting and calibrating checkpoints every two weeks.

Get started

Reducing lead times is not the only reason for making client feedback a key part of the software delivery process. Open communication with both developers and clients shows a dedication to improving the experience of all parties and fostering trust and confidence on both sides.

This article previously appeared on Tech Beacon.