Scoping onboard and ground software for NASA's eight-rotor Titan rotorcraft

Quick Overview

A product design question about defining the software for NASA's Dragonfly rotorcraft, an eight-rotor drone-like vehicle meant to search Titan for signs of life. It tests scoping a vague request, identifying users, reasoning about the limits of a distant and irreplaceable vehicle, prioritizing capabilities, and planning verification for mission-critical software.

Scoping onboard and ground software for NASA's eight-rotor Titan rotorcraft

Company: Google

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

You have just joined a company as a product manager and are placed on a client project. The client is NASA, and the work is software for its Dragonfly mission, presented here as the 2026 mission, which will look for signs of life on Saturn's moon Titan. The centrepiece of the mission is a rotorcraft: a vehicle with eight rotors that flies much like an oversized drone. You are responsible for the software for this vehicle. How would you design the product? ```hint Let the setting write the requirements List what is different from any product on Earth: distance, message delay, what a bad release would cost, and whether anyone can fix the hardware. Those differences decide what must run on the vehicle and what can stay with the team at home. ``` ### Clarifying Questions - Is the scope the software running on the rotorcraft, the ground software the mission team uses, or both? - How much autonomy does NASA expect: flying routes planned on Earth step by step, or choosing landing spots and avoiding hazards on its own? - Which groups will use the software: flight operators, scientists, engineers, or the public following the mission? - What are the current launch and arrival dates, and can new software be sent to the vehicle after launch? ### What a Strong Answer Covers - Scoping a huge request into a defined product: which software, for whom, and which mission goals it serves - Constraints unique to the setting, such as signal delay, limited bandwidth and power, no physical access, and the cost of failure - A split between onboard autonomy and ground tools, with prioritized capabilities and one critical user journey designed in depth - A verification and release approach suited to mission-critical software rather than ship-and-iterate - Success measures tied to mission and science outcomes, with risks and mitigations ### Follow-up Questions - Fresh images show an unexpected hazard near the planned landing site, and the next chance to send commands is hours away. What should the software do? - The vehicle collects far more data than the link to Earth can carry. How would you decide what is sent first? - How would you test the flight software when Titan's conditions cannot be fully reproduced on Earth?

Overview: A product design question about defining the software for NASA's Dragonfly rotorcraft, an eight-rotor drone-like vehicle meant to search Titan for signs of life. It tests scoping a vague request, identifying users, reasoning about the limits of a distant and irreplaceable vehicle, prioritizing capabilities, and planning verification for mission-critical software.

Google logo
Google
Nov 9, 2024
mediumProduct ManagerOtherProduct Design & Strategy
0
0

You have just joined a company as a product manager and are placed on a client project. The client is NASA, and the work is software for its Dragonfly mission, presented here as the 2026 mission, which will look for signs of life on Saturn's moon Titan. The centrepiece of the mission is a rotorcraft: a vehicle with eight rotors that flies much like an oversized drone. You are responsible for the software for this vehicle. How would you design the product?

Clarifying Questions Guidance

  • Is the scope the software running on the rotorcraft, the ground software the mission team uses, or both?
  • How much autonomy does NASA expect: flying routes planned on Earth step by step, or choosing landing spots and avoiding hazards on its own?
  • Which groups will use the software: flight operators, scientists, engineers, or the public following the mission?
  • What are the current launch and arrival dates, and can new software be sent to the vehicle after launch?

What a Strong Answer Covers Guidance

  • Scoping a huge request into a defined product: which software, for whom, and which mission goals it serves
  • Constraints unique to the setting, such as signal delay, limited bandwidth and power, no physical access, and the cost of failure
  • A split between onboard autonomy and ground tools, with prioritized capabilities and one critical user journey designed in depth
  • A verification and release approach suited to mission-critical software rather than ship-and-iterate
  • Success measures tied to mission and science outcomes, with risks and mitigations

Follow-up Questions Guidance

  • Fresh images show an unexpected hazard near the planned landing site, and the next chance to send commands is hours away. What should the software do?
  • The vehicle collects far more data than the link to Earth can carry. How would you decide what is sent first?
  • How would you test the flight software when Titan's conditions cannot be fully reproduced on Earth?