Improve how Google Docs tracks, compares and restores earlier document versions

Quick Overview

A product sense question asking a PM candidate how to improve version history in Google Docs. It tests choosing a collaborator segment, spotting pain points in finding, comparing and restoring earlier versions, prioritizing fixes, and setting success metrics with guardrails.

Improve how Google Docs tracks, compares and restores earlier document versions

Company: Google

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

You are a product manager on Google Docs. The interviewer asks how you would improve its version control: the part of the product that keeps earlier states of a document and lets people look back at them, see what changed, and return to an earlier state. Decide whom you are improving it for, explain what goes wrong for them today, and propose and prioritize improvements. ```hint Why people open the history Nobody browses old versions for fun. List the concrete situations that send someone into a document's past, and ask what they are trying to find, understand or undo in each one. ``` ### Clarifying Questions - Which users should the improvement target: individual writers, teams editing the same document at once, or organizations with formal review and record-keeping needs such as legal or policy teams? - Is the goal fewer incidents of lost or overwritten work, faster reviews, or winning workplace customers who still keep their "official" drafts in desktop files with tracked changes? - Should the scope stay within Docs, or may the change carry over to Sheets and Slides, which keep a similar history? - Are there constraints to respect, such as the storage cost of keeping more snapshots or keeping the editor simple for casual users? ### What a Strong Answer Covers - A chosen user segment and the specific moments when they need history: recovering deleted text, finding who changed a passage, checking what changed before signing off. - Pain points grounded in how history works today, such as locating the right version among many automatic saves, comparing two points in time, and restoring part of a document instead of all of it. - Several solutions with a prioritization that weighs impact on the chosen segment, effort, and the risk of cluttering a simple editor. - Success metrics tied to the chosen problem, plus at least one guardrail. - Risks specific to multi-person editing, such as one person's restore wiping out a collaborator's newer work. ### Follow-up Questions - Your top idea restores one section from an old version. What should happen when a collaborator has edited that same section since then? - Opens of the history panel climb sharply after your launch. Is that good or bad news, and how would you tell? - How would your plan change for an administrator who must preserve every version of certain documents for legal reasons?

Overview: A product sense question asking a PM candidate how to improve version history in Google Docs. It tests choosing a collaborator segment, spotting pain points in finding, comparing and restoring earlier versions, prioritizing fixes, and setting success metrics with guardrails.

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

You are a product manager on Google Docs. The interviewer asks how you would improve its version control: the part of the product that keeps earlier states of a document and lets people look back at them, see what changed, and return to an earlier state. Decide whom you are improving it for, explain what goes wrong for them today, and propose and prioritize improvements.

Clarifying Questions Guidance

  • Which users should the improvement target: individual writers, teams editing the same document at once, or organizations with formal review and record-keeping needs such as legal or policy teams?
  • Is the goal fewer incidents of lost or overwritten work, faster reviews, or winning workplace customers who still keep their "official" drafts in desktop files with tracked changes?
  • Should the scope stay within Docs, or may the change carry over to Sheets and Slides, which keep a similar history?
  • Are there constraints to respect, such as the storage cost of keeping more snapshots or keeping the editor simple for casual users?

What a Strong Answer Covers Guidance

  • A chosen user segment and the specific moments when they need history: recovering deleted text, finding who changed a passage, checking what changed before signing off.
  • Pain points grounded in how history works today, such as locating the right version among many automatic saves, comparing two points in time, and restoring part of a document instead of all of it.
  • Several solutions with a prioritization that weighs impact on the chosen segment, effort, and the risk of cluttering a simple editor.
  • Success metrics tied to the chosen problem, plus at least one guardrail.
  • Risks specific to multi-person editing, such as one person's restore wiping out a collaborator's newer work.

Follow-up Questions Guidance

  • Your top idea restores one section from an old version. What should happen when a collaborator has edited that same section since then?
  • Opens of the history panel climb sharply after your launch. Is that good or bad news, and how would you tell?
  • How would your plan change for an administrator who must preserve every version of certain documents for legal reasons?