Cruise: Define a First Flying-Car Release and Speed Up an Engineering Workflow

This prompt comes from a product manager interview at Cruise, a company that develops self-driving cars. It sets two tasks: create a minimum viable product (MVP) for flying cars, and optimize a workflow for Cruise's engineers. The prompt gives no more detail, so you decide how to scope each task. ### Clarifying Questions - Does "flying car" mean a vehicle that both drives on roads and flies, or a small electric aircraft that takes off and lands vertically and carries a few people over short hops? - Should the MVP build on Cruise's self-driving technology, and should it carry passengers, goods or both? - Are the two tasks connected: is the workflow the one Cruise's engineers would use to build the flying-car MVP, or one in today's self-driving car development? ### Part 1 — A first version of a flying-car product Decide whom the first flying-car product serves and for what trip, what the smallest version that tests the core value looks like, and what it deliberately leaves out. ```hint Demand risk versus vehicle risk List the assumptions that must hold for flying cars to succeed, then separate those about whether people want it from those about the vehicle and its approval. Ask which of them a first version can test safely, and how early. ``` #### What This Part Should Cover - A chosen user, trip type and location, with why it suits a first version better than the alternatives - The riskiest assumptions and an MVP scoped to test them, including what is out of scope - How safety, certification and landing infrastructure shape the MVP - Success criteria that decide whether to keep investing ### Part 2 — Optimize a workflow for Cruise's engineers Choose one workflow that engineers building self-driving vehicles go through, find where it is slow or error-prone, and propose how you would improve it. ```hint Follow one issue end to end Trace a single problem from the moment it is noticed in testing until a fix is validated and released. Mark where work waits, and on whom. ``` #### Clarifying Questions for this Part - Which engineers should the workflow serve: autonomy software engineers, simulation and testing teams, hardware engineers, or the people who run the test fleet? #### What This Part Should Cover - A chosen engineering persona and workflow, mapped step by step with its bottlenecks - Improvements prioritized by the delays or errors they remove - Metrics for engineering speed paired with safety and quality guardrails ### What a Strong Answer Covers - An explicit interpretation of a terse, two-part prompt and a stated view of how the two parts relate - Safety as a gate in both parts, never traded away for speed - MVP thinking adapted to a regulated, hardware-heavy product: what can be learned before the final vehicle exists - Clear prioritization and trade-offs in each part ### Follow-up Questions - If passenger flights could not be approved for several years, what would you ship in the first year, and how would you know it was worth continuing? - How does your workflow change once the vehicle flies instead of drives, when every real-world test is costlier and riskier? - Engineers want faster iteration and the safety team wants more validation. How does your workflow resolve that tension?