Plan a Staged Launch of a New AI Feature at Perplexity, From Dogfood to Full Release

Perplexity has built a new feature. Explain how you would take it from a finished build to full availability for the users it is meant for. ```hint Let the risk set the pace A new feature in an answer engine can fail in ways a button change cannot: wrong answers at scale, a jump in inference cost, a bad output that spreads online. Work out what could go wrong with this feature and let that decide how many stages you need and what each must prove. ``` ### Clarifying Questions - What kind of feature is it: a change in how answers are generated, such as a new model, a new answer mode, or a capability that takes actions for the user? - Who is it for: free users, paid Pro subscribers, enterprise customers, or everyone? - Is there a fixed date to hit, such as a public announcement or a competitor launch, or can the ramp be gradual and quiet? - Is there enough inference capacity to serve all intended users at once, or does capacity limit how fast we can ramp? ### What a Strong Answer Covers - Readiness checks specific to an AI feature: offline evaluation, adversarial testing, cost and capacity planning, and a kill switch. - A staged plan from internal use to full launch, with entry and exit criteria agreed before each stage. - Success metrics and guardrails, measured with a controlled experiment during the ramp. - Go-to-market choices: which users get it first, free or paid, and how and when it is announced. - Monitoring, rollback and post-launch iteration driven by feedback on output quality. ### Follow-up Questions - Midway through the ramp, quality looks good but inference cost per query is well above plan. Do you keep ramping, and what would you change? - A competitor announces a similar feature while yours is still in beta. Do you speed up? - After full launch, a screenshot of a badly wrong output from the feature spreads on social media. What do you do in the first day?