How continuous discovery helps software teams make product decisions - Wishevoke

How continuous discovery helps software teams make product decisions

According to Neil Turner, continuous discovery for product development is regular research in which the entire software product team is involved and can actively influence product decisions. Equating continuous discovery with weekly conversations with one or more customers can be misleading. Combining quantitative and qualitative research methods can help software teams collect data and understand what lies behind the data.

Neil Turner talked about how Redgate conducts continuous discovery for product development Agile Cambridge 2023.

Turner defines continuous discovery for product development as:

Regular customer research;

By the team developing the product;

Looking for a desired result.

The biggest pitfalls software teams face when attempting continuous discovery are chasing weekly goals, conducting unfocused research, and neglecting other customer insight channels such as metrics and surveys, as Turner explained:

Many teams are fixated on meeting weekly goals and speaking to a certain number of customers per week. This can lead to poor research quality as teams focus on the quantity of research rather than the quality.

Turner mentioned that software teams can end up conducting unstructured and unfocused customer research to achieve their goals (even if they are self-imposed goals) rather than considering the most appropriate research to inform their product assumptions and decisions support:

Just because a team speaks to their customers regularly doesn’t mean they’re conducting high-quality customer research. Most teams benefit from a mix of quantitative and qualitative data, and it can be risky to make decisions based on the insights of a few customers.

Combining quantitative research methods like surveys and metrics with qualitative research methods like customer interviews can help teams collect data about their customers and better understand what lies behind that data, Turner said.

Not all teams at Redgate conduct continuous discovery, Turner said. 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 essentially about a team choosing the most appropriate research approach given what they need to learn and the work being done. This choice of research approach is determined by the product designer working on or with the team, Turner said.

Teams at Redgate that conduct continuous discovery often do so through short customer research, rather than, for example, running a session at a set time every week, Turner explained:

You may plan on two to three days of targeted research per month. This makes it easier to plan, plan and prepare customer research sessions. It also makes it easier to identify trends because insights are collected over a period of a few days, rather than, for example, several weeks passing between sessions.

Teams use tools like Calendly to automate recruiting and often share responsibility for facilitating sessions and writing notes, Turner said. For example, some teams have a rotation schedule in place so there is less reliance on one designer to carry out all research activities.

Turner mentioned that teams that conduct continuous discovery have been able to establish a good rhythm for exploring a problem area to identify opportunities, validate ideas being worked on (e.g. via prototypes), and Gather feedback for features that made it into a product. This supports a two-pronged discovery and delivery approach.

Teams also have a better understanding of their customers and can better empathize with their challenges. After all, it’s one thing to read a customer’s feedback; “It’s very different to hear that feedback directly from the customer’s mouth,” Turner concluded.

InfoQ interviewed Neil Turner about continuous discoveries for product development.

InfoQ: What have your software teams learned from continuous detection?

Neil Turner: Teams learned that there is no set approach to continuous discovery and that it is not the answer to every research question. For example, at Redgate we have a team focused on early research and development. They are better able to conduct more traditional preliminary research rather than ongoing discovery. They tend to work on very early concepts and don’t want customer insights to be collected gradually. Instead, they typically prototype a concept and receive early feedback through blocks of customer research sessions.

Teams also learned that continuous discovery requires a surprising amount of effort from the team. It’s not just about scheduling a few sessions with clients and hoping for the best. Meetings need to be carefully planned, well executed and then properly analyzed as a team. The benefits are worth the cost, but there are certainly costs too.

InfoQ: What advice do you have for teams looking to get started with continuous discovery?

Turner: My main advice for any team starting out with Continuous Discovery is to improve their understanding of Continuous Discovery, start small and adapt their approach.

Too many teams hear about continuous discovery, jump into a standard version of continuous discovery (because they don’t know enough to refine their approach), and then give up when it doesn’t deliver the wealth of customer insights they expect.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top