Market research tied to a decision
Scout is the market intelligence assistant project for founders, product leaders, and commercial teams. It brings competitor changes, customer signals, and research into evidence-backed opportunity briefs. The team defines the market questions and chooses which opportunities deserve further investigation. Scout's role is to make the evidence behind those choices easier to examine.
An announcement, an objection in a sales conversation, and a request from an existing customer answer different questions. An announcement describes what a competitor says it offers. An objection explains why a particular buyer hesitated. A customer request reveals friction in an existing relationship. Treating all three as interchangeable signs of demand can lead a team to build for a problem it has not understood.
A common manual counterpart is a collection of saved links, notes, and competitor comparisons assembled whenever a strategic question arises. Someone must reconstruct why a link was saved, check whether it remains current, and determine whether several notes came from the same original event.
The working model begins with a bounded decision. The team names the customer segment, the job under investigation, the relevant competitors, and the sources it permits Scout to use. Research can then distinguish information that changes the decision from interesting material outside its scope. A broad market feed has no natural stopping point; a question about whether to test a specific use has one.
The useful output is a brief a decision maker can challenge. It connects observations with possible explanations, identifies what remains unknown, and proposes a test whose result would affect the next commitment. A decision to stop investigating belongs in that output when the evidence points away from the opportunity.
One illustrative question: could the product serve small agencies?
Consider an illustrative request to evaluate whether an existing product could serve small agencies and propose three experiments before substantial building. To make the question concrete, suppose the team is considering agencies that prepare recurring client reports.
The first choice would be which agencies to include. An agency preparing recurring reports for retained clients may face different work from one delivering a single creative project. Combining both groups could produce an average description that fits neither. The founder would need to confirm which group represents the possible expansion and which existing product capabilities Scout should compare with its work.
Scout would turn that choice into a question about behavior: could these agencies use the existing product to prepare a report that their client can review? That question would expose several uncertainties. The agency might already collect the necessary information but struggle to assemble it. Alternatively, collecting it might be the difficult part. Those explanations imply different product requirements even when both are described as a need for better reporting.
The initial research brief would state what the team already knows about its own product. A documented ability to organize information would not establish that the product can retrieve every agency data source or provide a client review process. Comparing an imagined future product with current market needs would make expansion look easier than comparing the capabilities available now.
The team would also define what research is meant to unlock. Permission to run a small discovery exercise is a different decision from allocating engineering capacity. The brief could recommend the former while leaving the latter unresolved. This keeps the first investigation proportional to the evidence it can reasonably produce.
Build a dated record of competitor changes
Scout's detailed research model compares approved public pages and product announcements over time. A useful change record says what changed, where the claim appeared, and when it was observed. Publication dates and observation dates answer different questions: an older announcement found today does not establish that the underlying change happened today.
For the agency example, Scout would look for evidence relevant to preparing and reviewing recurring reports. A competitor page mentioning a client portal could justify further inspection, but the phrase alone would not establish what clients can do there. Documentation might explain whether clients merely view a report, comment on it, or approve it. Each capability would affect a different part of the proposed agency workflow.
The comparison would separate available functions from promises. A release note describing a launched feature carries a different implication from a page inviting people to join a waitlist. The team might still care about the promised feature as a possible future competitive change, but it should not appear as an available alternative in a present-day comparison.
Scout would also trace repeated coverage back to the underlying event. A product announcement, an article quoting it, and a newsletter linking to that article may all describe one change. Keeping the references is useful for checking the claim; counting them as three independent confirmations of demand would distort the opportunity assessment.
Missing information would remain a research gap. If a public page does not describe report approval, the brief could say that approval was not established by the inspected material. It could then identify the next source needed to resolve the question. A missing feature description cannot support a sales claim that the competitor lacks the feature.
The resulting competitor change log would contain concise implications tied to the agency question. For example, a newly documented review function could weaken an assumption that agencies lack an existing option. That would give the team a reason to revisit its proposed offer, without pretending that a competitor announcement reveals how many agencies actually use or value the function.
Read customer signals without manufacturing a pattern
Selected internal customer feedback adds evidence about experienced work. In the proposed workflow, Scout would group it by the job people are trying to complete, the friction they describe, and the outcome they want. This preserves the meaning of a request before translating it into a feature idea.
For the reporting-agency example, a request for a dashboard could conceal several needs. One person might want to stop copying figures between documents. Another might need clients to find the latest version. Scout would keep those explanations separate until the evidence supported combining them. Building a dashboard would not automatically resolve either underlying problem.
The evidence table would retain the connection to the original conversation or approved note. If a call recording, its summary, and a salesperson's follow-up all describe the same complaint, they would remain one customer signal. If the same account repeats the complaint over time, that repetition could indicate persistence for that account without establishing prevalence across the segment.
Disagreement would be useful evidence. Suppose one agency wanted more client involvement while another preferred to send a finished report with no review cycle. The brief would need to ask whether they serve different clients or work differently. Erasing the disagreement into a general demand for collaboration could hide the reason a proposed feature would suit only part of the market.
Scout would then compare those reported needs with documented product capabilities. The output could distinguish a job the product already supports, a job that would need an altered working practice, and a job that depends on new functionality. Those distinctions would help the product leader see whether the proposed expansion is primarily a fit test or a substantial development commitment.
A weak collection of feedback would lead to a discovery proposal. It would not justify a confident market-size estimate. Even clear evidence that several people experience a problem leaves unanswered how widespread it is, how urgently they want to solve it, and whether the existing product is an acceptable way to do so.
Turn the agency question into three experiments
The opportunity memo would connect the agency need with three possible experiments, each aimed at a different uncertainty. The team would receive the target user, hypothesis, success condition, required effort, and next decision for each. Effort and uncertainty would remain separate: a cheap test can still address a poorly supported idea, while a credible opportunity can require an expensive test.
The first experiment could investigate the reporting job through customer discovery. With the team's authorization, a researcher could ask agencies in the selected segment to explain how their latest recurring report was prepared and reviewed. The useful evidence would be the actual sequence and the troublesome step. General enthusiasm for a new tool would leave the original uncertainty largely intact.
Before starting, the team would agree what would warrant the next experiment. A recurring problem at a step the existing product can address would support a fit test. If the difficult work lay in collecting information from systems the product does not support, the founder might narrow the segment or reject the idea. The discovery result would change the plan rather than merely add favorable quotations to it.
The second experiment could test the current product on a bounded reporting task. An authorized participant could try to turn permitted sample material into a report suitable for client review. The test would need to record where the participant required explanation, manual work outside the product, or help from the team. A finished report would be less persuasive if producing it depended on assistance the agency could not normally receive.
This experiment would separate an understandable workflow from a technically possible one. If the product already performs the necessary operations but the participant cannot find them, the next decision could concern guidance or presentation. If a required operation is absent, that would become a product gap. The team would avoid treating every difficulty as proof that it needs to build the same proposed feature.
The third experiment could examine the commercial response to a bounded offer based on what the fit test established. With approval for the outreach and terms, the team could present a specific reporting use and ask qualified agencies whether they would take the agreed next step. The offer would describe available capabilities, with any limits visible. A response to a promised future capability would test a different proposition.
The success condition would have to be chosen before interpreting responses. A request to see a demonstration, agreement to try a workflow, and a purchase are different levels of commitment. Recording the behavior actually requested would let the commercial lead decide whether the evidence supports further testing. It would also prevent a collection of polite replies from becoming a claim of validated demand.
These experiments need not all proceed. Scout's proposed ranking would explain dependencies between them. If discovery contradicts the assumed reporting problem, the later tests might become irrelevant. The decision maker could stop, revise the question, or authorize the next experiment with the uncertainty stated plainly.
Keep the research useful after the first decision
A focused market brief, competitor change log, opportunity register, and experiment briefs provide different views of the same investigation. The brief answers the immediate question. The change log preserves dated observations. The opportunity register connects each possible use with its supporting evidence and current decision. Experiment briefs describe what the team would do to resolve a remaining uncertainty.
In Scout's proposed research memory, the agency investigation would retain its earlier hypotheses and the reasons for accepting or rejecting them. If the team declined to proceed because a required capability was missing, a later product change could provide a specific reason to reopen the question. A general instruction to research agencies again would lose that useful starting point.
The history would also preserve test results supplied by the team. An experiment that found poor fit should remain visible alongside one that produced interest. Otherwise, a later summary could favor the successful-looking material simply because it was easier to reuse. Rejected ideas help the company avoid repeating a test without a reason to expect a different result.
Sales and product teams could use the dated comparison notes for objection research and positioning. They would still need to distinguish a competitor fact from the company's interpretation of it. The agency team might choose to emphasize a simpler reporting process, but that positioning would need evidence from its own product and testing. Research about another product's limitations alone would not prove superiority.
Define research authority and evaluate the decision
Scout's inputs can include approved public websites, release notes, research documents, and selected internal customer feedback. Source access rules and internal document permissions remain in force. The operating boundary is concrete: preparing a research brief or experiment draft does not authorize outreach, publishing, paid research purchases, or commercial commitments. Those actions remain subject to the team's chosen authorization process.
The researcher or decision maker would review whether the brief's conclusions follow from its references. For the agency investigation, that means checking that customer evidence belongs to the selected segment, competitor comparisons are dated, and proposed experiments address the gaps the brief actually found. A well-written recommendation with no resolving test would still leave the expansion decision unsupported.
Useful evaluation measures include source accuracy, time to an accepted brief, and the share of opportunities with a testable hypothesis. Human correction time belongs beside preparation time: a quick draft that confuses available and promised features creates more research work for its reviewer. These are evaluation criteria, not reported performance results.
For the illustrated agency question, the team estimates around 1.5 hours to check sources and dates, challenge the fit assessment, and decide on the experiments, against roughly 8 hours of research, comparison, and writing by hand: around 5× faster to an accepted brief. This is a modeled estimate for one bounded question, not a measured result.
The team should also follow what happened to the recommendation. Did the evidence change the selected segment, start an experiment, or support a deliberate rejection? For the illustrative agency question, the next decision could be to authorize discovery and defer building. The record should identify the unanswered question that discovery must resolve before engineering capacity is committed.