According to Neil Turner, continuous discovery for product development is regular research that involves the entire software product team, and that can actively inform product decisions. Equating continuous discovery to weekly conversations with one or more customers can be misleading. Combining quantitative and qualitative research methods can help software teams gather data and understand what is behind the data.
Neil Turner spoke about how Redgate does continuous discovery for product development at Agile Cambridge 2023.
Turner defines continuous discovery for product development as:
Regular customer research;
By the team building the product;
In pursuit of a desired outcome.
The main pitfalls that software teams experience when attempting continuous discovery are chasing weekly targets, carrying out unfocused research, and neglecting other channels of customer insights, such as metrics and surveys, as Turner explained:
Many teams get fixated on hitting weekly targets, and on speaking to a certain number of customers a week. This can lead to poor quality research as teams focus on research quantity over quality.
Turner mentioned that software teams can end up carrying out unstructured and unfocused customer research for the sake of hitting their targets (even if they are self-imposed targets), rather than considering the most appropriate research to help inform their product assumptions and decisions:
Just because a team is speaking to their customers on a regular basis doesn’t mean that they are carrying out high quality customer research. Most teams will benefit from a mixture of quantitative and qualitative data and it can be risky to make decisions based on the insights from a few customers.
Combining quantitative research methods such as surveys and metrics, with qualitative research methods such as customer interviews, can help teams to gather data across their customers and to better understand what is behind that data, Turner said.
Not all teams at Redgate carry out continuous discovery, Turner mentioned. It’s an approach that works well with an established product, but it’s not a one-size-fits-all approach, he added. It’s very much a case of a team choosing the most appropriate research approach to take given what they need to learn and the work being undertaken. This choice of research approach will be driven by the product designer working in, or with the team, Turner said.
Teams at Redgate that do carry out continuous discovery will often do this via short bursts of customer research, rather than say running a session at a set time each week, Turner explained:
They might plan for 2-3 days of focused research a month. This makes it easier to plan, schedule, and prepare for customer research sessions. It also makes it easier to see trends as insights are collected over the course of a few days, rather than say having weeks between sessions.
Teams will use tools such as Calendly to help automate recruitment and will often share the responsibility of facilitating sessions, along with writing up notes, Turner said. For example, some teams have set up a rota so that there is less of a dependency on a designer running all the research activities.
Turner mentioned that teams carrying out continuous discovery have been able to establish a good cadence of exploring a problem space to identify opportunities, validating ideas being worked on (such as via prototypes), and getting feedback for features that have made it into a product. This supports a dual-track discovery and delivery approach.
Teams also have a better understanding of their customers and can better empathise with their challenges. After all, it’s one thing reading some feedback from a customer; it’s quite another to hear that feedback directly from the customer’s mouth, Turner concluded.
InfoQ interviewed Neil Turner about continuous discovery for product development.
InfoQ: What did your software teams learn from doing continuous discovery?
Neil Turner: Teams have learned that there is no set approach to continuous discovery and that it isn’t the answer to every research question. For example, we have a team at Redgate whose focus is early research and development. They are better placed to run more traditional upfront research, rather than continuous discovery. They tend to work on very early concepts and don’t want to be slowly drip fed customer insights. Instead, they will typically prototype a concept and get early feedback through blocks of customer research sessions.
Teams have also learned that continuous discovery takes a surprising amount of effort from the team. It’s not just a case of scheduling some sessions with customers and hoping for the best. Sessions have to be carefully planned, well run, and then properly analysed as a team. The benefits are worth the costs, but there are certainly costs.
InfoQ: What advice do you have for teams that want to start with continuous discovery?
Turner: My main advice for any team starting with continuous discovery is to level up their understanding of continuous discovery, to start small, and to adapt their approach.
Too many teams hear about continuous discovery, jump into a cookie cutter version of continuous discovery (because they don’t know enough to refine their approach), and then give up when it’s not delivering the wealth of customer insights they expect it to.
