When developing new projects or services in an Agile way of working, it’s critical to gain insights from our customers to ensure we are improving the product and/or service. But how do we do this when we don’t have the opportunity to directly ask the customer for feedback? This is a challenge particularly relevant for organisations with a vast customer base in the hundreds of thousands, or with multiple business units, with hundreds of projects on the go at once. In this post I will explore an approach to “Fast Customer Feedback” at scale, using data to drive project decisions and validate customer satisfaction. The Intent of Iterate and Evolve Iterate, evolve, pivot, test learn, and repeat. These are core principles of Agile that I can comfortably say all practitioners (whether beginning on their Agile journey, or an experience expert) should be familiar with. We build in sprints, deliver, iterate and evolve our solutions, pivot our direction and test our hypothesis and learn from these. With the adoption of Agile broadly across all industries, the understanding or definition of these principles is varied. The true intent of an “iteration” sometimes feels like it is lost. Commonly, it is used as a noun for a phase of a project, or a set duration of time we work in. If we think of the true intent and meaning of the word iterate, it relates to building on or changing to achieve a desired goal. The desired goal for any customer-facing organisation is providing the customer with what they want. This can be a new product or service, a better customer experience or removing customer challenges. For a telecommunications company, an example may be a new plan which is tailored to a customer’s usage. Simply put: Providing the customer with what they want = satisfied customers, who are more likely to be advocates and recommend your service or products, supporting your revenue and growth. The intent of the Agile way of working is to iterate and evolve – until we provide the customer with what they want. If what we are developing for the customer turns out to be completely off track, we pivot and change our direction. The Role of the Product Owner In an Agile scrum framework, we introduce the role of the product owner. Ideally the product owner would be the customer, but practically speaking the product owner is often a stakeholder within the business who acts as a proxy for the customer and acts as the voice that communicates the customer’s wants and needs. Representing the Customer Needs How does the product owner know what the customer wants and needs? Typically they would actually go and ask the customer, showing an initial prototype or the working solution at the end of each sprint to get their feedback. As an organisation grows and scales, it gets harder and generates more of an overhead to try and ask the customer each time. If we consider the example of a large bank, they are delivering hundreds of different solutions at once, which may be across multiple different business units but are impacting the same customer stakeholder group. To gain the customer feedback for each of these solutions as frequently as required, we would flood the customers with these requests for feedback. Interviewing customers on this scale can also be quite costly and time consuming for an organisation. The harder it is, the less likely it is to occur. So instead, product owners at many large organisations end up presenting the view of what they think the customer wants and this is more than often inaccurate. Scaling Fast Customer Feedback We need the ability to scale fast customer feedback, especially in large organisations. If we can’t ask the customer, how do we streamline the process to get their input? The answer is using customer data. We can achieve this by measuring the right metrics to track the success of our solutions. Using the customer data captured, we can get real time customer feedback, without having to interview our customers directly. By using the customer data to measure our success, we can then inform future enhancements to continue to iterate and refine our solutions. Using Customer Data to Inform our Iterations We currently visualise and measure the granular detail of our delivery progress. We do this using metrics and dashboards. These track the burn down rate of completing stories, track any risks and issues, delivery timelines, etc. We use them to measure the success of our delivery, but that is where we stop. We don’t however, visualise the success of what we delivered to the customer and whether it was what they wanted. Most product owners do this as a measure phase on an adhoc basis, but why aren’t we placing the same level of importance on having this visualised every day? If we constantly have a view of how the customer has responded to what we delivered, we will be making more informed decisions with our iterations or how we evolve our solutions. What Do We Measure? When defining a solution upfront, or developing a hypothesis, we should define what our desired end state looks like and the metrics we will use to measure this. These metrics are what we should be tracking on the product owner dashboard. An example of a scenario or hypothesis: We want to provide customers with a self-service capability to troubleshoot any issues with their product or service. This will improve customer experience and reduce call volumes to our troubleshooting centre. The metrics you could measure on the product owner dashboard are: Customer visits to the self service capability Customer clicks through the self-service steps Customers still calling after visiting self service capability Customer satisfaction/experience with self-service capability Customers still choosing to call instead of self-serving Support call volumes Support call durations Iterate and Evolve Based on this Fast Customer Feedback You can then improve and evolve on the product/service you have provided to this customer based on the feedback provided. For example, if there is no change to call volumes and if customers are not making it past the first few steps of the self service capability, how do you refine this to allow for a better customer experience? By having this data on a dashboard, you are able to respond to this quickly by iterating, or pivoting in the next sprint. Metrics/Data Shouldn’t Replace Customer Interaction While removing some of the challenges of getting customer feedback on all solutions in a large organisation, metrics and data should not replace all customer interaction. Metrics and data will not always give you the “why” in terms of understanding a customer’s particular experience. It does allow you to go into these conversations with these customers with an initial informed view to ask more targeted and specific questions if required. If it is not possible to interview customers (and there are some approaches to tackling this at scale which we’ll cover in a future blog post), using metrics and data means you are at least iterating and evolving with an informed view of what the customer wants, instead of just guessing. Without measuring and understanding the customer perspective, we will not realise the real benefits of iterating and releasing regularly. The sooner we can include customer feedback as part of the iteration process, the sooner we can deliver solutions that meet customer expectations.