##### Question
a. Name three products you admire—at least one must be non-technology. For each, explain why you like it and how it compares against key competitors.
b. Pick one of the three (e.g., Google Maps) and describe how you would improve it. Identify user pain points, success metrics, and a prioritized roadmap of enhancements.
Overview: Practice a product sense and roadmapping prompt about admired products and improvement planning. The solution compares Google Maps, Notion, and IKEA, then deep-dives on a Google Maps parking confidence roadmap with target users, pain points, MVP phases, success metrics, experiments, and guardrails.
Solution
# Solution: Favorite Products and Optimization
## 1. Three Products I Admire
### Google Maps
Job to be done:
- Help users confidently get from intent to arrival, including search, route choice, navigation, and local discovery.
Why I admire it:
- Global coverage.
- Strong routing.
- Local search and reviews.
- Multimodal navigation.
- Useful in both planned and urgent situations.
Competitors:
- Apple Maps: strong iOS integration and polished design, but historically less broad in local discovery.
- Waze: excellent driver incident reporting, but narrower outside driving.
- HERE WeGo: strong offline maps, less consumer mindshare.
Trade-off:
Google Maps is broad and powerful, but complex trips, parking, EV charging, and route explainability still create pain.
### Notion
Job to be done:
- Help individuals and teams organize knowledge and lightweight workflows.
Why I admire it:
- Flexible blocks.
- Databases.
- Templates.
- Strong community.
Competitors:
- Evernote: simpler capture, less flexible workflow building.
- Coda: powerful interactive docs, steeper learning curve.
- Confluence: enterprise documentation, less personal flexibility.
Trade-off:
Notion's flexibility can create information architecture sprawl.
### IKEA Flat-Pack Furniture
Job to be done:
- Help customers furnish a home affordably with transportable, modular products.
Why I admire it:
- Product design, packaging, logistics, and price are tightly integrated.
- Showrooms help customers visualize complete rooms.
- Flat-pack model lowers distribution cost.
Competitors:
- Wayfair: more online selection, less consistent in-person experience.
- Target: convenient and affordable, less complete room-planning depth.
- West Elm: higher design polish, higher price.
Trade-off:
IKEA wins on affordability and system design, but assembly friction and store complexity can be painful.
## 2. Improvement Plan: Google Maps Parking Confidence
### Target Users
- Urban drivers.
- Event-goers.
- Travelers.
- EV drivers.
- People visiting unfamiliar neighborhoods.
### Pain Point
Google Maps often gets users to the destination, but not necessarily to a confident parking outcome. Users still circle blocks, misjudge garage entrances, face unexpected pricing, or discover that street parking is restricted.
### Hypothesis
If Google Maps helps users choose parking based on certainty, price, distance, and walking time before arrival, then users will spend less time circling, feel more confident, and return to Maps for future driving trips.
## 3. Feature Proposal
Parking Confidence Layer:
- Parking difficulty badge for destination.
- Off-street garage and lot options.
- Price, hours, walking time, and entrance routing.
- Availability confidence.
- Reservation where partners support it.
- On-street likelihood zones only where data quality is strong.
MVP:
- Launch in dense cities with garage partners.
- Focus on off-street options first.
- Add walking directions from parking to destination.
- Collect feedback on availability and entrance accuracy.
## 4. Roadmap
Phase 1: Discovery and data quality.
- Identify markets with high parking pain and strong partner coverage.
- Validate data reliability.
Phase 2: MVP.
- Parking badge.
- Garage option comparison.
- Entrance routing.
- Reservation links.
- User feedback.
Phase 3: Expansion.
- Event and airport flows.
- EV charging filters.
- On-street probability where city data supports it.
Phase 4: Personalization.
- Rank by user preference: cheapest, closest, most certain, EV, accessible.
## 5. Metrics
Primary metric:
- Successful parking-assisted trips.
Secondary metrics:
- Parking option click-through.
- Reservation conversion.
- Time from arrival area to parked.
- Repeat use.
- User satisfaction after parking.
- Entrance accuracy.
Guardrails:
- Illegal parking reports.
- Wrong availability reports.
- Driver distraction.
- Congestion near recommended areas.
- Partner bias complaints.
- Refunds or disputes.
## 6. Experiment and Rollout
Rollout:
- Pilot in one or two markets.
- Compare users shown parking guidance with matched users or randomized eligible sessions.
- Measure trip-level outcomes and feedback.
Decision rule:
Scale if parking-assisted trips reduce time-to-park and improve satisfaction without increasing complaints, wrong availability, or congestion.
## 7. Stakeholder Alignment
Partners:
- Maps engineering.
- Local data.
- Parking partners.
- UX research.
- Trust and safety.
- Legal.
- Ads/commerce if monetization is considered.
Narrative:
"Maps is trusted for navigation, but the trip is not done until the user can park. Improving the last 200 meters strengthens Maps' core job to be done."
## 8. Variant: Three Products You Use Every Day
Some interviewers ask for three products you use every day instead of three you admire. The structure above still works, but the emphasis shifts from admiration to repeat choice, and the rule about including a non-tech product no longer applies.
What changes:
- Picks must be genuine daily habits. IKEA furniture is something you buy rarely, so it does not fit this version; swap it for a product you open every day, such as a messaging app or a music streaming service.
- Lead with the need and the moment it shows up in your day, not with what you find impressive.
- Explain why you keep choosing it: reliability, low friction, accumulated history or data, defaults, or the fact that the people you need are already there.
- Name the alternative you would otherwise use and what it would take for you to switch.
- Keep one honest weakness that has not yet been bad enough to make you leave.
How the existing picks adapt:
- Google Maps: the need is getting to work or errands on time every day. You keep choosing it because its arrival estimates and live traffic are trusted enough that you stop checking other apps, and saved places make each trip faster to start.
- Notion: fits only if you use it daily for notes, plans, or tasks. The reason you stay is that your notes and templates live there, so moving to Evernote or Coda would mean rebuilding your system.
- A messaging app in place of IKEA: the need is staying in touch with family and friends. You keep choosing it because the people you talk to are already on it, and an app with better features is useless if they are not there.
The improvement part is unchanged. Because the framing is about daily use, tie the Google Maps parking plan to habit as well as trip success: repeat use of parking guidance across a user's weekly driving trips is a natural secondary metric.
## 9. Variant: One Favorite Product, With Rollout as Its Own Part
Some interviewers ask about a single favorite product instead of three admired ones, in three parts: why you like it, how you would improve it, and what you would consider and measure when rolling the improvement out. There is no non-tech requirement and no explicit ask to compare with competitors.
What changes:
- Depth replaces breadth. Use the time saved on the other two picks to build one thread: why the product works, where it falls short, the fix, and the metric that proves the fix.
- Pick a product you actually use and the interviewer likely knows, so the "why" rests on your own experience rather than a feature list. Check the current version before the interview so you do not pitch something it already ships.
- A competitor comparison is optional. One or two sentences on the alternative you would otherwise use still sharpen why the product wins, but do not spend a section on it.
- Rollout is graded as its own part, so the short pilot plan in section 6 is not enough. Cover who else the change touches and what could go wrong, not just how to run the test.
Part 1 with Google Maps: use the job to be done and the reasons from section 1, then end on the honest weakness that sets up Part 2: Maps gets you to the address but not to a parking spot, and the last 200 meters is where trips still go wrong.
Part 2: the parking confidence plan in sections 2 to 4 carries over unchanged.
Part 3, rollout considerations:
1. Experiment design. Randomize eligible drivers at the user level in the pilot markets and run long enough to cover several driving trips per user. Early taps on a new parking badge overstate the effect, so read results after the novelty fades. Fix the primary metric before launch and cut results by market, trip type (commute, event, airport) and new versus returning users.
2. Data quality by market. Launch only where partner coverage and availability accuracy clear a set bar, and hide on-street likelihood where city data is weak. A wrong "spaces available" label costs trust in Maps' core navigation, not only in the new feature.
3. Driver safety. Add no new interactions while the car is moving: the parking choice happens before departure or by voice, and garage entrance guidance becomes part of the route itself.
4. Partners and neutrality. Garage and reservation partners need inventory feeds, contracts and a refund process. Rank options on the user's criteria, keep paid placement out of the ranking or label it clearly, and expect regulators and rivals to watch for self-preferencing.
5. City and traffic effects. Sending many drivers to the same garage or block can create the congestion the feature was meant to remove. Spread recommendations when one option fills, and coordinate with city transport offices in pilot markets.
6. Privacy. Where someone parks and how long they stay is sensitive location data. Use aggregated signals for availability, respect location history settings, and keep individual parking history private to the account.
7. Operations. A feature flag per market, a kill switch, dashboards for wrong-availability reports and reservation disputes, help-center articles and a support process for refunds.
Launch stages: employee testing in the pilot cities, then a small share of eligible users, then the A/B test, then market-by-market expansion where data quality passes, then broad availability.
Metrics: use the primary, secondary and guardrail metrics in section 5, with successful parking-assisted trips as the primary metric and time from arrival area to parked as the main supporting one.
Decision rule: ship a market when time-to-park falls and satisfaction rises with guardrails flat. If wrong-availability reports or disputes cross the bar in a market, pause that market and fix its data before continuing. If time-to-park does not improve after several weeks of steady use, stop expanding and revisit the hypothesis rather than adding features.
## 10. Variant: One Favorite Product, Three Enhancements
Some interviewers ask you to choose one favorite product, physical or digital, and propose three distinct enhancements to it. There is no list of three admired products, no competitor comparison, no non-tech requirement and no single-improvement roadmap. What gets graded is the quality of the three ideas and how you compare and rank them.
What changes:
- Keep "why I like it" under a minute. For Google Maps, use the job to be done and the reasons from section 1, then move straight to the users.
- Aim all three ideas at one user segment. Ideas for three unrelated groups cannot be compared on the same terms.
- Make the ideas distinct: each should solve a different pain point, not be three phases of the same feature.
- Rank them against stated criteria and finish with a recommendation. Three ideas with no ranking is only half an answer.
- Check each idea against the current version of the product before the interview. The ideas below assume none of them ships today in the form described.
Segment: drivers heading to unfamiliar destinations in dense cities, such as event-goers, travelers and people visiting a new neighborhood. They lean on Maps the most and feel it the most when a trip goes wrong near the end.
Pain points:
1. Reaching the address is not the same as being parked. Drivers circle, misjudge garage entrances, or meet unexpected prices and restrictions.
2. In an unfamiliar area, drivers cannot tell why Maps picked a route or a reroute. A route that looks odd gets ignored, and a route with many turns and lane changes causes stress and missed exits.
3. The arrival estimate stops at the address pin. On time-critical trips (a show, a flight, a meeting) drivers arrive late once parking and the walk are added.
Three enhancements:
1. Parking confidence layer. The plan in sections 3 and 4: a parking difficulty badge, garage options with price, hours, walking time and entrance routing, and reservations where partners support them.
2. Route reasons and a simpler-route option. A short reason under the chosen route and under every reroute ("avoids a closure ahead", "saves six minutes over the highway"), plus a route preference that gives up a few minutes for fewer turns and complex interchanges, offered when the driver is far from home.
3. Door-to-door arrival time. For trips with a set arrival time, an estimate that adds the predicted time to park and the walk to the entrance, and a "leave by" reminder built on that estimate rather than on drive time alone.
Prioritization: rank on reach within the segment, impact on arrival confidence, effort and risk.
| Enhancement | Reach | Impact | Effort | Risk |
|---|---|---|---|---|
| Parking confidence layer | High: nearly every driver in the segment has to park | High: removes the largest remaining pain at the end of the trip | High: partner feeds, availability data, entrance mapping | Medium: wrong availability costs trust in navigation itself |
| Route reasons and simpler route | High: nearly every driver in an unfamiliar area sees a route or a reroute | Medium: more trust and fewer ignored routes, but trip outcomes change less | Medium: reasons can come from signals routing already uses; a simpler-route option needs routing changes | Medium: vague or wrong reasons hurt trust, and extra text on the driving screen adds distraction |
| Door-to-door arrival time | Medium: time-critical trips | Medium to high for those trips | Low to medium once parking-time estimates exist, high without them | Medium: a wrong estimate makes users late, which is worse than today |
Recommendation: build the parking confidence layer first, starting with the off-street MVP in section 3. It has the highest impact for the segment, and the time-to-park data it collects is exactly what door-to-door arrival time needs, so it lowers the cost of the third idea. Door-to-door arrival time comes second, launched only in markets where parking-time predictions are accurate. Route reasons come last despite their high reach, because their effect on trip outcomes is the least certain: test demand first with reasons on reroutes only, check whether drivers follow reroutes more often, and only then build the simpler-route preference.
Metrics: for the recommended enhancement, use the primary, secondary and guardrail metrics in section 5. Give each of the other two headline metrics so they can be judged later on the same footing: the share of reroutes drivers follow for route reasons, and the gap between predicted and actual arrival at the door, plus the share of trips that arrive by the target time, for door-to-door arrival time.
Risks: the data quality, driver safety, partner neutrality, congestion and privacy points in section 9, Part 3 apply unchanged to the parking layer. The main extra risk in this version is overlap. If the three ideas blur into one feature, the interviewer cannot see a real choice, so name the pain point each one solves before you rank them.
Check in: offer to go deeper on the parking MVP, the test design, or how the door-to-door estimate would be built.