{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-08-21T09:56:11.775Z"},"content":[{"type":"documentation","id":"c5461609-d28e-44e5-96c1-0648f83ee0cc","slug":"research-lead-time-littles-law","title":"Research Lead Time: Why a Six-Day Study Takes Six Weeks (Little's Law for Research Teams)","url":"https://www.koji.so/docs/research-lead-time-littles-law","summary":"Research lead time is governed by Little's Law: average wait equals work-in-progress divided by throughput. A team finishing two studies a week with twelve open has a six-week lead time regardless of study efficiency. Halving study duration cuts about 8 percent off the answer date; halving work-in-progress cuts 50 percent. Little's Law holds independent of queue discipline, so prioritisation changes who waits, not the average wait.","content":"**Bottom line up front:** The time between a stakeholder asking a question and getting an answer is not set by how long the study takes. It is set by how many studies are already open. Little's Law fixes the relationship exactly: average wait equals average work-in-progress divided by average completion rate. A team finishing two studies a week with twelve studies open has a six-week lead time no matter how efficient any single study is. Halving the duration of the study itself cuts about 8 percent off the answer date. Halving the number of open studies cuts 50 percent. Measure work-in-progress before you optimise anything else.\n\n## The number every research team reports is the wrong one\n\nAsk a research team how long a study takes and you will get the duration of the work: \"about a week of fieldwork, a few days to analyse.\" Ask a product manager how long research takes and you will get a completely different number: \"six weeks, if you are lucky.\"\n\nBoth people are telling the truth. They are describing different quantities, and only one of them is the quantity that decides whether research gets used.\n\nThe researcher is reporting **touch time** — the hours during which somebody is actually working on that study. The stakeholder is reporting **lead time** — the elapsed calendar time from the moment they asked to the moment they got an answer. In every research function that has more requests than it can start at once, these two numbers are separated by a queue, and the queue is usually the larger part.\n\nThis distinction is not a matter of opinion or of how hard people work. It is arithmetic, and it has been settled since 1961.\n\n## Little's Law, and why it applies to a research team\n\nIn 1961 John D. C. Little published a proof of the queuing formula L = λW in *Operations Research* 9(3):383-387. The relationship is now known as Little's Law, and it says something disarmingly simple:\n\n> The average number of items in a system (L) equals the average arrival rate (λ) multiplied by the average time each item spends in the system (W).\n\nRearranged for the quantity research leaders actually care about:\n\n**Lead time = work-in-progress / throughput**\n\nTwo objections usually arrive at this point, and Little addressed both. Writing on the law's fiftieth anniversary in *Operations Research* 59(3):536-549, he noted that \"Little's Law holds under remarkably general conditions\" and — critically for anyone who runs a prioritised backlog — that it holds \"independent of queue discipline.\" Typical queue disciplines include serving items first-in-first-out, or by priority class. As Little puts it, \"No assumption has been made about order of service.\"\n\nThat matters enormously. It means your prioritisation framework, however good, cannot rescue your lead time. Reordering a queue changes *whose* study is fast; it does not change the average wait. If you run [RICE scoring](/docs/rice-prioritization-framework) or [Weighted Shortest Job First](/docs/wsjf-prioritization-guide) over the backlog, you are choosing who waits, not shortening the wait.\n\nThe second objection is that research is creative work, not a factory. Little's Law does not care. It applies to any system where things arrive, spend time, and leave. As Little writes, it \"provides structure for thinking about any operation that can be cast as a queue.\" A request for research arrives, spends time, and leaves. That is a queue.\n\nAnd the law is a conservation relation, not a tendency. In Little's words, it \"locks the three measures together in a unique and consistent way for any system in which it applies.\" You do not get to pick all three.\n\n## The arithmetic: where five of your six weeks go\n\nTake a small research function: two researchers, finishing on average two studies per week between them, with twelve studies open at any given time. Open means committed to, acknowledged, scoped, or half-analysed — anything the team considers live.\n\nLead time = 12 / 2 = **6 weeks**.\n\nNow look at the touch time. Suppose one of those studies genuinely absorbs five working days of human effort. The flow efficiency — touch time divided by elapsed time — is 1 week / 6 weeks = **16.7 percent**. Roughly five of every six weeks the requester waits, no one is touching their study.\n\nHold throughput constant and vary only the number of open studies:\n\n| Studies open (WIP) | Throughput | Lead time | Flow efficiency |\n| --- | --- | --- | --- |\n| 12 | 2 / week | 6.0 weeks | 16.7% |\n| 8 | 2 / week | 4.0 weeks | 25.0% |\n| 6 | 2 / week | 3.0 weeks | 33.3% |\n| 4 | 2 / week | 2.0 weeks | 50.0% |\n| 2 | 2 / week | 1.0 week | 100.0% |\n\nNothing in that table required anyone to work faster, recruit faster, or analyse faster. Throughput is fixed at two studies per week in every row. The only thing that changed is how many things were open at once.\n\n## Why \"make the study faster\" barely moves the answer date\n\nThis is where most research improvement programmes are aimed at the wrong term, and the arithmetic is brutal about it.\n\nStart from the baseline above: a six-week lead time made of one week of touch time and five weeks of queue.\n\n| Intervention | What it changes | New lead time | Improvement |\n| --- | --- | --- | --- |\n| Halve the study duration | Touch time 1 week to 0.5 weeks | 5.5 weeks | 8.3% |\n| Halve the work-in-progress | 12 open studies to 6 | 3.0 weeks | 50.0% |\n\nHalving the duration of the work — an enormous methodological achievement — buys 8.3 percent. Halving the number of things open at once, which requires no new skill, tooling, or headcount, buys 50 percent.\n\nThe reason is simply that the intervention is being applied to the small term. When flow efficiency is 16.7 percent, five-sixths of the lead time is untouchable by anything you do to the study itself.\n\nThis is also why the reflex of running more studies in parallel to \"get more done\" is exactly backwards. Starting another study raises WIP, and by Little's Law raises the lead time of every study already open, including the new one. Work-in-progress is not free capacity; it is inventory, and it is paid for in calendar time by every stakeholder in the queue.\n\n## The lead-time spread nobody can explain by the work\n\nIf lead time were governed by the difficulty of the work, organisations doing similar work would have similar lead times. They do not, and the best-measured example comes from software delivery.\n\nGoogle's DORA programme has measured delivery performance across the industry for a decade. The 2024 *Accelerate State of DevOps Report* clusters respondents into four performance levels by change lead time:\n\n| Performance level | Change lead time | Share of respondents |\n| --- | --- | --- |\n| Elite | Less than one day | 19% |\n| High | Between one day and one week | 22% |\n| Medium | Between one week and one month | 35% |\n| Low | Between one month and six months | 25% |\n\nThe unit of work is the same in every band: one change. The spread between the top and bottom band is roughly two orders of magnitude. No plausible account of that gap is \"the low performers' changes are a hundred times harder.\" The gap is batching, queueing, and handoffs — the structure around the work, not the work.\n\nResearch functions have never been measured this way, which is precisely why the six-week number goes unchallenged. It is treated as a property of research rather than a property of a queue.\n\n## What one unit of research inventory actually is\n\nTo apply the law you have to count WIP honestly, and most teams undercount badly. A study is in the system from the moment the requester believes it has been accepted to the moment they have an answer they can act on. That includes:\n\n- Requests acknowledged in [intake](/docs/research-intake-process-guide) but not started\n- Studies in recruiting or field\n- Interviews recorded but not analysed\n- Analysis finished but the readout not yet delivered\n- Findings delivered but not yet written up anywhere the organisation can find them\n\nThat last category is the one teams forget, and it is the one that quietly inflates WIP the most. A study whose interviews are done but whose synthesis has not happened is still occupying a slot in someone's head, still generating status questions, and still not answering anybody's question. Under Little's Law it counts.\n\nThere is a human cost layered on top of the arithmetic. Sophie Leroy's work on attention residue (*Organizational Behavior and Human Decision Processes* 109(2):168-181, 2009) documents that people perform measurably worse on a new task when a previous task was left unfinished — the unfinished work continues to consume attention. High research WIP therefore does not merely divide time; it degrades the quality of each slice. The team is slower *and* the analysis is worse.\n\n## How to measure your own lead time in a week\n\nYou do not need a tool for this, and you should not buy one before you have the numbers.\n\n1. **Count WIP once.** Today, list every request the organisation believes is live, using the five categories above. Do not filter for \"really active.\" The requester's belief is what defines the queue.\n2. **Count throughput over four weeks.** How many studies reached a usable answer? Divide by four. This is your λ.\n3. **Divide.** WIP / throughput is your current lead time in weeks. Compare it to what your intake process promises.\n4. **Timestamp two events going forward.** Date requested, date answered. After a quarter you have a real distribution rather than an average, which is what you need for the harder question of [which decisions you can serve at all](/docs/unasked-research-questions-suppressed-demand).\n5. **Set a WIP limit and hold it.** Pick a number below your current WIP. New work starts only when something finishes. This is the single change that moves the date.\n\nStep 5 is where most teams stop, because holding a WIP limit means telling someone \"not yet\" out loud. The queue already told them \"not yet\" — it simply did it silently, six weeks at a time.\n\n## How Koji changes the arithmetic\n\nLittle's Law is a constraint, not a strategy: it tells you that lead time, WIP, and throughput are locked together, and that you must move one of them. AI-native research moves the term that manual research treats as fixed.\n\nThe reason research WIP runs high is that studies are slow to clear, and studies are slow to clear because the expensive stages are human-serial. One moderator can run one interview at a time. One analyst reads one transcript at a time. Throughput is therefore capped by headcount, which leaves WIP reduction as the only available lever — and WIP reduction means saying no.\n\nKoji raises throughput directly:\n\n- **AI-moderated interviews run in parallel.** Twenty participants can be in session simultaneously, so fieldwork stops being a scheduling exercise measured in weeks. The recruiting-to-transcript stage collapses from a calendar problem to a throughput problem.\n- **Voice and text interviews** let participants respond when it suits them, which removes the scheduling round-trip that silently adds a week to most qualitative studies.\n- **Automatic thematic analysis** clears the largest hidden WIP category — recorded but unanalysed. Analysis that used to sit in a queue for days is available as the interviews land.\n- **Real-time reporting** removes the gap between \"we know\" and \"they know,\" which is where findings go to age.\n- **Customisable AI consultants** encode your team's standards into the study itself, so quality does not depend on a scarce senior reviewer becoming available.\n\nThe structural point is that raising throughput does not just shorten lead time proportionally — it also relaxes the WIP limit you can afford. A team clearing eight studies a week can hold twelve open and still deliver in a day and a half. The same twelve at two a week is six weeks.\n\n[Structured questions](/docs/structured-questions-guide) matter here more than they first appear. Koji supports six types — `open_ended`, `scale`, `single_choice`, `multiple_choice`, `ranking`, and `yes_no` — and mixing them means a single study produces both quantified distributions and quoted reasoning in one pass. The traditional alternative is a survey to size the problem and interviews to explain it: two studies, two queues, two lead times. Collapsing them into one is a throughput gain that never appears on anyone's efficiency dashboard.\n\nNone of this makes prioritisation unnecessary. It changes what prioritisation is for. When lead time is six weeks, ranking the backlog decides who gets served this quarter. When lead time is two days, ranking decides what order things happen in this week — which is a far less consequential decision, and a far less political one.\n\n## Common mistakes\n\n**Reporting touch time to stakeholders.** Saying \"this takes about a week\" when the requester will wait six is the fastest way to lose credibility. Quote lead time. If it is embarrassing, that is information.\n\n**Treating a prioritised backlog as a solved queue.** Prioritisation is real work and it does allocate scarce capacity fairly. It does not shorten the average wait, and Little's Law is explicit that queue discipline is irrelevant to the relationship.\n\n**Counting only \"active\" studies as WIP.** If the requester thinks it is live, it is live. Undercounting WIP produces a lead-time estimate that is wrong in the flattering direction.\n\n**Adding parallel studies to look responsive.** Starting a study is the most expensive thing you can do to everyone already waiting. Responsiveness is a property of finishing, not of starting.\n\n**Optimising the stage you can see.** Transcription speed, template quality, and recruiting turnaround are all visible and all part of the small term. The queue is invisible and is the large term. Measure before you optimise, or you will spend a quarter buying 8 percent.\n\n## Frequently asked questions\n\n### What is research lead time?\n\nResearch lead time is the elapsed calendar time between a stakeholder requesting research and receiving an answer they can act on. It is distinct from touch time, which is the hours of actual work a study absorbs. In most research functions lead time is several times longer than touch time, because requests spend most of their life waiting in a queue rather than being worked on.\n\n### How do I calculate my team's research lead time?\n\nUse Little's Law: lead time equals work-in-progress divided by throughput. Count every request the organisation believes is live (including analysis not yet written up), then count how many studies reached a usable answer per week over the last month. Divide the first number by the second. A team with twelve open studies finishing two per week has a six-week lead time.\n\n### Does prioritising the backlog reduce lead time?\n\nNo. Little's Law holds independent of queue discipline, which means reordering the queue changes who waits but not the average wait. Prioritisation frameworks such as RICE and WSJF are useful for allocating scarce capacity to the highest-value questions, but the only ways to reduce average lead time are to reduce work-in-progress or to raise throughput.\n\n### What is a good flow efficiency for a research team?\n\nFlow efficiency is touch time divided by lead time. A team with a six-week lead time on a study containing one week of real work is running at about 17 percent, which is typical for knowledge work with a shared queue. Above 40 percent is strong. The figure is most useful as a trend for your own team rather than as an industry benchmark, since definitions of touch time vary widely.\n\n### Should I reduce work-in-progress or hire another researcher?\n\nReduce work-in-progress first, because it is free and immediate. Hiring raises throughput, which also cuts lead time, but it takes months to land and the new capacity is often absorbed by additional open studies rather than faster ones. If WIP is not limited, added headcount tends to raise WIP in step with throughput and the lead time barely moves.\n\n### Does AI-moderated research actually change the arithmetic?\n\nYes, because it attacks throughput rather than WIP. Human-moderated qualitative research caps throughput at one session per moderator at a time, which makes WIP reduction the only lever available. Running interviews in parallel and analysing them automatically raises the completion rate directly, which shortens lead time at the same WIP and lets the team keep more work open without penalising the queue.\n\n## Related Resources\n\n- [How to Build a Research Request and Intake Process](/docs/research-intake-process-guide) — the front door that feeds the queue this article measures.\n- [Time to Insight: How to Cut Research Cycles from Weeks to Hours](/docs/time-to-insight) — the stage-by-stage view of where elapsed time goes.\n- [Why a Fully Booked Research Team Is Slower](/docs/research-team-utilization-queue-time) — what happens to this arithmetic when the team runs near capacity.\n- [Research Pipeline Yield: Why Seven Good Stages Produce a Bad Finding](/docs/research-pipeline-yield-rolled-throughput) — the same series logic applied to quality rather than time.\n- [Structured Questions Guide](/docs/structured-questions-guide) — the six question types that let one study replace two.\n- [ResearchOps: The Complete Guide to Scaling Research Operations](/docs/research-ops-guide) — where WIP limits sit in a wider operating model.\n","category":"Research Operations","lastModified":"2026-08-21T03:26:55.189567+00:00","metaTitle":"Research Lead Time: Why a Six-Day Study Takes Six Weeks (2026)","metaDescription":"Little's Law for research teams: lead time = WIP / throughput. Why halving study duration buys 8% and halving open studies buys 50%.","keywords":["research lead time","little's law","research work in progress","flow efficiency research","research turnaround time","research queue","researchops metrics"],"aiSummary":"Research lead time is governed by Little's Law: average wait equals work-in-progress divided by throughput. A team finishing two studies a week with twelve open has a six-week lead time regardless of study efficiency. Halving study duration cuts about 8 percent off the answer date; halving work-in-progress cuts 50 percent. Little's Law holds independent of queue discipline, so prioritisation changes who waits, not the average wait.","aiPrerequisites":["Basic familiarity with how research requests reach your team"],"aiLearningOutcomes":["Calculate research lead time from work-in-progress and throughput","Distinguish touch time from lead time and compute flow efficiency","Explain why prioritising a backlog cannot shorten average wait","Set and hold a work-in-progress limit"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}