Beacon PM Case: Taking an In-App Messaging Feature From Idea to Launch

You are a product manager at Beacon. Walk through how you would take an in-app chat feature from idea to launch. ```hint Who talks to whom Before any features, pin down who would be messaging whom inside the app and what they do today instead. That answer shapes the scope, the safety work and the metrics. ``` ### Clarifying Questions - What does Beacon's app do today, and who would chat: users with each other, users with businesses or providers on the platform, or users with Beacon's support team? - What triggered the idea: requests from users, a metric problem such as people leaving the app to coordinate, or a competitor launching chat? - Are there constraints in Beacon's domain to respect, such as minors on the platform, sensitive or regulated information in messages, or rules on where data is stored? - How much engineering capacity and time is available, and is a third-party messaging provider acceptable? ### What a Strong Answer Covers - A clear picture of Beacon's product, the conversations chat would carry and the problem it solves, backed by evidence that the problem matters - A scoped first version: the core user flows, what ships and what is deferred - Build versus buy, and the technical and trust-and-safety requirements that messaging brings - Success metrics with guardrails, and an experiment design that accounts for both people in a conversation being affected - A staged rollout plan and the teams involved ### Follow-up Questions - What would you do if early data showed chat raised engagement but lowered the metric it was meant to improve? - How would you handle harassment, spam, or people using chat to move transactions off the platform? - When would you add group chat, media sharing or AI-drafted replies, and what would have to be true first?