The product discovery process decision record: why the discovery model you chose determines your validated requirement confidence ceiling and your build-the-wrong-thing accumulation rate

A 27-person B2B SaaS building a project management platform for construction companies had a clear product thesis: field workers at job sites spent significant time each day filling out daily logs on paper forms, then handing them to an office coordinator at the end of the week for manual data entry into the project management system. The product team had spoken with one general contractor during a sales call who mentioned this workflow. The VP of Sales had heard similar comments from three other prospects over six months of conversations. The PM had visited one job site during a customer development trip and observed field workers with clipboards. The product team began designing a mobile-first daily log entry feature: a streamlined native-feeling mobile interface for field workers to enter daily progress, crew counts, equipment usage, and weather conditions directly from the job site, eliminating the paper form and the weekend data entry batch.

Three sprints in, with the mobile UI substantially built, the PM scheduled a usability study with five existing customers. She recruited the contacts who had originally spoken to the VP of Sales — the general contractors and project managers who were the primary account owners. None of them were the people who would actually use the daily log entry feature. The PM recognized this during the first session when the general contractor being interviewed said, "Oh, Maria does all of that." Maria was the office coordinator. The PM asked whether it would be possible to include Maria in the next session. It was. Maria's session produced a finding that the three-sprint mobile-first implementation was architecturally misaligned with. Maria entered daily logs for between 8 and 14 active job sites every Monday morning, compiling data from the paper forms that field foremen had left in a folder on her desk over the week. She entered them on a desktop, in batches, copying from the paper forms. She had 4 to 6 hours of Monday morning reserved for data entry. The mobile interface — which opened one daily log at a time, for the date of entry, oriented around a single job site's crew list — was designed for a field worker entering their own crew's data in real time. For Maria's batch weekly workflow, it was unusable. She would have needed to open 47 individual log sessions across 14 job sites to enter one week's worth of data, with no way to copy repeating fields across similar log entries or see multiple logs side by side during entry.

The PM had discovered the actual user in session 4 of a 5-session usability study, three sprints after the discovery that should have preceded the sprint. The general contractor stakeholder — the economic buyer, the contract signer — was not the daily log user. The field foreman — the person the PM had observed on the job site with a clipboard — was not the daily log entry user either; foremen filled out the paper form, but they did not enter data into the project management system. The office coordinator was the daily log entry user for most of the customers who were likely to purchase, and the office coordinator had been entirely absent from the product team's discovery process because the discovery had been conducted with account-owner and economic-buyer stakeholders, not with the operational user who performed the actual job. The three sprints of mobile-first development were not wasted — the interface worked correctly for field workers in smaller operations where the field worker also performed their own data entry — but the ICP for data entry at the company's largest accounts was not a field worker entering data for one site on the day it occurred; it was an office coordinator entering data for a dozen sites once a week on a desktop. The discovery model had produced high confidence in the wrong population's requirements.

The mobile-first interface was not abandoned. It was repositioned as the field worker tier — individual contributors at smaller job sites — while the PM began a new discovery cycle with office coordinators at mid-size and enterprise construction companies to understand the batch desktop entry workflow that represented the majority of data entry volume at the company's highest-revenue accounts. The three-sprint rework cost to add a desktop batch-import interface was three sprints. The PM's original discovery process — one sales call, three sales-team anecdotes, one job site observation — had produced a clear requirement with high felt confidence and a wrong ICP classification. The requirement was wrong not because the PM had done poor research but because the discovery had been conducted with the stakeholders who were easiest to reach rather than the stakeholders who performed the actual job.

A 41-person SaaS building an HR compliance platform for small and mid-market healthcare organizations had a well-established discovery process: before any major feature sprint, the PM ran a survey to the existing customer base. The surveys were professional, thoughtfully constructed, and produced high response rates — typically 15 to 25 percent, well above industry benchmarks. When the product team decided to invest in improving the reporting capability of the platform, the PM sent a survey to 312 customers asking a battery of questions about their current reporting experience: how often they ran reports, what types of reports they ran most frequently, how satisfied they were with the current reporting interface, and — the key question — what one change would most improve reporting for them. Seventy-eight percent of respondents selected "more comprehensive, easier-to-use reporting" from a list of options. The product team interpreted this as strong validated demand for a richer, more capable reporting interface. Six months of development began.

