# The Weekly Research Cadence > Project-based research cannot keep up with a team that ships daily. This is the > weekly version: a fixed rhythm, three hours total, that produces evidence at > the rate decisions are being made. Includes a plain position on synthetic > users, because the question comes up in week one. --- ## Why weekly and not per project A research project answers a question that was asked six weeks ago. When generation is cheap, the questions turn over faster than a project can close, and the team stops waiting. They do not stop deciding, they just decide without you. A cadence changes what research is for. Not "answer this question by the review," but "keep a standing supply of fresh contact with reality, so the team is never more than a week from a real user." --- ## The week Three hours, spread. Same slots every week, on the calendar, treated like a standup rather than an event. | Day | Slot | What happens | Who | |---|---|---|---| | Monday | 30 min | Pick the week's question. One. Write it down. | Designer plus PM | | Tue to Wed | 90 min | Contact. Two to four sessions, thirty minutes each. | Designer runs, anyone can watch | | Thursday | 30 min | Synthesis. What changed, what did not, what to do. | Whoever ran the sessions | | Thursday | 30 min | Register update and one line to the team. | Same person | That is the whole cadence. The discipline is in the constraints, not the volume. --- ## The Monday rule: one question One question per week, written as a sentence with a question mark, narrow enough to answer in four conversations. Good: "When people ignore the suggested reply, what do they do instead?" Bad: "How do users feel about the suggestions feature?" The second one cannot be answered, only discussed, and discussion is what happens when a question is not sharp enough. Where the question comes from, in priority order: 1. A decision being made this week that lacks evidence. 2. A row in the evidence register that expired. 3. A disagreement in the last rubric review that turned out to be about users rather than about the rubric. 4. Something from support that has now come up three times. If nothing qualifies, do not manufacture a question. Skip the week and do a review of old sessions instead. A cadence that runs on invented questions trains everyone to ignore the output. --- ## Who you talk to Rotate deliberately or you will hear from the same enthusiasts forever. | Week | Segment | |---|---| | 1 | Active users of the surface in question | | 2 | People who tried it and stopped | | 3 | People who never adopted it | | 4 | Internal, support or sales, who hear the complaints | Week 2 is the one teams skip and the one that pays. Abandoners tell you things active users cannot, because active users have already adapted to the thing that is wrong. --- ## Recruiting without a research ops team Keep a standing list of people who agreed to be contacted, refreshed as you go. A short list you actually use beats a large panel you do not. Fastest sources when the list runs dry: recent support conversations that were resolved well, people who filled in a feedback form, and customers your account team already talks to weekly. All three are faster than a formal recruit and all three carry a bias you should name in the register row. --- ## Sessions: thirty minutes, three parts **Minutes 0 to 5.** What they did most recently in the product, in their words, without prompting. **Minutes 5 to 25.** The week's question. Watch more than you ask. If you can get them to do the thing rather than describe it, do that instead, every time. **Minutes 25 to 30.** The two questions that surface what you did not ask about: what did you expect to happen that did not, and what did you stop doing since the last time we spoke. Record if permitted, and keep the notes short. Ninety minutes of transcript that nobody re-reads is not evidence, it is an archive. --- ## Synthetic users: the position Worth being direct about, because the tooling is good enough now that the question is live. **Where they work.** - Stress-testing an interview guide before you use it on real people. Cheap, and it catches leading questions. - Generating edge-case inputs for evals. A synthetic user producing weird, malformed, or adversarial inputs is useful, because you are testing the system, not learning about people. - Rehearsing a difficult session when the real ones are scarce and you get one shot. - Coverage checks: does the flow break for a persona you have no access to. **Where they lie.** - Anything about motivation. A synthetic user will produce a plausible reason for a behavior it never had. Plausible reasons are exactly what you cannot get from real people either, which is why we watch behavior instead. A synthetic user gives you the confident version of the least reliable data type. - Anything about willingness to pay. Confidently wrong, every time. - Anything about frequency or prevalence. Synthetic populations are not samples and treating a distribution of generated answers as a survey is a category error with a chart attached. - Novelty. They reproduce what is documented. The thing you did not know to ask about is precisely what they cannot surface. **The rule.** Synthetic users are a tool for testing your instruments and your system. They are not a source of evidence about humans, and no row in the evidence register cites them as one. --- ## What the cadence produces Each week: one register row, one line to the team, one thing changed or deliberately not changed. Each quarter: enough rows that a planning conversation can cite evidence instead of opinions, which is the entire point and takes about a quarter to become noticeable. --- ## The one thing to do this week Put the four slots on the calendar for the next four weeks and pick Monday's question now. Do not build a research plan. The plan is the calendar, and the first week will be scrappy, which is fine because week five will not be. --- _From "Research at Generation Speed", chapter 17 of The Design Operating Model._ _falkster.com/design/research-at-generation-speed_