In a **TikTok platform Product Manager** interview, explain how product requirements are generated and how you prioritize competing work for a platform product with many internal stakeholders and limited engineering capacity. ### Constraints & Assumptions - Requirements should not come only from the loudest stakeholder. - Platform users may include internal operations, creators, advertisers, analysts, or other product teams. - Prioritization should balance business impact, user pain, technical constraints, reliability, compliance, and long-term leverage. - Communicate tradeoffs clearly when requests are deferred. ### Clarifying Questions to Ask - Who are the platform users and stakeholders? - What company OKR or product goal is the roadmap supporting? - What constraints exist around engineering capacity, reliability, compliance, or migration work? - Are requests mostly new features, operational tooling, risk work, or infrastructure improvements? ### Part 1 - Identify Where Requirements Come From Where do product requirements come from? #### What This Part Should Cover - Company strategy and OKRs, user research, product data, stakeholder requests, operational pain, technical debt, reliability, compliance, and risk. - Validation of whether a request reflects a repeatable platform need or a one-off ask. ### Part 2 - Evaluate Incoming Requests How do you evaluate requests from different stakeholders? #### What This Part Should Cover - Clarifying the requester, user problem, frequency, current workaround, metric affected, urgency, and risk. - Translating feature requests into comparable problem statements. - Evidence gathering before committing roadmap capacity. ### Part 3 - Prioritize With Limited Resources How do you prioritize features or platform improvements? #### What This Part Should Cover - RICE or weighted scoring adapted for platform work. - Platform-specific factors such as reusability, reliability, compliance risk, scalability, and architectural leverage. - Clear categories such as must-do now, MVP later, not now, or manual workaround. ### Part 4 - Explain Tradeoffs And Measure Success How do you explain priorities and measure whether the chosen work succeeded? #### What This Part Should Cover - Communication of business goal, impacted users, expected metric movement, engineering cost, and deferred work. - Stakeholder management when senior or loud requests are deprioritized. - Metrics such as adoption, task completion time, error rate, SLA, throughput, satisfaction, support tickets, and reliability. ### What a Strong Answer Covers - Shows a repeatable intake and prioritization process. - Balances short-term stakeholder needs with long-term platform health. - Makes opportunity cost visible. - Measures outcomes after launch rather than only shipping features. ### Follow-up Questions - What if a senior stakeholder pushes for a low-impact request? - How would you prioritize technical debt against visible feature work? - What if two teams disagree on the same platform capability? - How do you avoid building one-off custom tools? - How would you define success for an internal platform feature?