The resulting dashboard was technically impressive. Filtering, pivoting, custom date ranges, saved report views, exportable to CSV. The PM had reviewed it in sprint reviews with the two customers who served as regular product advisors — both of whom had praised the capability and the visual design. The dashboard shipped. In the first six weeks, usage was lower than the team had projected. The PM conducted four customer interviews to understand the low adoption. The findings were consistent across all four. The compliance officers who were the primary users of reporting at the healthcare organizations described their reporting workflow: they ran a single standard report every Monday morning — staff certification expiration statuses, grouped by department, covering the next 90 days — and sent it as a PDF to their department heads and HR director. They had done this workflow every Monday for years. The compliance officer at one of the interviewed accounts said, "I just need it to show up in my inbox on Monday morning as a PDF. I don't have time to go log in and run it myself." The PM had built an interactive dashboard for a user whose reporting job was a scheduled weekly export delivered by email. The dashboard required the user to log in, navigate to reporting, configure filters, and export each time they needed the report. The compliance officer's actual job was: set it up once, have it arrive in my inbox. The survey had asked "what one change would most improve reporting?" and the compliance officer had selected "more comprehensive, easier-to-use reporting" — which was accurate and genuinely what she wanted. She had not selected "email me a scheduled PDF export" because that option was not on the list, and the survey format — multiple choice with predefined options — had no mechanism to surface a behavioral pattern the PM had not anticipated when writing the survey.

The structural failure was not the survey instrument; it was the method selection. The survey was a measurement tool — it measured distribution of stated preferences across a defined option set. It was not a discovery tool. It could not surface a behavioral job the PM had not already understood well enough to include as an option. The PM had used a measurement tool to answer a discovery question — "what is the reporting job our customers are trying to accomplish?" — and had received a confident answer to a different question: "of the reporting improvements we considered, which do customers prefer?" The 78% selection was real; the inference from "more comprehensive reporting" to "interactive dashboard" was the PM's interpretation, and that interpretation was not surfaced as an assumption to be tested because the survey data had the quantitative feel of validated demand. Connect this to the technical roadmap prioritization decision record: the survey result had entered the prioritization process as a high-confidence signal, allocated six months of the team's capacity to an implementation, and produced a feature that solved a problem the PM had inferred rather than a problem the discovery had found. The scheduled PDF export — the actual job — was a four-week feature, not a six-month one. The miscategorization of the discovery method's confidence ceiling had a direct cost in the capacity allocation model: six months of development on a wrong solution, where four weeks of interviews before the sprint would have redirected the investment.

A 63-person enterprise SaaS building a workforce management platform for healthcare systems had invested meaningfully in product discovery. The PM team ran structured Jobs-to-be-Done interviews before each major feature cycle, produced detailed problem statements from interview synthesis, and maintained a discovery repository in Notion that documented interview findings by theme, participant role, and organizational type. The process was good. The handoff was not.

The discovery team was organizationally separate from the engineering team in a structure that the company called a "product trio" but that in practice had the PM performing discovery and writing requirements and the engineering lead receiving them as Jira tickets at sprint planning. The discovery findings — the interview quotes, the constraint reasoning, the specific behavioral contexts that had reshaped the requirements during synthesis — lived in the Notion discovery repository. The sprint tickets contained the stated requirements: "Users need to view schedule conflicts for a department across a 28-day rolling window" or "Shift swap requests must support a two-step approval with configurable approver roles." The tickets were clear and technically precise. They were also stripped of the reasoning that had produced them.

The workforce management platform was building a shift swap feature — a mechanism for nurses and other hourly workers to trade scheduled shifts with colleagues, subject to manager approval. During discovery, the PM team had conducted eight interviews with charge nurses, floor managers, and HR compliance officers at three healthcare systems. One finding from those interviews had reshaped the entire feature design: healthcare compliance requirements at two of the three systems required that any shift swap be evaluated against the replacing worker's certification profile before approval — a nurse with a standard RN certification could not cover a shift in an ICU that required ACLS certification, regardless of whether their manager approved the swap. The compliance constraint was not a feature request; it was a regulatory requirement that determined whether the built shift swap mechanism was legally usable by the product's target customers. The PM had incorporated this constraint into the requirement: the ticket read "Shift swap approval must check replacing worker's certifications against the shift's required certifications before surfacing the swap for manager approval."

