Suppose a user asks for an export button. The product team schedules it immediately without asking why. After launch it sees little use. Only later does the team learn that the user needs to explain weekly changes to a manager, while the exported raw table still takes two hours to organize manually.
Feature requests are clues, not complete requirements. The key is to identify the user’s goals, current path, challenges, and constraints, and then choose the appropriate solution. This discussion focuses on reducing decision uncertainty, rather than extending the research process to keep all features in a perpetual state of discussion.
The interview focuses on the most recent instance of behavior.
Instead of asking “Will you use automated reporting?”, it’s better to ask “When was the last time you reported to your manager? Where did you get the data from? And what did you finally submit?” This approach makes it easier to verify recent events and reveal the actual steps taken.
Ask users to show work artifacts they are authorized to share, and record timing, participants, and failure points. Do not assume that you have permission to inspect private material, or require disclosure of sensitive company data. Blank examples and redacted screenshots can also reveal the workflow.
The interviewer avoids introducing the proposed solution upfront, as this might lead the user to answer in a way that aligns with your assumptions. Instead, focus on understanding the user’s goals first, then inquire about alternative approaches and their associated costs. Agreement on a concept does not necessarily mean a willingness to change their existing work practices.
Keep Explanations and Evidence Separate
You can replay the process step-by-step, following the timeline of the report: What triggered the process, which system was opened first, how to determine if the data is complete, and who confirms the results. A user might say, “Usually, it’s just a copy,” and then be asked about the most recent exception. Failures, delays, and rework often hide in the steps that experienced users omit. The task map needs to record these, not just the successful main path.
Avoid questions that contain their own answer. “Wouldn’t automated reporting be convenient?” invites agreement. “Why did you choose these three columns last time?” helps explain the user’s decision. Mark uncertain recollections as pending verification rather than demanding a precise time estimate. The hypothetical two-hour cost above illustrates a possibility; an actual decision needs work records or an estimate whose basis can be explained.
At the end, restate your understanding: the user needs to explain changes to a manager; export is one way to obtain the supporting material; accuracy matters more than attractive formatting. Invite corrections. This is not a request to commit to buying a solution, but a check that the team has understood the task. Preserve the conditions the user adds or corrects in the research conclusion.
“User needs to export” is an explanation, while “users copy three tables into a slide weekly” is an observation. Separating these two allows the team to discuss options like automated summarization, shared views, or scheduled emails, without being constrained by the initial plan.
The sample size and distribution need to be specified. The fact that three active users expressed the same problem does not mean that all users need it; the fact that no one mentioned it does not mean that the problem does not exist. The research is used to form hypotheses, and further validation requires behavioral data or experimental results to determine the scale.
Counterexamples are equally important. Some users do not need to report, while others can only export local files due to compliance requirements. Document these differences as grouping criteria to avoid creating a single solution that satisfies no one.
Don’t Hide the Solution in the Opportunity Description
Observation notes can record their source and evidence status. A worksheet shown by a user is an inspectable artifact; a frequency described by the user is self-reported; an efficiency loss inferred by a researcher is a hypothesis. Put these in separate columns so a later team does not quote an inference as the user’s own words. Redacted excerpts must retain their meaning, including inconvenient conditions that weaken a proposal.
Recruitment also influences the conclusions. Users who frequently respond to product emails may be more engaged than inactive users, while corporate buyers may not perform routine tasks, and churned users may face different constraints. First, identify the key groups to understand, and then explain which groups are not yet covered. The goal is not to require all research to achieve statistical representativeness, but rather to ensure that the conclusions are within the scope of the evidence.
Counterexamples can help narrow down the options. If some users must submit files in a fixed format, automated summarization cannot fully replace exporting; if other users only need to see the changes, sharing a link might be better. These two needs do not necessarily need to be forced into a single “smart export platform.” Instead, it’s possible to identify the primary user group and clearly state the conditions that are currently not supported.
Describe the opportunity as “reduce time spent compiling weekly changes,” not “add automated export.” The former permits comparing several solutions and defining success criteria. State who the user is, the situation in which the task occurs, and the constraints they face.
For example, a team administrator may need to explain project progress each week while gathering data across several pages. The opportunity might be cheaper data collection or better explanation of exceptions. If you do not know which matters more, investigate before building a large reporting system that tries to do both.
There may be dependencies between opportunities. Users need to first trust the accuracy of the data before using automated summarization. Product discovery should focus on the entire process, not just looking for improvements in the final output interface.
Experiment Focused on Maximum Uncertainty
The opportunity description should also distinguish where the difficulty lies: lack of information, inability to trust information, difficulty in explaining information, or difficulty in communicating it to others. A single button can only reduce the initial friction, but cannot fix inaccurate data. By identifying the biggest obstacle along the current path, and then comparing how each solution addresses it, we can avoid investing the most resources in the easiest-to-implement interface.
Suppose administrators must explain delays each week, but the existing data stores only statuses, not reasons. An automatic summary cannot recover reasons that were never recorded; the product may first need a better update process. Technical feasibility and user value interact here. Invite engineering to examine data availability, but do not let ease of implementation substitute for a judgment about user needs.
If there is uncertainty about whether users are willing to use summaries, create a sample manually and invite users to try it during real reporting. If there is uncertainty about whether the system can accurately extract changes, create a technical prototype. The two experiments address different questions.
Concept tests can reveal comprehension and appeal, not long-term use. Click tests can reveal interest, not whether the result has value. Before an experiment, state what you want to learn, what observations would support continuing, and what would make the team stop.
Avoid “fake door” effects that erode trust. Any incomplete functionality should clearly explain the status after the user interacts with it, without collecting sensitive data or giving the impression that the task has been completed. Even low-cost experiments should have ethical boundaries.
Combining Value and Constraints in Decision-Making
Manual example testing can provide users with two different outputs: the original data table and a summary with explanations of the changes. The user should then select and explain the modifications in their next real task. The focus should be on identifying which content was retained, deleted, or rewritten, rather than simply choosing a preferred output. If users still require significant additional context, the experiment reveals information gaps that cannot be resolved simply by changing the color scheme to improve feedback.
For a technical prototype, you can focus solely on verifying the extraction of changes. Using pre-approved, fixed data, you can compare whether the summary accurately distinguishes between new additions, deletions, and status changes, without needing to simultaneously send emails and update the account system. Each experiment should retain the input, decision, and failure conditions, allowing for subsequent decisions to be based on specific learning outcomes rather than a simple “prototype validation” statement.
Stopping criteria must matter. If target users repeatedly do not use the manually prepared examples, investigate whether the trial misses the task’s timing, the output is untrustworthy, or the problem has little value. Do not keep changing the explanation until someone agrees. A failed experiment can narrow the opportunity or justify pausing investment in favor of a clearer difficulty.
User demand is strong, but development and maintenance costs may be high; however, if usage is low, it may be concentrated among key customers. The results of these findings should lead to a clear decision, rather than automatically deciding whether or not to proceed.
It is possible to record expected value, evidence strength, scope of application, and key risks. While weak evidence does not necessarily prohibit action, it should be addressed with reversible, small-scale solutions. Strong evidence does not mean that safety, privacy, and operational capabilities can be ignored.
The research findings highlight the need for temporal relevance. User habits and preferences from the past may become outdated due to changes in products and organizations. To determine whether a particular study or user insights remain relevant, it’s crucial to identify the specific research, the user group, and the context in which the findings were originally obtained. This information will allow for a proper assessment of their continued applicability.
Differentiating Reporting, Archiving, and Compliance Submissions Based on Deliverables
Consider three users asking for export. One wants to write changes into a weekly report; another needs a monthly snapshot for offline reference; the third must submit a fixed-format file to a regulator or client. The requested button is identical, but success differs: explanation for reporting, completeness and a stable version for archiving, format and authorization for submission. Discovery should distinguish these tasks rather than merge them merely because the same word appears repeatedly.
When interviewing about the latest task, ask who receives the final artifact, how that recipient judges it usable, and which edits cannot be skipped. A user may praise a raw table while actually removing half its fields and adding explanations for exceptions every time. Observing edits reveals the real information structure; a positive reaction does not establish task completion. Use blank templates or synthetic data when necessary instead of requesting unauthorized company material.
The output also reveals dependencies. The person reporting must first verify the accuracy of the data. Automatically generating output eliminates duplication but increases verification, which may not actually reduce the overall workload. The record includes preconditions, waiting times, and rework, which are considered when comparing solutions and evaluating data lineage and error handling. The task map is not just about showing the user’s smooth navigation through pages, but also includes when to pause to confirm with colleagues.
Maintaining a Flexible Relationship Between Opportunities and Solutions
An opportunity statement might say that administrators need to explain project changes accurately before weekly meetings and currently gather, verify, and interpret information across several pages. Export, shared filtered views, change summaries, and team templates are different solutions. For each, explain which step it reduces, which new information it requires, and which maintenance and trust costs it adds. Do not close off alternatives by putting “must automatically generate reports” into the opportunity statement.
If the main difficulty is missing reasons, an automatic summary can only repeat statuses. First improve reason capture during updates or let report authors add clearly marked explanations. Engineering can establish whether data exists and design can observe whether its expression is understandable. But no role’s preferred implementation is evidence of user value. Team consensus remains a hypothesis requiring appropriate validation.
The scope of opportunity should also include conditions that are currently unsupported. For example, the initial single-project administrator role does not support merging sensitive data across multiple clients. This allows the prototype to be reversible and verifiable, preventing a strong demand from driving the development of a universal reporting platform. A small-scale approach is not about ignoring other users; rather, it is about clearly stating that the current evidence and capabilities are insufficient to cover them.
A single experiment can only answer the most dangerous assumption at the current time.
If there’s uncertainty about the usefulness of the output, create two redacted versions manually, allowing users to choose, edit, and use them in real-world reporting. If there’s uncertainty about the accuracy of the automated extraction, compare it with fixed data for new, deleted, and status changes, without initially developing the sending process. If there’s uncertainty about whether users can find the entry point, conduct usability tests without providing any hints about the location. These three types of experiments test value, technology, and interaction separately, and cannot be declared completely feasible if only one passes.
Before testing, write down observations that would support continuing or pausing. Which content users retain, what they still rewrite manually, and whether they use it for the next task tell you more about behavior than “looks good.” Nonuse does not automatically prove lack of value: check whether the task actually occurred, whether the participants were the right users, and whether trying the sample cost too much. Keep explanations within the evidence rather than changing them repeatedly until you get agreement.
Manual services can verify tasks, but cannot prove that automation will maintain accuracy. A technical prototype can demonstrate that a fixed set of inputs can be processed, but cannot prove that long-term habit changes will occur. The report breaks down the conclusions and records the unverified assumptions. The value of low-cost experiments lies in exposing uncertainty, not in providing a formal development process that cannot be refuted.
The fake door experiment must not mislead users into believing that the actual task has been completed. After clicking, clearly explain the functionality status and the next steps, to avoid collecting sensitive documents or triggering contractual obligations. Tests involving concepts such as payment, personal information, or important rights require more careful design. The convenience provided should not expand the scope of user authorization.
Sample Bias Revealed Through Recruitment and Counter-Examples
Active users are familiar with the existing system, while inactive or lost users may have left due to difficulties. Buyers focus on cost, daily executors focus on steps, and administrators focus on collaboration and permissions. First, identify the key groups to understand, then specify the actual coverage to avoid assuming that three people who are willing to respond to emails represent the entire group. Qualitative interviews do not need to pretend to be representative, but conclusions must be based on the source material.
Counterexamples are helpful in identifying boundaries. Some teams don’t require weekly reports, while others need fixed documents that cannot be shared via links. Some can only handle information within a private network. Documenting the constraints behind these differences helps determine the primary users or provide alternatives, rather than forcing all different needs to be the same. While investing in a few key users may be worthwhile, the justification should be based on business decisions, not on artificially creating a majority from a small sample.
Label research material as observation, self-report, or inference. Redacted quotations must not remove unfavorable conditions, and citations should identify context and time. Treat statements about future use as intentions and recent actual behavior as evidence of the past. Both can help, but they have different strengths. Restate the team’s understanding and invite corrections to reduce the risk of mistranslating a feature request into the wrong problem.
Verify the original tasks again after deployment.
After the new entry point launches, revisit actual tasks and compare the steps removed and added. Faster copying with longer verification can increase clicks without improving net value. More complete output that is harder to approve may move the problem into collaboration. Behavioral data shows who used the feature; task observation explains how. Preserve differences between users instead of claiming universal savings from the most enthusiastic case.
Decision-making record: Explains the chosen approach, rejected alternatives, the scope of evidence, and conditions for re-evaluation. After changes in the background, there is an opportunity to re-examine. Old research should not be treated as an eternally correct authority. The key is that there should be observable evidence and a clear understanding of what is unknown for each important decision.
Research conclusions must identify who owns follow-up verification. Check user value through task follow-ups, automatic extraction against fixed factual samples, and security through authorization and privacy-boundary tests. A solution owner can coordinate these efforts, but one passing prototype cannot replace their different evidence. Record missing conditions as pending verification rather than hiding them in a formal requirement’s default assumptions.
Further Verification Issues After Delivery
The implementation plan can also maintain explainability. Automatic summarization displays data sources and change rules, allowing users to verify; it also allows for editing but distinguishes between original facts and user explanations, preventing errors from being replicated in subsequent reports. When “lack of trust” is identified, the appropriate response is not simply to add a confident statement, but to provide verifiable evidence and correction paths. To understand how product capabilities can build user trust, we need to examine the plan comparison.
The team can invite representatives from research, engineering, and content to review a specific observation before implementation, identifying user difficulties, data constraints, and potential communication risks. This cross-functional discussion does not require repeating all interviews, but it can reveal different interpretations. Ultimately, the record should document which interpretations are supported by evidence and which remain as hypotheses, to avoid misinterpreting the meeting consensus as user facts.
For a personal website, discovery can be lightweight: retain voluntary feedback, observe your own content-maintenance tasks, and ask a few readers about specific situations in which they try to find an article. Small scale does not require copying a large research department, but it still does not justify inventing reader needs. An explicit evidence boundary and next review time are an inexpensive, reliable starting point.
Value and cost should be discussed through scenarios, rather than simply quantified. A conservative scenario involves serving only a small number of fixed reporters, a moderate scenario involves more teams using it, and an optimistic scenario involves it becoming a daily work entry point. Clearly define the evidence, operational, and maintenance capabilities required for each scenario, and then create a reversible version that supports the conservative scenario first, rather than building a complete version based on the most optimistic needs at once.
The decision record should also outline alternative options. Perhaps improving existing filtering and copying formats would be sufficient, or perhaps team templates are more reliable than automatically generated ones. Including the option of “not implementing new features” in the comparison allows us to determine whether development is the most effective intervention. Product discovery is not just about finding reasons to implement new features; it can also help reduce system complexity.
Once a summary feature launches, success is not merely clicks. Check whether users spend less time compiling information, explain changes more accurately, and continue using it. Combine small follow-up studies with behavioral metrics to establish whether the original opportunity improved.
If the adoption rate is low, and it’s difficult to identify the entry point, the output is unreliable, or the target users don’t match, or the problem itself is unimportant, simply increasing promotion efforts may only increase clicks without addressing the underlying value gap.
Iteration also needs to check for changed task context. A new reporting process, different manager requirements, or migrated data sources can invalidate the original opportunity. Keep asking about current work instead of using old research to defend every new version. Sustainable discovery depends on updating evidence, not maintaining an eternally correct initial conclusion.
The ultimate goal of documenting work should be to leave a record of the decisions made: what was observed, what assumptions were made, what was verified, and what remains unknown. This is more helpful than a well-written requirements document in helping the team make decisions in the future.