Continuous Discovery

Your constantly-updated definition of Continuous Discovery and collection of videos and articles. Be a conversation starter: Share this page and inspire others!
88 shares

What is Continuous Discovery?

Continuous discovery is an approach to user research used in agile teams where research is conducted as small, frequent activities throughout the product development lifecycle. This infuses customer feedback into all product decisions instead of focusing on one-time research activity at the beginning of a project.

Product discovery coach and author of Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, Teresa Torres explains in this video:

Show Hide video transcript
  1. 00:00:00 --> 00:00:33

    Software grew up in sort of a project world where *business stakeholders defined* a whole big chunk of work to do; we wrote product requirements; the team built it; we learned way late in the process nobody wanted it. And so, we've seen people move more towards an *Agile mindset* or a *continuous improvement mindset* where we're looking at: How do we work in smaller chunks? How do we get feedback more continuously? So, continuous discovery is really just: How do we continuously *infuse  our decisions* about what we're building

  2. 00:00:33 --> 00:01:02

    with customer input? — instead of thinking about it as a project approach where you do some research up front and then you rely on that research for the rest of the project. I think this switch from project to continuous is one of the hardest ones. So, even when people – let's say they start to adopt Scrum as their sort of Agile methodology and they work in a two-week sprint; really all they're doing, what most teams do, is they make the mistake of

  3. 00:01:02 --> 00:01:31

    'Oh, well, I just take my old Waterfall process and I jam it into a two-week cycle, and so I'm still defining upfront two weeks' worth of work and then my  engineers build it and then I do a little bit of research while they're building,  and I define the next two-week iteration.' The challenge with that is that when we do our  research in a project basis even if it's just a two-week project, is that we do the research on the *big questions*, but we don't do the research on all the little teeny tiny questions that come up as we're building,

  4. 00:01:31 --> 00:02:03

    like, 'What do we call this button?' or 'How do we expose this in the interface?'  or 'How should the data model work?' And the example that I give for this is I feel like anybody on the planet could look at their mobile phone and find a dozen apps that they were excited about, which is why they downloaded it. So, they got the big idea of the app right, but then they never used it, because they *tried to* and they got all those little details wrong, and the app didn't quite work as promised. So, a more continuous discovery process is

  5. 00:02:03 --> 00:02:14

    we have to answer those *big questions* like 'What should we be building?'; we also have to answer those *little questions* as we're building so that we get all the little details  right and people actually use our products.

Product discovery refers to research that aims to identify what a product team should build—the solution, features and improvements—based on the customer’s needs. Continuous discovery refers to a sustained practice of product discovery to inform product development decisions continuously.

Table of contents

Project-Based Discovery vs. Continuous Discovery

In many software development processes, teams work linearly in clearly demarcated stages. As the team completes one stage, it hands the deliverables to the next stage.

The most common stages are requirements gathering, design, development, testing, deployment and maintenance. In most teams that implement waterfall, work flows in one direction. If the team decides to make any changes in the earlier stages, every activity “downstream” is affected—hence the term “waterfall.” Typically, teams that follow waterfall invest heavily in discovery at the beginning of the project while gathering requirements.

In the early 2000s, when teams began adopting Agile, they recognized that the “big-design upfront” approach was not going to work and made continuous efforts to distribute the requirements discovery process across iterations.

The Scrum sprint process is a cyclical, iterative process that includes a periodic evaluation of customer feedback.

Agile methods are iterative. Most agile teams work in short sprints—usually 2 to 4 weeks—at the end of which they ship working software. The team reviews customer feedback and plans improvements in future sprints. © Interaction Design Foundation, CC BY-NC-SA 3.0

In the agile framework, teams focus on shipping working software as soon as possible and iterating based on customer feedback. Since most teams work in short bursts (called sprints), teams often have little time for the big upfront research that project-based teams typically conduct. For this reason, several agile teams pressurize researchers to complete all research in unrealistic time frames, or worse, skip research entirely.

Continuous discovery helps agile teams reap the benefits of research without compromising on speed and quality of research and, at the same time, not burdening researchers.

Continuous Discovery Methods

Continuous discovery essentially requires a mindset shift. Teams can adapt most research methods to conduct research continuously. For example, a team can conduct interviews, contextual inquiries, prototype tests, etc., with a few customers every week. Continuous discovery is most effective when:

  1. The team defines and strictly adheres to the schedule of the research activities. For example, if a team commits to interviewing four customers every Friday, the team must follow it on a regular basis without pausing the schedule.

  2. Team members collaborate on the research activities. When teams delegate research to a single person or the same group of researchers, researchers may find it difficult to “sell” research insights. For example, team members could question the research findings or the methodology. But if engineers, business stakeholders and designers actively participate in the research activities, they will be more likely to trust the research insights. Since they will have first-hand experience interacting with the customers, each member can then combine this customer knowledge with their domain expertise to contribute towards product decisions. Everyone in the team need not participate in every research session. Instead, representatives of each role can take turns participating in sessions so that everyone benefits while their own work does not suffer.

Learn More about Continuous Discovery

For more on how to implement continuous discovery and other practical insights on working on agile teams, take the course, Agile Methods in UX Design.