Three sprints into the implementation, the engineering lead ran into a tradeoff: the certification check could be implemented as a hard block (swap requests are not visible to managers if the replacing worker lacks the required certifications) or as a soft warning (swap requests are visible with a certification-gap flag). The hard block was simpler to implement and safer from a compliance perspective. The soft warning gave managers more visibility and flexibility but created a workflow path in which a manager could approve a certification-gap swap. The engineering lead chose the soft warning — it gave managers more control and seemed like the more flexible and user-friendly option. He was reasoning against the stated requirement ("must check certifications"), which did not specify block versus warn, and his default preference was to give users more flexibility rather than less. The ticket had not included the constraint reasoning from the discovery interviews: that the certification gap was a regulatory compliance issue, not a scheduling preference issue, and that the purpose of the check was not to inform the manager but to prevent a non-compliant assignment from reaching the approval stage. Two of the three healthcare systems that the PM had interviewed had told her explicitly that any mechanism that allowed a manager to approve a certification-gap swap would be unusable in their compliance environment — their compliance team would not allow the feature to be deployed because the existence of a manager-override path for a certification gap violated their interpretation of Joint Commission staffing standards.

The soft-warning implementation was technically complete when the PM discovered the compliance issue during a demo with one of the interviewed healthcare systems. The system's compliance officer identified the problem immediately: "If a manager can approve a certification gap, we can't use this." The rework from soft-warning to hard-block was estimated at two sprints, not because the implementation change was complex but because the soft-warning path had been built into the notification model, the approval workflow, and the audit log schema in ways that a decision to remove the approval path rather than flag it required unwinding across multiple components. Connect this to the product sprint review decision record: the requirement divergence between what the discovery had found and what the engineering team had implemented did not surface until a demo with a customer who held the compliance requirement — which was three sprints later than it would have surfaced if the sprint review had included a compliance officer from one of the healthcare systems the PM had interviewed during discovery. The root cause was not the sprint review attendee model; it was the handoff fidelity between the discovery interview and the sprint ticket. The constraint reasoning that would have made the hard-block decision obvious to any engineer reading the ticket had been left in the Notion discovery repository, which the engineering lead had not opened during implementation because the ticket appeared complete.

Structural properties set by the product discovery decision

Two structural properties are determined by the founding decisions about how discovery is conducted, who participates, how findings travel into sprint requirements, and how frequently discovery runs relative to the delivery cadence. Neither property is visible when discovery is running smoothly — they become visible only when a feature ships and fails to solve the problem, and the team attempts to reconstruct whether the problem was correctly understood and finds either that the discovery method could not have surfaced the actual behavior, or that the actual behavior was found and lost in the handoff.

Property 1: Validated requirement confidence ceiling. The validated requirement confidence ceiling is the maximum confidence achievable that a requirement correctly captures actual customer behavior rather than stated preference, organizational assumption, or a single participant's view. The ceiling is not set by the quantity of discovery conducted but by the method selected and the participant qualification model. A method that asks customers what they want has a ceiling determined by customers' ability to accurately predict and describe their own behavior — which behavioral economics research consistently shows is low for novel solutions and moderately reliable for incremental improvements to familiar workflows. A method that observes or interviews customers about what they actually do has a ceiling determined by participant qualification: if the participants are the actual ICP performing the actual job in their actual context, the finding has a high confidence ceiling; if the participants are adjacent users who share demographics with the ICP but not the specific job or constraint, the finding has a low confidence ceiling regardless of interview quality. The 27-person construction SaaS's discovery had a low confidence ceiling not because the sales call and the site visit were poorly conducted but because the method — observing economic buyers and field workers — could not surface the office coordinator's batch desktop workflow, which was not a workflow those participants performed. The ceiling of any discovery method is the ceiling of what the method can access. A survey can access stated preferences at scale; it cannot access a behavioral job the researcher did not anticipate. An interview can surface unanticipated behavioral constraints; it can only surface the constraints that the ICP participant actually holds, not the constraints held by a participant who looks similar but performs a different job. Connect this to the scope creep decision record: a discovery process with a low confidence ceiling produces requirements that feel clear and are implemented as though they were validated, but have the same structural risk as an informally added requirement — both accumulate implementation that is potentially wrong for the actual customer need, and both produce a rework cost that scales with how much implementation has been built on the wrong foundation before the misalignment is discovered.

