Turn Match Preview Signals Into Mobile App Requirements
A match preview can suggest useful discovery questions, but it cannot prove demand. Use a structured process to validate fan needs and define a focused app scope.
A match preview describes a particular event; it does not tell a product team what fans want from an app. Still, it can provide a useful starting point for discovery. Preview coverage of the Kansas City Current–Bay FC match includes event-specific context that prompts questions about schedules, venue information and fan priorities. The practical task is to turn those prompts into evidence, then into testable requirements—not to assume a new product is wanted. This guide offers a lightweight method for product leaders to separate event facts from hypotheses, validate important needs with intended users, and decide what belongs in an initial mobile app scope.
Treat the preview as a prompt, not a product brief
Start by extracting only what the supplied material actually establishes. In this case, the signal is preview coverage for a Kansas City Current–Bay FC match, including references to the teams and a specific event. That may help a team frame discovery around when fans need information, what venue details might matter, and which questions arise before attending. It does not establish that fans lack an app, that they want particular features, or that the clubs have commissioned a product. Record the event context as a research prompt, alongside its source and date, so it is not later mistaken for validated user evidence.
Next, turn each prompt into an open question rather than a feature request. “Would you use a venue guide?” steers people toward a proposed solution; “What information do you look for before travelling to a match?” asks about behaviour. Follow up with what they checked, when they checked it, and what was difficult or uncertain. Keep the distinction visible in a discovery log: observed source material, assumptions to test, user-reported behaviour, and decisions. This simple separation reduces the risk of a compelling news hook becoming a premature requirements list.
- Label every event-derived idea as an unvalidated hypothesis until research supports it.
- Do not infer product demand, club plans or user preferences from a match preview.
Validate fan priorities across the journey
Explore the journey around the event, not just the moment of kickoff. Ask participants how they learn the start time, where they check venue details, what they need while travelling, and which questions come up after arrival. Interview people with different levels of familiarity with the venue and matchday routine; a regular attendee may navigate information differently from a first-time visitor. Where possible, ask people to walk through a recent experience or show the sources they actually used. That makes it easier to distinguish a frequent, consequential problem from a feature idea that sounds attractive in conversation.
A useful discovery record links each need to evidence and impact. For example, a hypothetical participant might say they check several places to confirm when gates open. Record that as a reported task, note how many research participants raised it without treating a small sample as representative, and investigate whether the information is available from a reliable source. Then test whether a mobile app is the appropriate solution: perhaps the existing website works, or perhaps the gap is inconsistent information ownership. Requirements should address the demonstrated problem, not encode a predetermined app screen.
- Ask about actual past behaviour before showing concepts or suggesting features.
- Record source, confidence, affected user group and unresolved questions for each finding.
Convert evidence into a focused, testable scope
Prioritise candidate requirements using a compact decision test: Is the need supported by research? Does it matter at a clear point in the fan journey? Can the product team obtain accurate information and keep it current? Is a mobile app the right channel? What is the consequence if the feature is unavailable or wrong? A schedule display, venue details, or another proposed capability should pass these checks independently; their appearance as discovery themes does not automatically place them in an MVP. Also identify dependencies such as content ownership, update processes, permissions, and any systems that would need to supply information.
Write each selected requirement so it can be checked without prescribing unnecessary implementation detail. A hypothetical requirement could be: “Before matchday, a fan can find the confirmed event start time and venue address from the event detail view; the displayed values identify their source and last update.” The team would still need to validate whether fans need that information, confirm the data source and freshness rules, and define acceptance criteria with stakeholders. Keep rejected ideas and reasons in the backlog. Revisit priorities when research or operational constraints change, rather than expanding scope in response to every event-specific signal.
- For each proposed feature, capture user need, evidence, data dependency, owner and acceptance test.
- Use a prototype or low-cost content test to check comprehension before committing to full implementation.
Match-preview coverage can help a team choose a timely discovery question, but it is not evidence of demand. Preserve that distinction from the first research note through the product backlog. Ask fans about real behaviours, verify the information and operational dependencies behind potential features, and prioritise only needs that research supports. The result is a more defensible mobile app requirements list: focused on a specific user journey, explicit about uncertainty, and testable before significant development effort is committed.