Prompt and context
Design a product that helps people discover local events. Cover target users, use cases, supply, search and recommendations, trust and safety, cold start, metrics, and V1 scope.
The answer does not need to default to a map or social network. Choose a specific audience and context, then explain why other directions wait. Location data, event privacy, and organizer quality are real constraints.
What the interviewer is testing
User segmentation
A strong answer chooses a concrete group, such as people new to a city, families with children, or a hobby community, instead of treating every resident as one user. The segment changes event types, trust requirements, and discovery entry points.
Problem prioritization
Validate why users cannot find a good event: fragmented information, timing, distance, uncertain quality, or lack of companions. Prioritize one frequent problem the product can improve.
Two-sided supply
Organizers and attendees jointly create value. Explain how real events enter the catalog, how duplicates and expired listings are handled, and why organizers keep updating them.
Metrics and tradeoffs
Connect success metrics to discovering and attending a suitable event. Track misleading listings, complaints, permission denial, and supply concentration as guardrails.
Clarifying questions to ask
- Which city, event types, and age range are in scope?
- Is the product for visitors, residents, organizers, or all three?
- Does supply come from partners, organizers, or public data?
- Must discovery be real-time and personalized, or accurate first?
- Is precise location allowed, and what happens after denial?
- Is the goal browsing, registration, attendance, or filling organizer capacity?
30-second answer framework
“I would start with adults who recently moved to a city and want a small weekend activity with people who share an interest, without joining a large social group. The problem is finding events that are trustworthy, fit their time, and are close enough. V1 lets verified local organizers submit structured events; users filter by time, distance, and interest, with source, update time, and cancellation policy visible. A user-selected area works without location permission. I would measure detail-to-registration and registration-to-attendance conversion, with expiry, complaint, and organizer-retention guardrails.”
Step-by-step deep dive
Step 1: Choose a wedge
Pick a group with a concrete job, such as new residents seeking small hobby events. Describe current search behavior, why it fails, and which information users will provide.
Step 2: Define the core job
Define the job as finding a trustworthy event within acceptable time and distance. Separate browsing, saving, sharing, registering, and attending so clicks do not masquerade as task completion.
Step 3: Build supply and trust
Let verified organizers submit start time, area, capacity, price, cancellation policy, and update time. Merge duplicates, remove expired events, and support reports for fraud, discrimination, or danger.
Step 4: Design discovery
V1 offers area, time, interest, distance, and price filters. Rank by relevance, freshness, and trust rather than sponsorship alone. Show source, location precision, last update, and registration destination on the detail page.
Step 5: Handle location and privacy
Ask users to choose a city or neighborhood before requesting browser location. Keep manual search after denial; retain only the coarse area needed and provide deletion and editing controls. Location is progressive enhancement, not a gate.
Step 6: Cold start and metrics
Partner with a small set of venues, community groups, and event platforms in one city. Track qualified-detail-to-registration and registration-to-attendance conversion. Guardrails include expiry, duplicate, complaints, cancellations, permission denial, and seven-day organizer retention.
Model high-quality answer
“I would target adults who recently moved to a city and want a small weekend hobby activity. Their problem is not a lack of events; it is fragmented information, poor time and distance fit, and uncertain organizer quality.
V1 is a city-level directory. Verified organizers submit structured fields, and the system checks duplicates, expiry, and missing data. Users choose a city or neighborhood and filter by time, interest, distance, and price. The detail page shows source, update time, capacity, and cancellation policy, then sends registration to the organizer. Manual area search remains available without precise location.
My value metrics are detail-to-registration and registration-to-attendance. Expiry, complaint, duplicate, cancellation, and organizer-retention rates are guardrails. I would validate supply and attendance in one city and one interest vertical before adding recommendations, social features, or cross-city discovery.”
Common mistakes
- Serving everyone → no focused demand or supply → choose one city and segment.
- Starting with maps and social features → value is unvalidated → solve trustworthy discovery and registration first.
- Relying only on user submissions → cold start and quality are uncontrolled → add verified organizers and structured fields.
- Using clicks as success → misleading listings can increase clicks → track registration, attendance, and complaint guardrails.
- Requiring precise location → denial blocks the product → provide city or neighborhood search.
- Counting event volume → duplicates and expiry pollute supply → monitor freshness, duplicates, and removal time.
- Ignoring organizers → supply will not persist → design verification, editing, and retention loops.
- Expanding into social too early → safety and moderation costs grow → validate discovery-to-attendance first.
Follow-up questions and responses
Follow-up 1: What if supply is too small?
Narrow the city and interest scope, recruit a few high-quality organizers, and provide import tools. Prove usable density before opening submissions and recommendations.
Follow-up 2: What if users deny location permission?
Keep city, neighborhood, and postal-code search. Use the area the user chooses for the core job; use device location only after explicit permission to improve ranking.
Follow-up 3: How do you prevent fake or dangerous events?
Verify organizers, contact details, and cancellation rules; detect duplicates and unusual edits; support reporting and rapid removal. Add human review for high-risk categories.
Follow-up 4: Will ranking make popular events even more popular?
Rank with relevance, freshness, trust, and diversity, and give new events controlled exposure. Monitor long-tail detail-to-registration conversion rather than clicks alone.
Follow-up 5: How do you decide whether to enter a second city?
Require several cycles of qualified supply density, registration-to-attendance conversion, complaint rate, organizer repeat posting, and user retention in the first city. Then assess supply access and local rules in the next city.
Source 1: Meta product-manager interview guide
Meta’s official preparation guide emphasizes explaining why a problem matters, user empathy, segmentation, tradeoffs, goals, and metrics—signals that apply to this product-sense answer.
Source 2: Location permission and fallback
MDN documents that the Geolocation API needs user permission, is available in secure contexts, and requires denial and error handling. That supports manual area search as the no-permission fallback.
Source 3: Public product-sense prompt
Public interview-preparation material lists “help people find local events” as a product-design exercise focused on segmentation, prioritization, tradeoffs, and metrics rather than feature volume.