Property 2: Build-the-wrong-thing accumulation rate. The build-the-wrong-thing accumulation rate is the rate at which unvalidated or incorrectly validated requirements become implemented features that fail to solve the actual customer problem. The rate is driven by three factors. The first is the gap between discovery cadence and sprint delivery rate: a team that runs discovery quarterly and ships fortnightly accumulates six sprints of potentially misaligned implementation before the next discovery cycle creates an opportunity to catch the misalignment — if the discovery had an incorrect assumption, twelve weeks of implementation built on that assumption is the exposure. The second is handoff fidelity: requirements that arrive at engineering as stated specifications without the constraint reasoning from the discovery interviews produce engineers who resolve implementation tradeoffs against the stated requirement rather than the underlying need. The engineering lead in the workforce management platform was not making a bad decision when he chose the soft-warning path; he was making a reasonable decision against an incomplete specification. The constraint reasoning that would have made the hard-block decision obvious was available in the discovery repository and absent from the ticket. The accumulation rate for handoff-fidelity failures is driven by how many implementation tradeoffs arise per sprint that the discovery had already resolved — each tradeoff resolved against the wrong information adds a unit of potentially misaligned implementation. The third factor is ICP qualification gap: discovery conducted with participants who are adjacent to the actual ICP produces high-confidence findings about the wrong population. The 41-person HR platform's survey findings were accurate for the respondents who filled out the survey — the 78% selection of "more comprehensive reporting" was genuine — but the behavioral pattern that drove the actual reporting job (weekly scheduled PDF export) was not represented in the survey response set because surveys do not surface jobs the researcher did not already anticipate and offer as options. The accumulation rate from ICP qualification gaps is difficult to detect during the sprint because the team is building confidently to a validated requirement; it surfaces at launch when the actual users encounter the feature and their actual behavioral context does not match the feature's design model. Connect this to the cross-functional team structure decision record: the accumulation rate from handoff-fidelity failures is directly shaped by the organizational distance between the PM who conducts discovery and the engineers who implement requirements; a team structure that embeds the PM in the sprint team rather than upstream of it reduces the handoff distance and creates more opportunities for the engineering team to ask the PM about the constraint reasoning behind a requirement before resolving a tradeoff in the wrong direction.

The product discovery ADR: five sections

Section 1: Discovery method selection model per requirement type. The discovery method selection model specifies which method is used for which type of requirement and what confidence threshold each method can produce. The model should distinguish four method types along two axes — whether the method captures stated preference or observed behavior, and whether the method surfaces anticipated phenomena or allows unanticipated patterns to emerge. Surveys capture stated preference from anticipated option sets; they are appropriate for quantifying distribution of a known behavioral pattern across a large population (measuring what fraction of customers perform a known workflow frequently enough to warrant feature investment) but not for discovering a behavioral pattern the team has not yet observed. User interviews surface observed behavior and allow unanticipated patterns to emerge; they are appropriate for core-path requirements where an incorrect assumption would produce months of misaligned implementation. Usability studies observe actual behavior on a specific implemented surface; they are appropriate for validating a designed solution against actual user behavior and for surfacing interaction model mismatches before they are built into the stable product. Analytics measure actual behavior in production; they are appropriate for quantifying patterns in an existing user base and for testing behavioral predictions from interviews against population-scale behavior. The 41-person HR platform used a survey for a discovery question — what is the reporting job customers are trying to accomplish? — that required a method capable of surfacing an unanticipated behavioral pattern. The method selection was wrong for the question, not for surveys as a class. The ADR should specify, for each requirement type in the current sprint cycle, which method is selected and what the method's confidence ceiling is for that requirement type, so that the team can make an explicit decision about whether the ceiling is high enough to begin the sprint or whether a higher-confidence method is needed before work begins.

