Design a parking-finding experience for **Google Maps**. Assume the product goal is to help drivers reduce uncertainty and wasted time when parking near a destination, especially in dense urban areas. Walk through how you would define the problem, choose a target user segment, design the product, prioritize an MVP, define success metrics, and address monetization and counter-metrics. ### Constraints & Assumptions - Keep the experience inside Google Maps rather than proposing a separate parking app unless you justify why. - Consider both garages/lots and street-parking uncertainty, but do not assume perfect real-time street availability. - Balance user trust, local regulation, partner data quality, and business incentives. - State assumptions for geography, launch scope, and data sources. ### Clarifying Questions to Ask - Is the primary goal user satisfaction, navigation completion, revenue, or marketplace expansion? - Are we launching globally or piloting in a few dense cities? - Can Google partner with parking operators, cities, or event venues? - Should the product support reservation/payment at launch, or only discovery and guidance? ### Part 1 - Define The User Problem And Segment Who are the target users, what pain are they experiencing, and why is this problem worth solving? #### What This Part Should Cover - A specific high-pain segment such as drivers going to dense urban destinations, airports, events, offices, or restaurants. - The core job to be done: arrive with confidence, avoid circling, understand price/rules, and complete the trip. - A reason not to solve for every driver and every city on day one. ### Part 2 - Design The Product What should the parking experience include, and how should it fit into the Google Maps journey? #### What This Part Should Cover - Pre-trip parking suggestions, availability confidence, price and walking-distance filters, and navigation handoff. - A clear distinction between reliable partner inventory and lower-confidence predictions. - User-facing trust mechanisms such as confidence labels, rule clarity, reports, and fallback options. ### Part 3 - Prioritize The MVP Which features would you launch first, and which would you defer? #### What This Part Should Cover - A focused MVP with structured garage/lot data, eligibility triggers, filters, and last-mile walking directions. - Deferred ideas such as guaranteed street parking, peer-to-peer spaces, or broad real-time coverage if they add too much risk. - A prioritization rationale based on reach, impact, confidence, and effort. ### Part 4 - Define Success, Business Model, And Counter-Metrics How would you measure success, monetize the product, and guard against harmful outcomes? #### What This Part Should Cover - A north-star or primary outcome tied to successful parking-assisted trips. - Metrics for adoption, time-to-park, prediction accuracy, reservation/payment conversion, repeat usage, and trust. - Revenue options such as referrals, bookings, transactions, or sponsored placements, with trust guardrails. - Counter-metrics for wrong recommendations, increased circling, citations, unsafe routing, cancellations, user complaints, and Maps performance impact. ### What a Strong Answer Covers - Starts with the user problem rather than a feature list. - Makes realistic assumptions about data quality and city-by-city launch constraints. - Shows good product judgment about trust, accuracy, and monetization tradeoffs. - Connects metrics to actual user value, not just clicks. ### Follow-up Questions - How would your answer change for street parking versus paid garages? - What would you do if availability predictions were only 60% accurate? - How would you rank paid placements without hurting user trust? - What local regulation or safety issues would you investigate before launch? - How would you test this in one city before scaling?