Show Hide video transcript
  1. 00:00:00 --> 00:00:35

    About a little over a year ago, I got bored  and decided to start a fight on Twitter; you know – as you do; as I do. And I asked Design Twitter,  "What do you hate about agile?" And then just to kind of kick the hornet's nest a little  more, I asked product folks the same thing, and I got a few responses! I got kind of a lot of responses, actually, and some of them were really interesting, and a lot of them were really similar, and the complaints all seemed to fall into these few different categories.

  2. 00:00:35 --> 00:01:01

    But the biggest similarity was that *none of the things* that people were complaining about *seemed particularly agile* to me – at least, I mean they weren't the kind of agile teams that I had been on or led, and I got kind of interested and I ended up having these more in-depth conversations with a bunch of folks. So, I did more research because – you know – *of course* I did; I am a user-centered designer – kind of my thing. For this research, we got people to tell us stories about their teams,

  3. 00:01:01 --> 00:01:34

    and what they considered agile to be, what worked, what didn't, what they loved, what they hated, especially what they hated, because those are always the most fun stories. They're also why I won't be identifying any of the research respondents by name here. They were all promised confidentiality,  and I don't burn my sources. Anyway, I got stories from literally hundreds of people, and again I had more in-depth conversations with lots of them, trying to get sort of a range of folks. I didn't just talk to designers. I talked to product people, engineers, some folks at agencies, big companies, small companies, obviously designers.

  4. 00:01:34 --> 00:02:00

    I even talked to people working in governments. What I *rarely saw* was something that I would describe as *an actually agile team*. I started working with the Interaction Design Foundation to write a course for new designers. And I decided to write a course about designing for agile teams because based on their research it was something that *their* students had been asking for for a bunch, and it turns out the designers I had chatted with weren't the only ones who had trouble figuring out

  5. 00:02:00 --> 00:02:05

    how to design on agile or agile-ish teams, which is not surprising.

If you’re short on time for an entire course, take this hour-long Master Class by Teresa Torres, in which she explains how to use the opportunity solution tree.

Continuous discovery is not just an adaptation of research for agile but a fundamental shift in mindset. Here are three mindsets that you need to approach continuous discovery and get the desired outcomes.

Read Marty Cagan’s views on continuous discovery and other agile concepts here.

Desirée Sy’s article in the Journal of Usability Studies explains how the team at Autodesk incorporated user research into their agile processes in the early days of Agile.

Earn a Gift, Answer a Short Quiz!

  1. Question 1
  2. Question 2
  3. Question 3
  4. Get Your Gift

Question 1

What is an important difference between project-based discovery and continuous discovery in agile teams?

1 point towards your gift

Literature on Continuous Discovery

Here's the entire UX literature on Continuous Discovery by the Interaction Design Foundation, collated in one place:

Learn more about Continuous Discovery

Take a deep dive into Continuous Discovery with our course Agile Methods for UX Design .

Agile, in one form or another, has taken over the software development world and is poised to move into almost every other industry. The problem is that a lot of teams and organizations that call themselves “agile” don’t seem to have much in common with each other. This can be extremely confusing to a new team member, especially if you’ve previously worked on an “agile” team that had an entirely different definition of “agility”!

Since the release of the Agile Manifesto in 2001, agile methodologies have become almost unrecognizable in many organizations, even as they have become wildly popular. 

To understand the real-world challenges and best practices to work under the constraints of agile teams, we spoke with hundreds of professionals with experience working in agile environments. This research led us to create Agile Methods for UX Design.

In this course, we aim to show you what true agility is and how closely agile methodologies can map to design. You will learn both the theory and the real-world implementation of agile, its different flavors, and how you can work with different versions of agile teams.

You will learn about the key principles of agile, examples of teams that perform all the agile “rituals” but aren’t actually agile, and examples of teams that skip the rituals but actually embody the spirit.

You’ll learn about agile-specific techniques for research and design, such as designing smaller things, practicing continuous discovery, refactoring designs, and iterating.

You will also walk away with practical advice for working better with your team and improving processes at your company so that you can get some of the benefits of real agility.

This course is aimed at people who already know how to design or research (or who want to work with designers and researchers) but who want to learn how to operate better within a specific environment. There are lots of tools designers use within an agile environment that are no different from tools they’d use anywhere else, and we won’t be covering how to use those tools generally, but we will talk about how agile deliverables can differ from those you’d find in a more traditional UX team. 

Your course instructor is product management and user experience design expert, Laura Klein. Laura is the author of Build Better Products and UX for Lean Startups and the co-host of the podcast What is Wrong with UX?

With over 20 years of experience in tech, Laura specializes in helping companies innovate responsibly and improve their product development process, and she especially enjoys working with lean startups and agile development teams.

In this course, you will also hear from industry experts Teresa Torres (Product Discovery Coach at Product Talk), Janna Bastow (CEO and Co-founder of ProdPad) and Adam Thomas (product management strategist and consultant).

All open-source articles on Continuous Discovery

Please check the value and try again.

Open Access—Link to us!

We believe in Open Access and the democratization of knowledge. Unfortunately, world-class educational materials such as this page are normally hidden behind paywalls or in expensive textbooks.

If you want this to change, , link to us, or join us to help us democratize design knowledge!

Share Knowledge, Get Respect!

Share on:

or copy link

Cite according to academic standards

Simply copy and paste the text below into your bibliographic reference list, onto your blog, or anywhere else. You can also just hyperlink to this page.

Interaction Design Foundation - IxDF. (2022, February 22). What is Continuous Discovery?. Interaction Design Foundation - IxDF.