Module 1: Why Discovery

Continuous discovery vs. big-bang research

Next →

Overview

Lesson 2 showed there are cheaper ways than building to learn. But how that learning is organized over time matters almost as much as which method you choose. There are two opposite patterns, and almost every team naturally falls into one of the two without ever deciding to on purpose.

The first is big-bang research: a concentrated research phase, almost always at the start of a big project — two weeks of interviews, a findings report, a presentation to the team — after which the team spends months building without talking to a user again until the next big project. The second is continuous discovery: small, frequent contact with users, every week, no matter what stage the project is in — not a phase that starts and ends, but a habit that never stops. This lesson shows, with numbers, why the second pattern produces a team that knows more, more often, with the same — or less — total effort.

How this connects to the module. Lesson 2 established that there are cheap ways to learn; this lesson adds the time dimension: it's not enough to choose a cheap method once — you need a rhythm that keeps the team informed all the time, not just at the start. Lessons 6 and 7 of this guide (the full module) — talking to users as a habit, and the opportunity solution tree as a living map — only work if discovery is continuous; an opportunity solution tree built once and never updated is as useless as an outdated map.

An analogy: the annual checkup vs. the emergency room

Think about two ways of taking care of your health. The first: you never go to the doctor, until something hurts so much you end up in the emergency room — and only then do they run every test, diagnose you, and act. The second: a small, low-cost annual routine checkup that catches problems while they're still manageable, well before they become an emergency.

The emergency room is expensive, stressful, and arrives late — the problem is already advanced by the time it finally gets treated. The annual checkup is cheap, routine, and catches things early — but it only works if it's truly annual, not a one-time checkup you did once five years ago and never repeated. Big-bang research is discovery's emergency room: it kicks in once there's already a big, visible problem (a failed launch, a bet that moved nothing), and by then it's already late and expensive. Continuous discovery is the annual checkup — small, repeated, and precisely because of that, able to catch problems while they're still cheap to fix.

Worked example: the same quarter, two patterns of user contact

Imagine a 12-week quarter at Mercado. In one pattern, the team spends the first two weeks on intensive research and then doesn't talk to a user again for the remaining ten weeks — classic big-bang research. In the other, the team keeps up a contact rhythm every two weeks, no matter what it's working on — continuous discovery.

// Compares two patterns of user contact across a quarter (12 weeks).
// 1 = there was real user contact that week, 0 = there wasn't.
function longestSilence(pattern) {
  let longest = 0;
  let current = 0;
  pattern.forEach((hadContact) => {
    current = hadContact ? 0 : current + 1;
    longest = Math.max(longest, current);
  });
  return longest;
}

const bigBangResearch = [1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
const continuousDiscovery = [1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0];

console.log('=== User contact over a 12-week quarter ===\n');
[
  { name: 'big-bang research', pattern: bigBangResearch },
  { name: 'continuous discovery', pattern: continuousDiscovery },
].forEach(({ name, pattern }) => {
  const contactWeeks = pattern.filter(Boolean).length;
  const silence = longestSilence(pattern);
  console.log(name + ': ' + contactWeeks + '/12 weeks with contact, longest silence = ' + silence + ' weeks in a row');
});

What to expect. When you run the file with Node, the output is exactly this:

=== User contact over a 12-week quarter ===

big-bang research: 2/12 weeks with contact, longest silence = 10 weeks in a row
continuous discovery: 6/12 weeks with contact, longest silence = 1 weeks in a row

Notice the number that actually matters here, and it isn't the total weeks with contact — it's longestSilence: big-bang research, despite having invested two full weeks of research up front (more concentrated effort than any single week of continuous discovery), ends the quarter with 10 weeks in a row with no real user contact at all. Anything that changed in user behavior, any new assumption that came up during the build, any signal that the direction is wrong — none of it reaches the team during those 10 weeks, because the "discovery phase" was already declared closed.

Continuous discovery, with less concentrated effort (no week dedicated entirely to research), never lets more than one week pass without a fresh signal. It's not that the continuous discovery team "knows more" in some absolute sense by the end of the quarter — it's that it's never more than a week out of date, while the big-bang research team spends most of the quarter operating on information that's two months old or more.

Why big-bang research "forgets" about discovery, without anyone deciding to

Nobody explicitly decides "we're going to stop talking to users after week 2". What happens, in practice, is more subtle: the research phase produces a report, the report gets presented, the team moves into "build mode", and from there the calendar fills up with sprints, code reviews, and deploys — none of which, by default, has a slot reserved for talking to a user. Discovery doesn't get canceled; it just stops having a place on the agenda, and once that happens, it takes active effort to pick it back up — effort that competes against the delivery rhythm already in motion. Continuous discovery avoids this problem by solving it backward: instead of treating user contact as something you have to "find time for", it treats it as a fixed block on the calendar, with the same priority as a planning meeting — small, recurring, and precisely because of that, hard to accidentally cancel.

Common mistakes

Confusing "we did research once" with "we do discovery". What happens: a team points to a research phase it did six months ago as evidence that it "knows its users", and uses that old research to justify new decisions. Why it happens: the past research was real and did cost real effort — it feels unfair to treat it as if it didn't count. How to spot it: when someone asks "how do we know this?", the answer always points to the same research, no matter how much time has passed since then. How to fix it: ask yourself how many weeks of silence (as in today's example) have passed since that research. Users, the product, and the market change; information from six months ago isn't automatically false, but it isn't automatically current either.