Section 2: ICP qualification model for discovery participants. The ICP qualification model specifies how discovery participants are selected and what role proximity to the actual ICP is required for each requirement type. The model should distinguish between economic buyers (who make the purchase decision), operational users (who perform the actual job the feature supports), and influence stakeholders (who are affected by the feature but do not perform the core job). For features that directly support an operational workflow, the qualification model should require operational users who perform that specific workflow as the primary participant source, not economic buyers who approve the purchase and have a theory of how their teams will use the feature. The 27-person construction SaaS's qualification failure was not that it spoke to general contractors rather than office coordinators — general contractors were the economic buyers and their feedback on the feature concept was valuable. The failure was that the team had no explicit qualification model that asked: who performs the daily log data entry job? The question was not asked because the PM had a confident mental model of the user (field worker with a clipboard) that had been reinforced by the job site visit observation. The qualification model should require an explicit question about who performs the operational job for each in-flight feature before participants are recruited, and it should require that at least three of the discovery participants for a core-path feature are confirmed performers of the specific operational job, not stakeholders who have a theory about how it is performed. The qualification model should also specify how many sessions constitute sufficient ICP coverage — for core-path requirements, the threshold is typically saturation (the point at which additional sessions surface no new behavioral patterns), not a fixed number, and the PM should document when saturation was reached and what the final session count was.

Section 3: Discovery-to-backlog handoff model. The discovery-to-backlog handoff model specifies how discovery findings enter the sprint backlog with enough context for engineers to resolve implementation tradeoffs against the actual customer need rather than the stated requirement. The model should require that every sprint ticket for a discovery-validated requirement includes three elements: the stated requirement (the specification the engineer implements), the originating constraint (the specific finding from discovery that produced this requirement — a quote, an observed behavior, or a documented constraint from an interview or usability study), and the decision-resolving note (an explicit statement about which implementation tradeoffs are pre-resolved by the discovery finding and how). The workforce management platform's sprint ticket stated "Shift swap approval must check replacing worker's certifications against the shift's required certifications before surfacing the swap for manager approval." The ticket should also have stated: "Discovery constraint: two of three interviewed healthcare systems have compliance environments that require this check to be a hard block — a swap request with a certification gap must not reach manager approval, because a manager-override path for a certification gap violates Joint Commission staffing standards in those systems. The tradeoff between hard block and soft warning has been pre-resolved by discovery: implement as hard block. Any workflow path that allows a manager to approve a certification-gap swap is a compliance disqualifier for this ICP segment." That addition would have closed the tradeoff before the engineering lead encountered it. The handoff model should specify a template for the constraint-reasoning attachment and require that every discovery-sourced ticket includes at minimum the originating constraint and the pre-resolved tradeoffs — not as a documentation exercise but as an operational mechanism that reduces the engineering tradeoff surface to the set of decisions the discovery has not yet resolved, rather than reopening decisions the discovery had already resolved.

Section 4: Discovery cadence model relative to sprint delivery rate. The discovery cadence model specifies how frequently discovery runs relative to the sprint delivery rate and what fraction of in-flight requirements have been validated at what confidence threshold before sprint work begins. The model should address two cadence risks. The first is the ahead-of-delivery gap: discovery runs ahead of delivery at a rate that ensures the next sprint's core-path requirements have been validated before the sprint begins; the gap between discovery and delivery should be at most one sprint for core-path requirements, meaning the discovery for sprint N+1 should be substantially complete before sprint N ends. A discovery process that runs quarterly against a fortnightly sprint cadence produces a one-in-six chance that any given sprint's core-path requirements have been validated recently; the other five sprints build to requirements that were discovered months ago in a customer context that may have evolved. The second risk is the behind-of-launch gap: features that shipped based on discovery conducted before the team had real users lack post-launch discovery to validate that the initial assumptions were correct at production scale. The cadence model should specify a post-launch discovery cadence — interviews with users who have encountered the feature in production — that runs within four to six weeks of launch for each major feature, with the explicit goal of comparing the discovery assumptions to actual usage patterns and surfacing requirement adjustments for the next sprint cycle. The 41-person HR platform's post-launch discovery — the four interviews the PM conducted after the dashboard shipped to low adoption — was the right method at the wrong time. Conducted before the sprint, those four interviews would have redirected six months of development. Conducted six months after the sprint started, they confirmed a mismatch the team was already experiencing in usage metrics. The cadence model should identify the point at which pre-launch discovery produces its highest return — before core-path implementation begins — and make that the mandatory checkpoint rather than treating discovery as a resource to deploy only when the team is uncertain.

