Product discovery for an arts-service idea
Investigate a studio-equipment booking idea by separating observed problems, assumptions, operational limits, and solution options before deciding what deserves a prototype or further research.
Investigate the problem behind the app
A proposal for a studio-equipment booking app may begin with a confident feature list, yet the real difficulty might be training authorization or unclear opening hours. Product discovery examines the problem before committing to a particular solution. It should reduce consequential uncertainty rather than turn every early opinion into a polished requirement.
Separate observations from assumptions
Start with questions about current behavior, who experiences the difficulty, and how the service operates. Separate direct observations from interpretations and assumptions. Identify constraints that would remain even with a new interface. A booking calendar cannot solve an equipment shortage, but it may make availability clearer and reduce avoidable coordination. Separate what the system knows from what the person has actually been told. A technically valid operation can still look unsuccessful when its confirmation is delayed or ambiguous. Describe the state before the action, while work is pending, and after it completes. Then name the information that remains available if the person leaves and returns. These notes become concrete requirements for the eventual implementation.
Build a print-press assumption table
Create an assumption table for booking a shared print press. Include demand, eligibility, reservation conflicts, and cancellations. For each assumption, propose an appropriate way to learn more, such as reviewing existing processes, interviewing studio coordinators, or observing a booking attempt. Do not put invented answers into the table. Work through the example once from the customer's perspective, once from operations, and once after an interruption. These passes examine different assumptions; none replaces research with people who use the finished service. Preserve the same task and content across passes so that changes reveal weaknesses in the design rather than unrelated differences in the scenario. Capture each weakness as a specific revision, not a general impression.
Avoid feature voting and endless discovery
If discovery produces only feature preferences, redirect discussion toward recent concrete situations. If it expands indefinitely, return to the decision the team needs to make. Some questions can be resolved with existing operational records; others need research. Building a prototype before understanding those differences can make an unsupported solution feel prematurely settled. Distinguish a missing cue from a missing capability. Product content can explain an available recovery path, but it cannot create a recovery path the system lacks. Annotate where the interface needs a different state, a preserved value, or an operational response. Give each case a visible outcome. Otherwise an apparently helpful message may simply send someone around the same unsuccessful loop with more words to read.
Record the next investment decision
Finish with a clear decision record: what is understood, what remains uncertain, which solution options are plausible, and what evidence would justify the next investment. Include the possibility that a process or content change would address the problem. Discovery is useful when it changes or clarifies a decision, even if it reduces the amount of software proposed.
Worked decision
If press reservations are blocked by training approval, investigate authorization before assuming a new calendar will resolve the obstacle.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