Scheduling discovery "whenever there's time". What happens: the team agrees, in principle, that talking to users regularly is valuable — but never reserves a fixed slot for it on the calendar, so it competes every week against more urgent delivery deadlines, and almost always loses. Why it happens: discovery doesn't have, on its own, the visible urgency of a sprint with a delivery date — it's easy to postpone it "one more week" indefinitely. How to spot it: if you ask the team when the last real conversation with a user happened, the answer is vague ("a while ago") instead of a concrete, recent date. How to fix it: treat user contact as a fixed, recurring block on the team's calendar — not as something done "whenever there's time left over". That's, literally, today's continuousDiscovery pattern: small and regular, not big and occasional.

Thinking continuous discovery means "discovery all the time, about everything". What happens: on hearing "continuous discovery", someone understands it as having to research every assumption of every bet, all the time, nonstop — and the team burns out trying to sustain that pace. Why it happens: "continuous" sounds like "constant and exhaustive", when it actually describes the cadence (never letting too much time pass without contact), not the volume of work per week. How to spot it: the team reports feeling overwhelmed by discovery, with long, exhaustive sessions every week. How to fix it: look again at the worked example — today's continuousDiscovery pattern has less concentrated effort than bigBangResearch (no week of intensive, full-time research), and still closes almost every silence gap. Continuous discovery is small and frequent, not big and constant.

Exercises

Exercise 1 — Calculate a third pattern. Without running Node, imagine a 12-week pattern where the team talks to users in weeks 1, 5, and 9 ([1,0,0,0,1,0,0,0,1,0,0,0]). Calculate how many weeks had contact and what longestSilence is. Compare it to the two patterns from the worked example.

See solution

This pattern has 3/12 weeks with contact (fewer than continuousDiscovery, which had 6) and a longestSilence of 3 weeks (between week 1 and week 5, and between week 5 and week 9, both 3-week gaps of silence). Compared to bigBangResearch (longestSilence = 10), this quarterly pattern is much better — there's never more than 3 weeks without contact—, but compared to continuousDiscovery (longestSilence = 1), it still leaves considerable gaps. The exercise shows that "continuous" isn't binary: there's a spectrum between total silence and weekly contact, and the shorter the longestSilence, the faster the team detects a change or a problem.

Exercise 2 — Diagnose your own team (or one you know). Without running Node, describe in words the real user-contact pattern of a team you know —does it look more like bigBangResearch or continuousDiscovery?— and estimate its approximate longestSilence in weeks.

See solution

There's no single answer —it depends on the team you pick—, but the exercise wants you to apply the longestSilence criterion, not a vague impression of "we talk to users regularly". Many teams, doing this exercise honestly, discover their real longestSilence is several months, even though they have a general sense of being "connected to the user" — that sense comes from a memorable past research effort, not from a recent, verifiable contact pattern, exactly the mistake named above.

Exercise 3 — Design a minimum viable pattern. For a team with very little available time (only 2 hours a week for discovery), design a 12-week pattern (like the ones in the example) that keeps longestSilence at 2 weeks or less, with the smallest possible number of contact weeks.

See solution

A pattern that meets the condition with minimum effort: contact every 3 weeks — [1,0,0,1,0,0,1,0,0,1,0,0] — gives 4/12 weeks with contact and a longestSilence of 2 weeks (the maximum allowed). Weekly contact isn't necessary (like continuousDiscovery, which used 6 weeks) to keep a reasonable longestSilence — with a cadence of every 3 weeks, the team invests half the effort of continuousDiscovery and still never goes more than two weeks blind. The point of the exercise: the discovery habit can be adjusted to a team's real time budget, as long as it stays regular — irregularity, not low frequency, is what produces the long, dangerous gaps of big-bang research.

Summary and next step

In this lesson you compared two ways of organizing discovery over time: big-bang research, a concentrated phase at the start that leaves the team, in today's example, 10 weeks in a row with no fresh signal from real users; and continuous discovery, a small, regular habit that never lets more than a week pass without contact. You saw that the continuous pattern doesn't demand more total effort — it demands regularity, not volume — and that the difference between the two patterns isn't how much research gets done, but how much time the team spends operating blind between one signal and the next.

Before moving on you should be able to: explain the difference between big-bang research and continuous discovery without using the word "phase"; calculate the longestSilence of a given contact pattern; and design a discovery pattern that fits a limited time budget, without sacrificing regularity.

Lesson 4 takes today's bigBangResearch pattern —the near-total absence of user contact before building— and puts an exact cost on it for Mercado's real case: how much does it concretely cost to build recommendations without having validated the risky assumption first?

Resources

← PreviousBuilding is the most expensive way to learnNext →The cost of building the wrong thing