Let’s take a quick journey back to the 1970s for a moment — a time when products were largely defined by a focus on… well… the products themselves. Over the next 30+ years, that product focus evolved to include services, and this new approach provided a much more robust customer experience. Fast forward to the 2000s, when the proliferation of the internet and the introduction of mobile shifted our focus away from the product toward the customer. Today in our switched-on, always-present world, communication must be bidirectional, frequent and focused on fostering relationships.
And yet there’s a growing disconnect between customer needs and the experiences being delivered, and it’s directly impacting customer loyalty and market share. Customers expect to interact with brands how and when they want. As a result, customer expectations are often evolving at a faster pace than brands can keep up.
Building a strong relationship with your customers is a proven way to close this gap. In the case of Agile product development, that means talking to your customers early and often.
In fact, 4 out of 5 companies say they are using Agile in some form today.1 Yet according to a survey by Maze in 2022, only 16% of them are conducting research during the development phase.2 So why is that? Why is so little research happening during development? Because the research and development processes are often at odds, and shoehorning UX research initiatives into an Agile process isn’t as easy as we would like it to be. Let’s take a closer look at why.
Nothing slows down design and development projects as much as arguing over personal opinions or wasting effort solving the wrong problem. The truth is, working in a shared reality, based on actual evidence, makes for faster decisions.
History tells us that it's too expensive NOT to do research. The 1 – 10 – 30 rule can be applied here. This rule explains that if the cost of making a change in discovery is 1X, it would then cost 10X to make the same change in development and 30X more once it’s been released into production.3
Most people probably do not. Or maybe you do — if you are doing continuous research. But even if you are, you still need to know how and when they want it. Customer needs are constantly changing, and you can lose touch in a short amount of time. In fact, the number one reason products fail is that they don’t meet their customers' needs. Today’s consumers have a short attention span and lots of options to choose from.
So how can teams be both customer-centric and agile in today’s world? There’s no perfect model that applies universally to everyone. Here are some best practices and tips that can help your team be more successful:
Delivery is one of the main driving forces in Agile, and output is often the primary measure of delivery. Make sure you understand your own Agile process (and the people you rely on) first. Then make it your mission to help guide the focus of the team from the process itself to the outcomes. Be the voice of your customer.
How to make outcomes > outputs
The idea of “just enough research” (introduced by Jeff Patton back in 2008) focuses on continuous learning.4 I like to think of this as “research and development” over “research then development.”
Use a “just enough” research approach in a sprint to validate that the changes you are introducing to your customers achieve the sprint goal and do not introduce any new issues. In my experience, this usually involves some form of moderated or unmoderated usability testing — depending on time, resource availability and importance.
How to adopt a continuous learning mindset
At some point, you will inevitably find yourself with a research initiative in front of you that needs to span multiple sprints. This is a good example of when research and Agile don’t align perfectly out of the box. The initiative (and the work you need to do) doesn't have to fit into one sprint. And that's perfectly ok. Consider using a parallel-track approach for work that doesn't fit neatly into a single sprint. Work with your Scrum Master or project manager to chunk the work into smaller parts so that each chunk can be estimated, has a defined finished state, and rolls up to an Epic.
How to use Epics to make Agile research work
The Agile process is built on the shoulders of feedback, but if that feedback doesn’t make its way back into the process (or isn’t conveyed effectively), it’s useless.
It's just research theater — done to signal that research is happening but doesn't have a significant business impact.
Use feedback as leverage to make sure that the team not only hears from (and can empathize with) your customers, but also responds to their needs.
How to make feedback effective in Agile
It takes people, process and technology to improve the performance of something. We’ve already touched on people and process, so let’s turn our focus to how technology can help incorporate research into Agile.
How to use tools to help with research in Agile
The struggle with incorporating research into Agile is age-old and pervasve. At the end of the day, it’s going to take time and hard work from you to make it work with your team, but as the research expert and the voice of your customer, it’s up to you to lead the charge.
In the long run, it will be worth it for you, your team and your customers. Leverage some of these best practices to get you started: