Theme park product design: choosing users, a core pain point, an MVP and metrics

Come up with a new product for theme parks: pick the users it serves and the problem it solves, describe what you would build, and say how you would know it is working. ```hint Look past the ticket booth Large parks usually run their own app for tickets, maps and wait times. Look for a moment in a park day that those apps leave painful, and for the visitors who feel it most. ``` ### Clarifying Questions - Is the product for park visitors, for park operators, or both? - Should it be software only, or can it include physical items such as wristbands or vehicles? - Should it live inside Meta's existing apps and social features, or stand alone? - Can we count on a partnership with park operators (ride wait times, ticketing, staff help), or must it work without the park's cooperation? ### What a Strong Answer Covers - A reason for the company to build this, and a chosen user segment with the reason others wait - Pain points mapped across the visit, before, during and after the park day - Solutions that go beyond what park operators' own apps offer, prioritized down to a first release - Success metrics and guardrails that account for how rarely most people visit a theme park - Risks such as location privacy, child safety, battery and connectivity, and park cooperation ### Follow-up Questions - Most families visit a big theme park once or twice a year at most. How would you keep the product from being forgotten between visits? - How would your design change if the customer were the park operator rather than visitors? - What would you need from park operators, and what would you offer them in return?