Sequence a note-taking app beyond its MVP: vision, staged priorities and exit metrics

Quick Overview

A product strategy question asking a product manager to lay out the roadmap for a note-taking app that has only shipped its minimum viable product. It tests vision and segment choice, sequencing work by what the MVP has proven, transparent prioritization, stage-level success metrics and awareness of risks.

Sequence a note-taking app beyond its MVP: vision, staged priorities and exit metrics

Company: Google

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

You are the product manager for a note-taking app that has only just reached its minimum viable product. Lay out the product roadmap you would follow from here: what the product should become, what you would build in which order, and how you would decide when to move from one stage to the next. ```hint Earn each stage An MVP has proven very little yet. Let what early users actually do decide what comes next, and ask which bets only make sense once people keep coming back. ``` ### Clarifying Questions - Who uses the MVP today (students, individual professionals, small teams), and what does it already do: plain text notes only, or also sync, search and sharing? - What have we learned so far: early retention, the most requested features, the main reason people stop using it? - What is the business goal for the roadmap period: user growth, paid conversion, or proving traction before a larger investment? - How big is the team, which platforms do we support, and what time horizon should the roadmap cover? ### What a Strong Answer Covers - A vision and target segment that turn the roadmap into a strategy, with a view on how the app wins in a crowded category. - An honest read of what the MVP has and has not proven, used to order the stages (core value and retention before growth, growth before monetization). - Themes prioritized with a visible method, including what is deliberately left out. - Exit criteria and metrics for each stage, so moving on is earned rather than scheduled. - Risks and dependencies such as sync reliability, data loss and platform coverage, and how the plan changes as learning comes in. ### Follow-up Questions - Early users like the app but open it only about once a week. Does that change your roadmap? - A large customer offers a big contract if team permissions ship next quarter. How do you respond? - How would you present this roadmap differently to engineers, executives and early users?

Overview: A product strategy question asking a product manager to lay out the roadmap for a note-taking app that has only shipped its minimum viable product. It tests vision and segment choice, sequencing work by what the MVP has proven, transparent prioritization, stage-level success metrics and awareness of risks.

Google logo
Google
Feb 20, 2025
mediumProduct ManagerOtherProduct Design & Strategy
0
0

You are the product manager for a note-taking app that has only just reached its minimum viable product. Lay out the product roadmap you would follow from here: what the product should become, what you would build in which order, and how you would decide when to move from one stage to the next.

Clarifying Questions Guidance

  • Who uses the MVP today (students, individual professionals, small teams), and what does it already do: plain text notes only, or also sync, search and sharing?
  • What have we learned so far: early retention, the most requested features, the main reason people stop using it?
  • What is the business goal for the roadmap period: user growth, paid conversion, or proving traction before a larger investment?
  • How big is the team, which platforms do we support, and what time horizon should the roadmap cover?

What a Strong Answer Covers Guidance

  • A vision and target segment that turn the roadmap into a strategy, with a view on how the app wins in a crowded category.
  • An honest read of what the MVP has and has not proven, used to order the stages (core value and retention before growth, growth before monetization).
  • Themes prioritized with a visible method, including what is deliberately left out.
  • Exit criteria and metrics for each stage, so moving on is earned rather than scheduled.
  • Risks and dependencies such as sync reliability, data loss and platform coverage, and how the plan changes as learning comes in.

Follow-up Questions Guidance

  • Early users like the app but open it only about once a week. Does that change your roadmap?
  • A large customer offers a big contract if team permissions ship next quarter. How do you respond?
  • How would you present this roadmap differently to engineers, executives and early users?