Pitch a Fresh Use Case for a Connected Smart Device: Users, First Version and Metrics

Quick Overview

A product strategy question from a Google product manager interview: choose a connected smart device and propose a new use case for it. It tests choosing a user segment with an unmet need, explaining why the device serves it better than a phone app, scoping a focused first version, and setting success metrics with privacy guardrails.

Pitch a Fresh Use Case for a Connected Smart Device: Users, First Version and Metrics

Company: Google

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

An interviewer asks you to propose a new use case for a smart product. Choose a connected device, then explain who the new use case would serve and what problem it solves for them, how it would work, what the first version would include, and how you would judge whether it succeeded. ```hint Let the device earn the job Ask what this device can do that a phone app cannot: where it sits, what it can sense, and who is near it through the day. If any phone app could serve the use case just as well, keep looking. ``` ### Clarifying Questions - Is any connected device in scope, or should I pick one Google already sells, such as a Nest speaker or display, a Pixel Watch or a Nest thermostat? - Does "new use case" mean a new job for the device's existing hardware, or may I propose added sensors or accessories? - What should the use case mainly achieve: more daily use by current owners, a reason for people who don't own the device to buy one, or new subscription revenue? ### What a Strong Answer Covers - A deliberate choice of device, grounded in what it can already sense and do and in how people mostly use it today. - A specific user segment and unmet need, with a clear reason this device serves it better than a phone app or a dedicated gadget. - A few candidate use cases compared on stated criteria, then one developed into a concrete flow and a focused first version. - Success metrics with guardrails, a business model, and the main risks, especially privacy, consent and false alerts when the device watches for something. ### Follow-up Questions - If your use case relies on the device noticing that something is unusual, how would you trade missed events against false alarms, and who decides the threshold? - How would you test demand for this use case before committing engineering time to it? - Should the use case be free with the device or part of a paid plan, and what evidence would change your mind?

Overview: A product strategy question from a Google product manager interview: choose a connected smart device and propose a new use case for it. It tests choosing a user segment with an unmet need, explaining why the device serves it better than a phone app, scoping a focused first version, and setting success metrics with privacy guardrails.

Google logo
Google
Apr 11, 2025
mediumProduct ManagerOtherProduct Design & Strategy
0
0

An interviewer asks you to propose a new use case for a smart product. Choose a connected device, then explain who the new use case would serve and what problem it solves for them, how it would work, what the first version would include, and how you would judge whether it succeeded.

Clarifying Questions Guidance

  • Is any connected device in scope, or should I pick one Google already sells, such as a Nest speaker or display, a Pixel Watch or a Nest thermostat?
  • Does "new use case" mean a new job for the device's existing hardware, or may I propose added sensors or accessories?
  • What should the use case mainly achieve: more daily use by current owners, a reason for people who don't own the device to buy one, or new subscription revenue?

What a Strong Answer Covers Guidance

  • A deliberate choice of device, grounded in what it can already sense and do and in how people mostly use it today.
  • A specific user segment and unmet need, with a clear reason this device serves it better than a phone app or a dedicated gadget.
  • A few candidate use cases compared on stated criteria, then one developed into a concrete flow and a focused first version.
  • Success metrics with guardrails, a business model, and the main risks, especially privacy, consent and false alerts when the device watches for something.

Follow-up Questions Guidance

  • If your use case relies on the device noticing that something is unusual, how would you trade missed events against false alarms, and who decides the threshold?
  • How would you test demand for this use case before committing engineering time to it?
  • Should the use case be free with the device or part of a paid plan, and what evidence would change your mind?