Scheduling App Product Design in 15 Minutes: Use Cases, Differentiators, Block Diagram

You are interviewing for a product manager role and have 15 minutes to design an app for time management, described as a "universal" calendar. The interviewer wants the answer in three steps: first the high-level use cases, then the features that would differentiate the app, and finally a block diagram of the system behind it. ### Clarifying Questions - What should "universal" mean here: one calendar that combines work, personal and other accounts from different providers, an app that works the same on every device, or a single place for both events and to-dos? - Is this a new standalone app or part of an existing productivity suite, and which users should it serve first? - How detailed should the block diagram be in the time available: main components and data flows, or storage and API choices as well? - May the app read and write calendars held by other providers through their public interfaces, once the user grants permission? ### Part 1 — High-level use cases Name the main situations in which people would use this app, choose the user segment to design for first, and rank the use cases that matter most to that segment. ```hint Moments of need Think about the moments someone reaches for a calendar: agreeing on a time with others, checking what comes next, protecting time for focused work. Which of these break down when a person's commitments are spread across more than one place? ``` #### What This Part Should Cover - A primary user segment, picked with a reason rather than "everyone". - Use cases grouped by the job the user is doing, not by screens. - A ranking of use cases tied to that segment's biggest pain. ### Part 2 — Differentiating features Every phone and email suite already ships a calendar. Propose the features that would make your chosen users adopt this one, and say which feature you would build first. ```hint Look for manual workarounds Ask what people currently do by hand because no single calendar handles it, such as copying events between accounts or trading messages to find a free slot. ``` #### What This Part Should Cover - Features traced to the pain points from Part 1, not a generic wishlist. - A first feature chosen on value, effort and how hard it is for incumbents to copy. - A signal that would show each differentiator is working. ### Part 3 — Block diagram Draw a block diagram of the system: the client apps, backend services, storage and outside integrations. Explain how an event created or changed in one place reaches every other place it should appear, and how reminders get to the user on time. ```hint Follow one meeting Trace a single meeting from the moment it is created on one device to the moment its reminder fires on another. Each hand-off along the way is a candidate block. ``` #### What This Part Should Cover - The main components and what each is responsible for. - The synchronization path across devices and outside calendars, including offline edits and conflicts. - Reliability of sync and reminders: failures, retries and how the user learns something is out of date. - How account permissions and sensitive calendar details are protected. ### What a Strong Answer Covers - Use of the 15 minutes: every part gets airtime, with the most depth where the differentiator lives. - A clear thread from segment to pain point to differentiator to the blocks that make it possible. - Named trade-offs, such as how fresh synced data must be versus battery, cost and provider limits. - Success metrics for the app, with at least one guardrail. ### Follow-up Questions - A user's employer blocks third-party apps from reading the work calendar. How does the product behave, and what happens to your main differentiator? - The user is invited to the same meeting on two connected accounts. How do you avoid showing it twice? - After launch, which single metric would tell you the app helps people manage their time rather than just display their events?