Imagine arriving in an unfamiliar city with just 90 minutes to spare. Google Maps shows dozens of cafés, museums, parks and attractions, yet you still cannot decide where to go. The nearest attraction might be uninteresting, the highest-rated place might be crowded, and reaching a popular destination could consume most of your available time.
The problem is not necessarily a lack of information. In fact, having too many options can make the decision more difficult.
Now imagine facing this Product Manager interview question:
"Redesign the Google Maps location discovery experience for the inexperienced traveller."
At first glance, this sounds like a user experience design exercise. A strong answer, however, requires more than proposing additional features.
The interviewer wants to understand whether you can identify the underlying user problem, prioritise different needs, recognise product constraints and recommend a solution whose effectiveness can be tested.
Start by defining the problem, not the interface
Before proposing any redesign, I would distinguish between two different user needs.
Finding a known place: The user already knows the name of a restaurant, hotel or attraction and wants to locate it.
Discovering a suitable place: The user has not decided where to go and expects the product to help them choose.
This interview question concerns the second situation.
Someone visiting a new city may not recognise neighbourhood names, understand the local geography or know how to interpret ratings and reviews in the context of their own circumstances.
Importantly, being an inexperienced traveller does not necessarily mean being inexperienced with technology.
Someone might be highly capable of using mobile applications but have no familiarity with the city or country they are visiting.
This distinction matters because defining the problem incorrectly could lead us to build a tutorial for Google Maps rather than improve the experience of choosing somewhere to visit.
For the purpose of this discussion, I would make a specific assumption: our primary user is someone exploring an unfamiliar city on a smartphone, with limited time, no predetermined destination and an expectation of making short journeys on foot.
That is a starting hypothesis, not a description of all travellers.
Someone travelling with children, requiring step-free access or dealing with unreliable connectivity might have substantially different needs.
Does Google Maps actually need another feature?
Before recommending a new capability, we need to understand what the existing product already offers.
Google Maps supports nearby searches, ratings and reviews, place details and discovery through its Explore section.
According to Google Maps' official documentation, Explore recommendations can adapt to location and time of day. Google also explains that local search ranking is influenced primarily by relevance, distance and prominence.
It would therefore be inaccurate to suggest that users currently have no way to discover places.
The more useful question is:
Do these existing capabilities adequately help travellers who have not yet decided what they want to visit?
There is a meaningful difference between displaying relevant places and helping someone make a decision appropriate to their circumstances.
But that difference remains a hypothesis until we validate it.
Research might reveal that travellers are satisfied with existing recommendations and merely struggle to find certain filters.
If so, a smaller usability improvement could be more valuable than a new discovery experience.
Understand the user before choosing a solution
I would segment users according to their circumstances and the task they are trying to accomplish, rather than simply by age, nationality or technical confidence.
For example:
Time-constrained travellers want to find somewhere worthwhile without spending too much time travelling or comparing alternatives.
Experience-seeking travellers want places aligned with their interests, rather than necessarily visiting the most famous attractions.
Travellers with additional constraints may care more about accessibility, cost, language support or connectivity.
We should not attempt to solve every segment's problems in the first release.
For our initial target group, I would investigate four questions:
- Where does the difficulty occur: finding options, comparing them or trusting the available information?
- What information influences a traveller's decision to visit or reject a particular place?
- How do travellers make these decisions today? Do they consult Google Search, social media, friends or local residents?
- Does the problem occur repeatedly, or mainly when travellers face constraints such as limited time or unfamiliar languages?
I would combine contextual observation, short interviews, usability sessions and analysis of existing product journeys.
Click data alone would not answer these questions.
A traveller might open five place profiles, return to the results and still fail to choose a destination. More engagement would not necessarily mean a better experience.
Three possible approaches to redesigning place discovery
Once the problem has been validated, I would compare at least three approaches.
Option 1: Simplify existing search and filters
We could make search categories and filtering controls more visible and easier to understand.
This approach would generally involve less disruption and preserve familiar user behaviour.
However, if someone does not know what type of place they want, better filters may not solve the fundamental problem.
Option 2: Build a dedicated tourist mode
We could introduce a separate travelling experience with local recommendations, itinerary planning and destination guidance.
This could address a broader range of needs.
The trade-off is additional design, engineering, maintenance and interface complexity.
We also have no evidence yet that travellers want an entirely separate experience rather than improvements to the Google Maps interface they already recognise.
Option 3: Provide optional, guided place discovery
My preferred starting point would be to test a lightweight, guided discovery journey within existing Google Maps functionality.
The experience could begin with a straightforward question:
"What would you like to do right now?"
The traveller might choose a short walk, somewhere to relax, a meal or a cultural experience.
Where relevant, they could then specify their available time and preferred way of getting around.
Instead of presenting a long list, the product would offer a small number of relevant suggestions, explaining why each might suit the traveller.
Those explanations could include:
- Relevance to the selected activity
- Estimated journey time and the traveller's time constraints
- Available opening-hours information
- Supporting evidence, such as place attributes and reviews
Each recommendation would allow the traveller to examine the details, save the place or request directions.
I would choose the third approach as a testable hypothesis, not as a predetermined answer.
The guided experience must remain optional.
Users should be able to dismiss it and return to ordinary search or browse all results without unnecessary friction.
Why fewer recommendations are not automatically better
Offering three suggestions instead of thirty might appear to simplify decision-making.
But there is an important risk: a recommendation system can inadvertently hide suitable options if its assumptions are wrong.
Reducing the number of choices is not, by itself, evidence of improvement.
Recommendations need to reflect the traveller's actual requirements, and the reasons behind them should be understandable.
Users must also retain the ability to change their preferences and explore alternatives.
A highly rated place is not necessarily appropriate for every traveller.
For example, a popular restaurant might require more travel time than the user can afford. A highly recommended museum might close before they arrive.
There is also a distinction between displaying information and guaranteeing that it is correct.
Opening hours, facilities and other place attributes can be incomplete or outdated. The product should communicate uncertainty where information is insufficient rather than imply unwarranted confidence.
Connectivity introduces another constraint.
Google Maps supports downloadable offline maps, but its official documentation explains that walking directions are unavailable when offline.
We therefore cannot promise a complete offline walking-discovery experience simply because an area has been downloaded.
A credible Product Manager answer needs to acknowledge such limitations before recommending an implementation.
A practical hypothetical software-product scenario
Imagine the Google Maps product team wants to test this concept with inexperienced travellers.
Our hypothetical user has arrived in Lisbon for the first time.
They have approximately 90 minutes before returning to their hotel and would like to visit somewhere culturally interesting.
In the existing experience, they might search for "attractions near me", open several results, inspect photographs and ratings, then repeatedly check distance and opening hours.
In our proposed experience, the user enters an optional "I have some free time" journey through Explore.
They select a cultural activity, a time allowance of up to 90 minutes and walking as their preferred transport mode.
The product presents a few options with estimated journey times, opening-hours information and explanations of why the places fit the chosen criteria.
The traveller can still browse all results or return directly to the standard search experience.
This is a hypothetical product-design exercise, not a description of an actual Google experiment or a confirmed existing feature.
The Product Manager would define the target problem, desired outcomes and prioritisation. The UX designer would develop and test the interaction. Engineers would assess data availability, response times and technical constraints. A product analyst would help design the evaluation.
Location data introduces additional privacy considerations.
Any location-dependent functionality should give users clear control over permissions, and selecting an area manually should remain a practical alternative.
How would we measure success?
If our objective is to help travellers make better decisions, the number of place-profile views should not be our primary success metric.
I would structure measurement around three levels.
1. Primary metric: Successful place selection
In a usability study, we could evaluate whether participants can select a suitable destination within a defined scenario and explain why it meets their requirements.
The task would include explicit constraints, such as available time, transport mode and preferred activity.
Task success rate = Participants making a valid, constraint-compatible choice ÷ All participants attempting the same task
The definition of a valid choice must be agreed before testing.
For example, the selected destination should be compatible with the time allowance, transport constraints and available evidence about the place.
In production, saving a place or starting directions might serve as a behavioural proxy for progress towards a decision.
Neither action proves that the traveller arrived or was satisfied with their choice.
2. Diagnostic metrics
I would examine the time required to choose a destination, unnecessary switching between results, uptake of the optional guide and the rate at which users return to standard search.
These measures would help identify where the proposed experience reduces friction and where it introduces additional effort.
3. Guardrail metrics
We must also monitor unintended harm.
Relevant guardrails include incorrect place information, recommendations that do not meet user constraints, slower response times, privacy-related friction and increased abandonment of the discovery journey.
I would evaluate the proposed experience against the existing one using comparable groups, and examine differences between new and experienced users, languages and geographical contexts.
The goal is not merely to make choices faster.
It is to help people make choices that are faster, better justified and more appropriate to their circumstances.
What if we had only two weeks?
This is one of the two follow-up questions included in the original interview-question reference.
With only two weeks, I would avoid attempting to build a complete new capability.
I would begin with targeted observations and interviews to identify where the current journey fails.
Next, the team would build a lightweight interactive prototype of the proposed discovery flow, using existing place information wherever practical.
We would test that prototype with people representing the target segment, using realistic or carefully simulated travel scenarios.
At the end of the two weeks, I would not expect a fully developed product.
I would expect enough evidence to answer three questions:
Do these travellers genuinely need more help choosing destinations? Does guided discovery improve their decisions? Is the evidence strong enough to justify further investment?
If the evidence does not support the hypothesis, continuing simply because the concept seems appealing would be poor product judgement.
What evidence would make you reject your proposed solution?
The second follow-up question asks whether we can recognise when our preferred idea is wrong.
If research showed that inexperienced travellers already make effective decisions through existing search and filters, the underlying hypothesis would be weakened.
I would also reconsider the proposal if testing showed that the guided journey increased decision time, concealed relevant places or produced unreliable recommendations because of incomplete data.
We might discover that travellers do not need a new recommendation experience at all.
Perhaps they simply need clearer opening hours, journey information or accessibility details when comparing existing results.
In that case, improving how place information is presented could be a better investment than adding another discovery journey.
Being willing to abandon a personally appealing solution is part of sound product management.
A natural interview answer
If I were answering this question in an interview, I would bring the reasoning together like this:
"Before changing Google Maps, I'd want to understand where inexperienced travellers actually struggle. Finding the address of a known place and choosing somewhere to visit in an unfamiliar city are two different problems.
"My initial hypothesis is that some travellers, particularly those with limited time, struggle to compare the available options and choose somewhere suitable.
"I'd first look at how they make that decision today and whether the existing discovery features are genuinely insufficient.
"If we validated that problem, I'd test a small, optional guided experience inside Explore rather than immediately building a separate tourist mode.
"It could ask what the traveller wants to do, how much time they have and how they intend to travel, then suggest a few relevant places with clear explanations.
"I'd measure whether that helps people choose suitable destinations, not just whether it generates more clicks. If recommendations were unreliable or the experience introduced additional friction, I'd change the approach."
Common mistakes in answering this question
Starting with a feature list: Artificial intelligence, augmented reality and dedicated tourist modes might sound impressive, but they are not automatically worthwhile investments. We first need to establish which user problem they solve.
Designing for every traveller: Someone visiting a city for the first time may have very different needs from a frequent visitor. A strong answer identifies and prioritises a meaningful segment.
Ignoring existing functionality: Without understanding what Google Maps already offers, we risk proposing duplicate capabilities or addressing the wrong problem.
Over-relying on ratings and popularity: A highly rated destination might be unsuitable for a particular user's time, budget or purpose.
Mistaking engagement for success: More clicks on recommendations do not prove that travellers are making better decisions.
Showing false certainty: Product Managers should state their assumptions and explain what evidence would cause them to revise their choices.
Conclusion
Redesigning place discovery in Google Maps should begin with understanding why some travellers struggle to choose destinations despite having access to extensive information. If that problem is validated, I would start with a short, optional discovery experience that considers the traveller's goals and constraints rather than introducing an entirely separate product journey.
The final decision must depend on evidence. If the new experience does not help travellers choose more suitable places, or if it undermines their trust in the recommendations, the approach should change. Strong Product Managers are not distinguished by how many features they propose, but by their ability to identify the right problem and make defensible, measurable decisions about solving it.
