Product design for shared cab rides booked and split inside a chat app

Quick Overview

Design a cab-sharing service built into a chat application rather than a separate ride app. The prompt tests choosing a goal and user segment, reusing chat features such as groups, live location and payments, prioritizing a minimum viable version, and defining safety-aware success metrics.

Product design for shared cab rides booked and split inside a chat app

Company: Microsoft

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

Design a cab-sharing service that is built into a chat application instead of being shipped as a separate app. Explain which kind of chat app you are designing for and what goal the feature should serve, which users you would focus on and what problems they have, which features you would build first and why, and how you would know it is working. ```hint Start from what chat adds Ride-hailing apps already handle booking well. Ask what a chat app knows or does that they cannot: who is making plans together, where those plans get made, and how people already share locations there. Let that choose your segment and your first feature. ``` ### Clarifying Questions - Is the chat app a consumer messenger used by friends and family, or a workplace tool such as Microsoft Teams? - Does "cab-sharing" mean booking a cab from inside a chat, or several people splitting one ride and its fare, and are the riders people who already know each other or strangers going the same way? - Would the service run its own driver marketplace or partner with existing ride-hailing providers? - Which markets come first, given that ride regulation and payment options differ by country? ### What a Strong Answer Covers - A stated goal for the feature (engagement, revenue or acquisition) and an interpretation of "cab-sharing" justified by what a chat app uniquely enables - A chosen user segment with concrete pain points in arranging, following and paying for a shared ride - Features that reuse chat building blocks (groups, live location, payments, notifications), prioritized into a minimum viable version - Rider safety and location privacy, plus the build-or-partner decision for drivers and vehicles - Success metrics with a clear primary metric, a booking funnel and guardrails that protect the chat experience ### Follow-up Questions - How would the design change if riders could share a cab with strangers who are not in their contacts? - How would you keep ride updates from annoying members of a large group chat who are not riding? - What would it take to make the driver side work, and would you build it yourself?

Overview: Design a cab-sharing service built into a chat application rather than a separate ride app. The prompt tests choosing a goal and user segment, reusing chat features such as groups, live location and payments, prioritizing a minimum viable version, and defining safety-aware success metrics.

Microsoft logo
Microsoft
Mar 21, 2026
mediumProduct ManagerOtherProduct Design & Strategy
0
0

Design a cab-sharing service that is built into a chat application instead of being shipped as a separate app. Explain which kind of chat app you are designing for and what goal the feature should serve, which users you would focus on and what problems they have, which features you would build first and why, and how you would know it is working.

Clarifying Questions Guidance

  • Is the chat app a consumer messenger used by friends and family, or a workplace tool such as Microsoft Teams?
  • Does "cab-sharing" mean booking a cab from inside a chat, or several people splitting one ride and its fare, and are the riders people who already know each other or strangers going the same way?
  • Would the service run its own driver marketplace or partner with existing ride-hailing providers?
  • Which markets come first, given that ride regulation and payment options differ by country?

What a Strong Answer Covers Guidance

  • A stated goal for the feature (engagement, revenue or acquisition) and an interpretation of "cab-sharing" justified by what a chat app uniquely enables
  • A chosen user segment with concrete pain points in arranging, following and paying for a shared ride
  • Features that reuse chat building blocks (groups, live location, payments, notifications), prioritized into a minimum viable version
  • Rider safety and location privacy, plus the build-or-partner decision for drivers and vehicles
  • Success metrics with a clear primary metric, a booking funnel and guardrails that protect the chat experience

Follow-up Questions Guidance

  • How would the design change if riders could share a cab with strangers who are not in their contacts?
  • How would you keep ride updates from annoying members of a large group chat who are not riding?
  • What would it take to make the driver side work, and would you build it yourself?