WhatsApp Plan-Making Feature for Group Outings: Scope an MVP and Write Its PRD

You lead product for a team at WhatsApp at the end of 2021. Pandemic restrictions are easing, the new year is approaching, and friends and families are trying to meet in person again for the first time in a long while. Plenty of these get-togethers are proposed in chats, but only a small share of them ever take place. The business ask: help people make plans inside WhatsApp, starting with simple outings built around a single activity, such as going out for dinner or a movie night. Your team: - 2 backend engineers - 1 front-end engineer - 1 QA engineer - 1 product designer The team works in agile sprints and releases twice a week. You are its only product manager, so it relies on you for the vision, the specifications, the design direction and the expectations for every release. ### Clarifying Questions - Should plans work in group chats only, or also in one-to-one chats, and is there a group size the first release must support? - Is money in scope for the first release (booking tickets, splitting the bill), or does a plan end once people agree on what, when, where and who? - Must the first release ship on every WhatsApp client (Android, iPhone, web and desktop), or can one client go first? - Which markets matter most for the launch, given that some services, such as in-app payments, exist only in a few countries? ### Part 1 — Diagnose the problem and scope the feature Explain why plans made in chats so often fall through, decide which part of that problem your first release attacks, and define what is in and out of scope for a team of this size. Include the research you would run to check your diagnosis before the team starts building. ```hint Find where plans stall Trace one group outing from the first "we should meet up" message to the evening itself. Look for the step where most plans quietly die, and scope the first release around that step rather than every step. ``` #### What This Part Should Cover - A diagnosis of why chat plans fail, broken into the stages a plan moves through - A chosen target user and type of plan, with the reasoning - An explicit in-scope and out-of-scope list sized to the team, including which clients ship first - Fast research that would confirm or overturn the diagnosis ### Part 2 — Write the product requirements document Draft the PRD for the first release. It should contain the problem and goals, the research and its open questions, user stories, the features with priorities, wireframes, success metrics, action items, and the deliverables for your own team and for any other team whose help you need. Describe each wireframe in words: the screens, their key elements and how a user moves between them. ```hint Write it for the five people who build it Each requirement should be something your designer, engineers or QA engineer can act on in the next sprint. Then list what you need from teams outside your own before you can launch. ``` #### What This Part Should Cover - User stories with acceptance criteria for the person organizing and for the people invited - A prioritized feature list with a clear line between the first release and later phases - Wireframes concrete enough for the designer to start from - Metrics, a release plan that uses the twice-weekly cadence, and dependencies on other teams ### What a Strong Answer Covers - A goal of more plans that actually happen, not more plans created, and metrics that reflect it - Scope that fits two backend engineers and a single front-end engineer, with reasoning about what was cut - Respect for WhatsApp's privacy model: plan details stay end-to-end encrypted and the product cannot read chats to measure success - Risks for the period and the product: notification overload, cluttered group chats, and people's mixed comfort with meeting in person - An execution plan with owners, milestones and a staged rollout ### Follow-up Questions - The first release ships and plan creation is high, but outings do not seem to happen more often. How would you find out why? - Engineering estimates that syncing plans with phone calendars would occupy both backend engineers for a month. Does it stay in the first release? - How would you run an experiment on a feature that only works when everyone in the group has it?