The need to be informed
All product teams share an archetypal challenge: we are groups of people trying to build something together in an uncertain and constantly evolving environment. An invariant feature of this challenge is that to continue successfully, we must have a clear view of the relevant context we're addressing. We need to be appropriately informed.
We need to be informed about the customer workflows we build for, about current conditions in the market, about how our existing product and service offerings are performing, about the unrealized opportunities and unmet needs we hope to serve. (It is quite possible to proceed — for a while — without being informed; I won't recommend it here.)
For the last decade and then some, product teams delivering products and services have turned to the functional expertise of user research (or design research, UX research, product research) to build the connection to context that allows for effective decision-making. To be informed.
Project as dominant paradigm
A researcher or research team is the means of resolving a large class of qualitative product and design questions that product teams face. Questions about how customers work, think, and act; questions about product performance and unexpected opportunities; questions about how customers will act on the team's new concepts, untested assumptions, and emerging hypotheses.
The package that unites these kinds of questions with their answers draws on academic rigor and insight from the disciplines of management, design, psychology, and human-computer interaction: a project. A linear, time-bound, and generally time-intensive research project. From 2-3 weeks up to 2-3 months, it goes something like this: identify the meaningful questions and target context, create a research plan, recruit appropriate participants, undertake research interviews, make sense of what was seen, synthesize, and report on implications or recommendations.
In an academic context, where we must work with rigor, it makes sense: framing the project package helps ensure we're generating useful knowledge on top of what was previously known, and that can, in turn, be built upon.
In a waterfall development context, where specifications must be fixed up-front and developed over long time cycles, it makes sense: framing the project well ensures we'll uncover enough of the context we need for longer-term design and product decisions.
In a modern software development context — given a self-aware, and self-directed product team — framing research projects as the primary means of informing that team is beginning to make less sense, primarily due to decision-cycle time.
Modern teams move faster than their research projects do. It's common to see a one- or two-week cadence for experiments, assumptions, and small-to-medium-size product decisions. This means that the product itself, current-state assumptions, key questions, and even target user profiles can change dramatically before a research project resolves and reports back.
So, for a certain, crucial kind of being informed — a reliable connection to customer context that allows teams to rapidly test assumptions, uncover new opportunities, or understand focused areas of user behavior — the research project may not be the best tool for the job.
Continuous discovery as emergent paradigm
What we'll call the emerging paradigm is not novel, it just hasn't coalesced until quite recently. Decades of product lore already proclaim that customer understanding is key, that the team needs to "get out of the building," that they need to fall in love with the problem [space].
Teams have instantiated this work under the banners of customer calls, ride-alongs, customer councils, product advisory boards, rolling research, lean UX, lean startup methods, and much more. In her 2021 book Continuous Discovery Habits, Teresa Torres named and framed an ongoing set of these practices as "continuous discovery," focused on the habits product teams employ to effectively decide what to build.
The simple idea underlying continuous discovery is that, just as a product team's ownership of their solution and product surface area doesn't neatly begin and end in a time-boxed fashion, neither should their relationship with and connection to the context of customer problem space. Their means of being informed.
Torres describes continuous discovery as a way of working as opposed to the project-based work traditionally run by researchers. From my vantage point consulting with product teams, it appears more as a spectrum, but taking these far poles as distinct modes of working helps to highlight the shift that's underway:
Project-based research:
- Weeks-to-months long efforts where a block of investigative activities are undertaken and synthesized as a whole.
- The research team is the primary owner, driver, and participant.
- A fixed project brief dictates participants, research questions, timelines, and context areas under investigation.
- A report document captures the output of the research cycle, after primarily interviewing is complete and the researchers have moved through analysis and synthesis, ideally involving the entire team. The report is used as a vehicle to drive action.
- Long cycle times. Simpler to instantiate any given cycle, especially with an in-house research team. Projects can be parallelized, purchased, outsourced.
Continuous discovery:
- Ongoing, continuous efforts marked primarily by a ~weekly cadence of customer conversations that are synthesized individually in a step-wise fashion.
- The product team is the primary owner, driver, and participant.
- An evolving experience map and opportunity-solution tree dictate participants, research questions, timelines, and context areas under investigation.
- Interview snapshots are produced from discussion with the entire team, and directly influence the work and assumptions at hand. Insights are accreted and fed back into the experience map and opportunity-solution tree as new understanding is consolidated through discussion of patterns.
- Short cycle times. Difficult to instantiate an effective practice, requires effort and reflection over repeat cycles. As a function of the product team, continuous discovery can't be outsourced. Product teams can invest in coaching or training.
A research project creates a separation between problem space and product solution, freeing the researcher[s] to decouple from the co-evolving solution and look at the problem space freely. That look is filtered through a roughly-fixed perspective generated during in project brief. The continuous discovery paradigm does the opposite: it forces the team to recognize their problem space and its opportunity co-evolve with their assumptions, hypotheses, concepts, and product itself.
Continuous discovery, when employed well, creates a special kind of informed-ness that allows the product team to accelerate their decision-making. The intertwingled and evolving reality of ⟦problem-space ↔ opportunity-space ↔ product-offering⟧ must be a shared understanding within the product team: discussable, challenge-able, and an actively present awareness in the product team members' minds.
A crucial difference, then, is that the product team must also be the owners of the continuous discovery practice: those who own the evolving solution, should own the evolving understanding of the problem space and its tractable edges.
The accompanying visuals — expressed as an experience map, and an opportunity-solution tree in Teresa Torres' framing — help characterize that understanding and bring outsiders in. But for the team to move forward effectively, these visuals only act as an external verification and expression of the critical thinking that has already led to a collective internalized understanding that moves at the same tempo as the team itself.
Continuous discovery qualifiers
Continuous discovery doesn't work for all teams in all situations. To understand where it makes sense, we have to ask who is being informed and how they're working.
I see three prime qualifiers that indicate whether a continuous discovery approach will make sense for a product team:
- The product team is actively building product or solution concepts,
A product team means, at the least, one representative of the engineering, design, and product perspective. Actively building solution concepts means that there is a built instantiation of a solution that the team is evolving, acting on, and making decisions for. (If you're familiar with Wardley Mapping, this is an approach suited to teams operating in the Custom-Built and Product spaces.) - With an outcome-focused scope,
The team needs to be actively building toward an outcome — some measurable criteria that are going to help us understand whether or not they are making progress. These outcomes may be framed in any number of ways, and tend to describe a real and concrete shift of behavior in the problem space. - And self-directed autonomy for developing solutions.
Finally, the team must have the latitude to move in previously unseen directions to achieve their outcome. Decisions carry signals: the hallmark of adaptive agility is the team's ability to sense and respond appropriately to the results of their decisions: product changes, assumptions tests, hypothesis tests, and new learning.
These qualifiers don't mean continuous discovery will be successful for a team that meets them; they indicate that it can be employed, and might be an effective approach for guiding the weeks-to-months-long outlook for the team.
Ingredients for successful continuous discovery
So for the right kind of team, continuous discovery makes sense. Then what does "good" look like? How do we ensure that this approach is going to make the team more effective?
As with any organizational work, so much relies on the operating culture of the company, and the internal trust and operations of the product team itself. But some invariant ingredients exist. So far I've come to see four such that, when any one of them is not in place, the theoretical efficiency of continuous discovery does not deliver in practice.
Teams working in a continuous mode must have:
- A problem-space point of view,
This is the basis of "being informed," and it must be framed from a user- or customer-centric point of view. Teresa Torres recommends an experience map as the visual expression of understanding the problem space, and it's an excellent starting point. Underneath that map, it means the team understands what customers are trying to achieve, how they go about doing so, and evolve this understanding as the basis of their decision-making. - An opportunity-space-and-assumptions point of view,
The bridge from problem-space to product opportunity-space is what helps teams identify the options on the table towards achieving their outcomes, and the assumptions those opportunities rely on that can be concepted, explored, and tested. You may be familiar with idea backlogs, prioritization frameworks, or risk/assumption dashboards to create this connection; Teresa Torres recommends an elegant and evolving tree structure. In project mode, this often lives as a static element in the "recommendations" section of the research report. - Broad participation in customer conversations,
Continuous discovery is meant to equip teams with real agility, and that agility relies on holding shared understanding and interpretation of the problem-space. Research reports that come from interviews the team did not engage in are often boiled down in hopes that the team will absorb the Big Ideas. In continuous customer conversations, that absorption occurs through ongoing, team-wide participation in customer conversations. The Big Ideas surface through the post-interview debrief discussions of their implications. - And active discussion with honest introspection.
It's not just the teams' understanding that has to evolve, though: it's also their continuous discovery practice. The only way this happens is through discussion about the results of customer conversations, and honest reflection. The team needs to discuss what was seen, and what it means for their work (that's core to #3 above). They also have to honestly assess if they're getting the kind and quality of information they need to move efficiently: if not, why?, and what are we going to do about it?
These ingredients form the beginning of a self-guided and self-correcting continuous discovery practice that will inform the specific and actual questions the team must answer as their solution space evolves and changes the problem space it's targeting. It can, dramatically, increase the speed and efficiency of teams who are comfortable navigating uncertainty with lean or agile methods.
And it's exciting, but not surprising, to see the once-familiar project ground shifting underfoot. In any organization, research serves a larger purpose, it's part of a larger practice that needs to be well-informed. As that practice shifts, so will the ways that we gather and make sense of the requisite information.
Evolutionary shifts enable the new paradigm
Over the last few years, I've seen more and more product teams work in a more continuous mode. (An admittedly small sample size of in-house teams and clients, and a biased selection at that.) The new paradigm begins to make more sense now that three underlying pieces have evolved into the right place.
The first evolutionary shift is the reason the project paradigm doesn't suit autonomous/self-directed product teams who are moving fast. The next two, firming up in the last few years, are the reason continuous discovery is about ready for early majority adoption.
- Decreasing product decision and delivery cycle times,
Everything is accelerating. This shift started some 15 years ago when the collective set of practices known as DevOps allowed for continuous integration and continuous deployment of code. That dramatic reduction of cycle time has now worked its way up the stack into product practice. [Informed] decisions need to happen faster than ever before. - Productization and operationalization of research activities,
Access to customers is key. Ten years ago, sourcing participants and setting up interviews took days of work, over multiple weeks. Criteria had to be defined and project-ized; incorrect specification led to massive waste of effort. Now, off-the-shelf product platforms allow for near-instant recruiting of target audiences, in-house query tools help teams contact specific customer profiles immediately, and products handle all manner of previously specialized coordinating, scheduling, recording, and transcription work. - And increasingly understood research best practices.
Research is neither complex nor magical. It's a straightforward path for product teams to get to "good enough" at interviewing practices and sensemaking through robust and accessible learning (books, blogs, videos, workshops, conferences, coaches, consultants, trainers) and honest reflection. So long as there is a desire to learn and improve, performing reasonable customer interviews and assumption tests is a matter of practice; there is no dark art that only well-trained researchers possess.
It's important to note that research isn't going anywhere. Where there are decisions made in the face of uncertainty, there will always be the need to inform those decisions according to the level of risk they carry. How product teams achieve informed decision-making is evolving, because the context of product delivery is evolving.
Looking forward
I expect most product teams working on non-regulated, non-infrastructural, user/customer-facing products will come to operate some form of self-directed continuous discovery as their primary model for near-horizon insights.
We'll see further automation of basic research activities, simpler frameworks for conducting useful interviews and making sense of patterns, and more and more refined knowledge about what product teams should do to move their work forward efficiently.
And (I hope) that change will lead to a stronger and more nuanced perspective on the kinds of questions where it remains expedient and cost-effective to deploy project-based research. Foundational and complex questions that aren't tied to the near-term direction of an actively evolving product line; longer-term, more strategic efforts.
This essay is part of my larger exploration of the evolution of research and its integration with new product practices and the larger organization.
For weekly updates on upcoming essays, contextual commentary, and personal prognostication, sign up for the newsletter on my homepage, davesresearch.com.
