Strengthen Meta's AR/VR Developer Platform and Weigh a Faster Third-Party Vendor

You are the product manager for the platform and developer tools that outside companies use to build AR and VR experiences on Meta's (formerly Facebook's) technology. Those developers are your direct customers, but the people who use the apps they build also matter to you. You may propose new designs for the platform and tools, not only changes to what exists today. At the companies building on the platform, the engineering leads make the technical decisions. ### Clarifying Questions - Does the platform cover VR headsets only, or also AR experiences on phones or glasses? - Which developers matter most here: large game studios, small independent teams, or companies building enterprise apps such as training? - Is the main goal to attract new developers, keep current ones, or raise the quality of apps already published? ### Part 1 — Improve the platform and tools What changes to the current platform and tools would help developers ship apps that perform better and run more reliably? ```hint Follow one failure Take a dropped frame or a crash in an end user's session and trace it back through the developer's build, test and release steps to see where the platform could have helped them catch or prevent it. ``` #### What This Part Should Cover - Developer segments compared, with one chosen and the reason - Performance and reliability pain points, ranked by how much they hurt developers and their end users - Platform or tool changes, including any new design, prioritized with explicit criteria - Success metrics that connect developer outcomes to the end-user experience ### Part 2 — Decide between the current platform and a faster vendor You come across a new platform vendor whose offering performs better than your current platform. How would you weigh the trade-offs and decide between staying with the current platform and moving to the vendor, and how would you discuss the priorities with your engineering lead, covering both the product reasoning and the execution? ```hint Fix the yardstick first Before looking at the vendor's numbers, write down what would have to be true for a switch to be worth it, including what it would cost the developers who already ship on your platform. ``` #### Clarifying Questions for this Part - Is the vendor offering a component you could build into your platform, or a complete alternative your developers would have to move to? - On which workloads and devices was the better performance measured? #### What This Part Should Cover - Decision criteria agreed before the comparison, covering more than speed - How comparable evidence on both options would be gathered - The cost and risk of the change for developers and their end users - How the discussion with the engineering lead is run, and who owns which part of the decision ### What a Strong Answer Covers - A goal that serves both developers and the people who use their apps - Part 1 priorities and the vendor decision that fit together in one roadmap - Risks for both the platform changes and the vendor decision, with ways to contain them - A plan for bringing the developers' engineering leads along, since they decide what their teams adopt ### Follow-up Questions - How would you ship a breaking SDK change without stranding apps that are already published? - If benchmarks favor the vendor but your engineering lead is uneasy about depending on an outside company for a core layer, how would you settle it? - Six months after your changes, how would you know whether developers' apps really became faster and more stable?