Section 5: Discovery artifact model and requirement confidence scoring. The discovery artifact model specifies what the discovery process produces, how requirements are documented with their originating evidence and confidence level, and how the artifact is maintained as the team's understanding of the customer evolves. The model should produce four artifact types: interview summaries with verbatim quotes and the PM's interpretation of behavioral constraints surfaced in each session; a synthesis document that groups interview findings by theme and identifies the behavioral patterns that were consistent across multiple participants versus the patterns that were surfaced by a single participant; a requirement set with confidence scores — core-path requirements validated by three or more qualified ICP participants at interview-method confidence receive a high score; requirements inferred from survey data or from a single participant receive a lower score with an explicit note about the inference — and a sprint readiness checklist that requires any low-confidence core-path requirement to have a named validation plan before the sprint begins, not a vague intention to validate at the next opportunity. The confidence scoring is not a bureaucratic exercise; it is the mechanism that makes the difference between "we think we understand this requirement" and "we know we understand this requirement, based on these specific interview sessions with these specifically qualified participants." Connect this to the scope creep decision record: a requirement confidence score below the sprint-readiness threshold is structurally equivalent to an informal scope addition — it represents unvalidated work that enters the sprint backlog and accumulates implementation under a level of uncertainty the team has not acknowledged. The discovery artifact model closes the loop between the discovery process and the backlog state: every sprint begins with an explicit record of what has been discovered, at what confidence, for which requirements — and the PM can report to the sprint planning session not "I think we understand what customers need" but "we have high-confidence discovery on these requirements, medium-confidence on these, and we have a validation plan for these before sprint N+2 begins."

FAQ

Further reading

• Technical roadmap prioritization decision record — discovery findings are the primary input to the roadmap's value estimation model: a discovery process that produces problem statements with confidence scores enables the prioritization model to weight requirements by how certain the team is that the requirement reflects actual customer behavior, rather than treating all requirements as equally validated; a discovery finding that a high-priority roadmap item is based on survey-level confidence rather than interview-level confidence is a direct input to the prioritization calculation — not a reason to deprioritize the item, but a reason to invest in higher-confidence discovery before allocating significant sprint capacity to its implementation.
• Scope creep decision record — incorrectly validated requirements are structurally identical to informal scope additions: both enter the sprint backlog as work the team is confident in, both accumulate implementation that may be wrong for the actual customer need, and both produce a rework cost that scales with how much has been built before the misalignment is discovered; the discovery confidence score is the upstream mechanism that prevents a requirement from entering the sprint backlog at a confidence level below what the team should require for the scope it represents, in the same way that the scope boundary holder is the upstream mechanism that prevents an informal addition from entering the sprint board without an explicit cost evaluation.
• Product sprint review decision record — the sprint review is the downstream correction mechanism for discovery failures: a discovery process that produced a requirement with an incorrect assumption creates a requirement divergence that the sprint review, with the right stakeholders attending, can surface before the implementation has accumulated too far in the wrong direction; the relationship between discovery and sprint review is a feedback loop — discovery sets the initial requirement confidence level, and sprint review with qualified stakeholders produces the ongoing updates to that confidence level as implementation progresses; a team whose discovery confidence is high and whose sprint review stakeholder model is correct has two independent mechanisms catching requirement misalignments; a team with low discovery confidence and poor sprint review stakeholder coverage has neither.
• Cross-functional team structure decision record — the build-the-wrong-thing accumulation rate from handoff-fidelity failures is directly shaped by the organizational distance between the PM who conducts discovery and the engineers who implement requirements; a team structure that embeds the PM in the sprint team rather than upstream of it shortens the distance between discovery findings and implementation decisions, creating informal opportunities for engineers to ask "why are we doing it this way?" before resolving a tradeoff in the wrong direction; a team structure that separates discovery from delivery as distinct organizational phases creates a dependency on artifact quality to carry the discovery's constraint reasoning across the handoff, and artifact quality is a harder problem to solve than co-location.
• Open-source extractor — the founding decisions about product discovery method, ICP qualification, and discovery cadence are among the decisions most commonly worked through in AI chat sessions: PMs use ChatGPT or Claude to reason through which research method to use for a given requirement type, how to construct an ICP qualification screener, how to write a ticket that preserves the constraint reasoning from a discovery interview, and how to structure a discovery synthesis document; those sessions contain the PM's reasoning about what the team does and does not know about the customer, what discovery methods were available and why certain ones were deprioritized, and what the specific constraint was from a given interview that changed the requirement — running those sessions through the extractor before a discovery retrospective recovers the decision log that the Notion repository stores as findings and the sprint board stores as requirements, but that neither stores as the chain of reasoning that connected a customer's behavioral constraint to the feature the team built.