{"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-09-21T12:34:37.946Z"},"content":[{"type":"documentation","id":"b991ab47-974d-496c-8e04-c7a1d02a59a8","slug":"research-refresh-cadence","title":"How Long Is User Research Valid? Insight Decay and When to Re-Run a Study","url":"https://www.koji.so/docs/research-refresh-cadence","summary":"Research validity depends on what the finding measures, not on a uniform expiry date. Core jobs to be done hold for 5-10 years; mental models 3-5 years; segment structure 2-3 years; category attitudes 12-18 months; competitive expectations and willingness to pay 6-12 months; usability findings only until the interface changes; behavioral signals decay in weeks. Five triggers should force re-validation: product change, competitive-set change, population change, regulatory or macro change, and interaction-norm change — four of which are external. The refresh protocol is to tag insights with fieldwork date, population, product state, and decay class; run quarterly staleness sweeps producing current/needs-review/superseded buckets; supersede rather than delete; and re-validate narrowly. Teams skip refresh because a re-run traditionally costs as much as the original study; reusable study briefs and identical structured question sets across waves invert that arithmetic.","content":"## How long does user research stay valid?\n\nThere is no single expiry date, and any team applying one uniformly is either throwing away good evidence or acting on dead evidence. Validity depends on **what the finding is about**. A finding about the fundamental job a customer hires your product for can stay accurate for a decade. A finding about which competitor a buyer shortlists can be wrong in six months. A usability finding about a specific screen dies the moment you ship the redesign.\n\nThe working rule: **research decays at the speed of the thing it describes.** Classify every insight by what it measures, assign it a half-life, and re-validate on event triggers rather than on the calendar.\n\n## What insight decay actually is\n\nInsight decay is the gradual divergence between what a research finding claims and what is currently true. Nothing announces it. The document does not change, the quote is still vivid, the chart still renders — and the team keeps citing it in roadmap reviews eighteen months after the population it described stopped existing.\n\nThe failure is structural rather than careless. Research repositories are built to accumulate and preserve; almost none are built to mark things stale. The result is a library where a study from last month and a study from 2023 look identical in the search results, and the one with the better title wins the argument.\n\nA useful analogy comes from the data-quality world, where decay is measured rather than assumed: B2B contact records degrade at roughly **2.1% per month, about 22.5% annually**, with some vendor analyses putting real-world decay at 30–40% per year. If the *contact details* of your research participants rot that fast, the organizational reality those participants described is not standing still either.\n\nA widely used practitioner heuristic is to check for existing research before commissioning new work, treating roughly **one year as the review point for evaluative research and about five years for generative research**. That is a reasonable default — but the classes below are far more accurate than a single number.\n\n## The half-life table: how fast each finding type decays\n\n| Finding type | Typical half-life | Why |\n| --- | --- | --- |\n| **Core jobs to be done / underlying need** | 5–10 years | The job is stable even as solutions churn — people needed to move money long before banking apps |\n| **Mental models and domain workflows** | 3–5 years | Professional practice shifts slowly; regulation and tooling move it |\n| **Segment structure** | 2–3 years | Segments drift as the product moves upmarket or a new channel changes acquisition mix |\n| **Attitudes toward the category** | 12–18 months | Sentiment moves with market narrative and press cycles |\n| **Competitive expectations / feature baselines** | 6–12 months | Faster in AI-adjacent categories, where a single major release resets what \"table stakes\" means |\n| **Willingness to pay / price sensitivity** | 6–12 months | Highly sensitive to competitor pricing moves and macroeconomic conditions |\n| **Usability findings on a specific interface** | Until the next material change to that interface | Often under 12 months; a redesign invalidates them instantly |\n| **Behavioral and intent signals** | Weeks | The fastest-decaying class; treat as perishable operational data, not research |\n\nThe most common repository error is filing everything at the speed of the slowest class. The second most common is the reverse: discarding durable generative findings because they are \"old\", then paying to rediscover the same job to be done.\n\n## The five decay triggers\n\nCalendar-based review catches decay late. Event-based review catches it when it happens. Re-validate a finding when any of these fire:\n\n1. **Your product changed materially.** Any change to the flow the research described. This invalidates evaluative findings immediately and completely.\n2. **The competitive set changed.** A new entrant, a major competitor release, or a category-defining feature shipping elsewhere. Buyer expectations reset against the new best available option, not against your last study.\n3. **Your user population changed.** Moving upmarket, opening a geography, or a growth channel that shifts who signs up. The finding may still be true — about a population you no longer primarily serve.\n4. **The regulatory or macro context changed.** New compliance obligations, budget contraction, or procurement policy shifts alter both behavior and stated priorities.\n5. **An interaction norm changed.** When a dominant platform popularizes a new pattern, expectations about what is \"obvious\" can shift within a year or two.\n\nNotice that four of the five are external. Teams tend to review research when *they* ship something and forget that most decay is caused by things happening outside the product.\n\n## The refresh protocol\n\n**1. Tag every insight with four fields at the time of publication.** Not later — later never comes.\n\n- *Collected on:* the fieldwork date, not the publication date\n- *Population:* the exact cohort, including how they were recruited\n- *Product version / state:* what the participants were actually reacting to\n- *Decay class:* from the table above\n\n**2. Run a quarterly staleness sweep.** Sort the repository by decay class and fieldwork date and produce three buckets: **current**, **needs review**, **superseded**. Insights marked critical or high severity deserve an annual review at minimum, regardless of class.\n\n**3. Never delete — supersede.** Deleting old research destroys the ability to see change over time, which is often the most valuable thing a repository holds. Mark the old finding superseded, link it to the new one, and keep both. The delta between waves is itself a finding.\n\n**4. Re-validate narrowly.** Refreshing does not mean repeating the original study. It means testing the specific claims that matter now, usually a handful of questions against the current population.\n\n**5. Publish an explicit confidence label.** \"Validated Q1 2026, population: SMB admins, decay class: competitive expectations, review by Q3\" is a sentence that prevents a stakeholder from confidently citing dead evidence in a planning meeting.\n\n## Why teams do not refresh — and what changes it\n\nThe honest reason refresh cadence is rare is arithmetic. Under a traditional pipeline, re-running a study costs approximately what the original cost: rewrite the screener, re-recruit, re-schedule, re-moderate, re-transcribe, re-code. Faced with paying full price to *possibly* confirm what you already believe, teams rationally defer — and the repository quietly ages into fiction.\n\nAn AI-native platform inverts that arithmetic, which is what makes refresh cadence practical rather than aspirational:\n\n- **Re-running a study is re-launching a brief.** In Koji, the study definition — objectives, question set, AI moderator configuration — is reusable. A refresh wave is a relaunch against a fresh cohort, not a rebuild.\n- **Identical instruments across waves.** Koji's six structured question types (open_ended, scale, single_choice, multiple_choice, ranking, yes_no) hold the measurement constant between waves, so a shift in a scale distribution reflects the market rather than a reworded question. This is what makes genuine wave-over-wave comparison possible.\n- **Consistent moderation removes drift.** A human moderator asks the question slightly differently a year later; an AI moderator does not. Between-wave differences are more likely to be signal.\n- **Cost per wave collapses.** When a refresh wave costs a small fraction of the original, quarterly re-validation of your fastest-decaying classes becomes a routine line item instead of a business case.\n- **Always-on studies replace point-in-time snapshots.** Leaving a study running continuously turns the refresh question into a non-question: the finding is never more than a few weeks old.\n\nThat last point is where the practice is heading. Teresa Torres defines continuous discovery as, at minimum, weekly touchpoints with customers by the team building the product, conducting small research activities in pursuit of a desired outcome. A team with a genuinely weekly cadence does not need a decay policy for its fastest-moving classes, because nothing in that bucket ever gets old enough to mislead. Legacy tooling makes weekly contact implausible; asynchronous AI moderation makes it a default.\n\n## Anti-patterns\n\n- **Uniform calendar expiry.** Marking everything stale after twelve months discards durable generative insight and creates busywork.\n- **Refresh theatre.** Re-running a study without a hypothesis about what may have changed. If nothing on the trigger list fired, spend the cycle elsewhere.\n- **Silent citation of undated findings.** The most damaging pattern: a slide with a compelling quote and no fieldwork date. Require dates on every cited insight.\n- **Treating the repository as an archive rather than a live asset.** An insight nobody has re-validated in three years is a hypothesis, and should be labelled as one.\n\n## Related Resources\n\n- [Structured Questions in AI Interviews](/docs/structured-questions-guide) — holding measurement constant across refresh waves\n- [How to Build a UX Research Repository](/docs/research-repository-guide) — the storage layer that decay metadata plugs into\n- [Insight Repository Methodology](/docs/insight-repository-methodology) — tagging and activating a research library\n- [Continuous Discovery Tools 2026](/docs/continuous-discovery-tools-2026) — the stack behind weekly customer touchpoints\n- [Time to Insight](/docs/time-to-insight) — why cycle time determines refresh feasibility\n- [Customer Signals](/docs/customer-signals) — building an always-on insight layer\n- [Activating Research Insights](/docs/activating-research-insights) — turning current findings into decisions\n\n## Frequently asked questions\n\n**Is there a standard expiry date for user research?**\nNo. A common default is reviewing evaluative research at one year and generative research at around five, but decay class is far more accurate than a blanket rule. Usability findings about a screen die when the screen changes; core jobs to be done can hold for a decade.\n\n**Should we delete outdated research?**\nNo. Mark it superseded and link it to the finding that replaced it. The comparison between an old wave and a new one is frequently more valuable than either wave alone, and deletion makes trend analysis impossible.\n\n**How do we know a finding has decayed without re-running the study?**\nYou usually cannot, which is why trigger-based review matters. If any of the five triggers fired — product change, competitive change, population change, regulatory change, interaction-norm change — treat the finding as unverified until a narrow re-validation says otherwise.","category":"Research Operations","lastModified":"2026-08-18T03:28:42.8096+00:00","metaTitle":"How Long Is User Research Valid? Insight Decay & Refresh Cadence | Koji","metaDescription":"User research does not expire on a fixed schedule. Get the half-life table by finding type, the five decay triggers that invalidate insights, and a refresh protocol that keeps your repository honest instead of fictional.","keywords":["how long is user research valid","insight decay","research refresh cadence","when to re-run a study","outdated user research","shelf life of research","research repository maintenance","stale insights","tracking study waves","Koji"],"aiSummary":"Research validity depends on what the finding measures, not on a uniform expiry date. Core jobs to be done hold for 5-10 years; mental models 3-5 years; segment structure 2-3 years; category attitudes 12-18 months; competitive expectations and willingness to pay 6-12 months; usability findings only until the interface changes; behavioral signals decay in weeks. Five triggers should force re-validation: product change, competitive-set change, population change, regulatory or macro change, and interaction-norm change — four of which are external. The refresh protocol is to tag insights with fieldwork date, population, product state, and decay class; run quarterly staleness sweeps producing current/needs-review/superseded buckets; supersede rather than delete; and re-validate narrowly. Teams skip refresh because a re-run traditionally costs as much as the original study; reusable study briefs and identical structured question sets across waves invert that arithmetic.","aiPrerequisites":["research-repository-guide","activating-research-insights"],"aiLearningOutcomes":["Classify findings by decay class and assign realistic half-lives","Recognize the five triggers that invalidate existing research","Tag insights with the metadata required for staleness review","Run a quarterly staleness sweep across a research repository","Re-validate findings narrowly instead of repeating whole studies","Design refresh waves that stay comparable to the original study"],"aiDifficulty":"intermediate","aiEstimatedTime":"13 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}