Google Docs · Execution · Mid · 60 to 90 minutes

Google Docs launch cut plan for Review Queue

Google Docs is a cloud based document editor where people write, share, and collaborate in real time across web and mobile. Answer this product management case and get it graded line by line against a weighted rubric.

Prioritisation
Execution planning
Stakeholder communication
Risk management
Metric design

The situation

Google Docs already supports live co-editing, comments, suggestion mode, @mentions, and basic assigned action items. At a recent Google keynote, your VP previewed a hypothetical new Docs collaboration feature called Review Queue, a sidebar that groups unresolved comments, assigned action items, and @mention requests into one place, with optional due dates and reminder nudges. You own this product area. Today, engineering says the feature is about three weeks behind plan because notification logic, permission edge cases, and accessibility work are taking longer than expected. There are four weeks left before the launch window shared with Sales, Support, and large Workspace customers. Assume the following numbers: 31 percent of weekly active Docs users leave or resolve comments, 8 percent use assigned action items each month, and review coordination issues drive about 14 percent of Docs enterprise support tickets. Leadership wants to avoid backing away from a public promise, but trust in Docs collaboration is more important than shipping a confusing or unreliable experience. Your director has asked you to recommend what should still launch, what should be cut or delayed, and how to communicate the decision internally and externally.

What to produce

A 1 to 2 page execution memo.

Your answer must

State your recommended launch scope for Review Queue, including what must ship, what should be cut, and what should be delayed.
Show the prioritisation criteria you used, with explicit trade-offs across user value, reliability risk, reputational risk, and dependency risk.
Include a four week execution plan with at least two go or no go checkpoints and a fallback if blockers remain.
Define 2 to 4 success metrics and 2 to 3 guardrail metrics for the first 30 to 90 days after launch.
Outline an internal and external communication plan that covers leadership, Sales, Support, and users or admins.

Constraints

There are four weeks left before the committed launch window.
No extra headcount or budget is available. The current team is 6 web engineers, 1 designer, and shared QA.
The mobile clients and shared notifications team can only take blocker fixes before launch, not new feature work.
The release must meet Workspace accessibility, privacy, and admin control requirements.

Format

Use clear sections such as recommendation, scope cuts, rationale, execution plan, metrics, and communications. A simple table for must ship, cut, and defer decisions is encouraged.