Product design question

OpenAI wants an enterprise data control plane for API customers. How would you define the MVP: which personas and use cases would you serve first, which controls are table stakes at launch (for example retention, encryption, audit logs, and permissions), and what would you deliberately leave out so you can ship quickly without compromising trust?

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Whether you can scope a trust-critical enterprise MVP by identifying true table-stakes controls versus features that can wait.

Identify the first personas: enterprise IT admins and compliance or security teams provisioning API access, since they are the buyers who block deals without baseline controls.
List table-stakes controls for launch: data retention configuration, encryption at rest and in transit, audit logs of API usage and admin actions, and role-based permissions.
Validate the table-stakes list against real blocked-deal feedback from Sales, not assumption, to avoid over-building controls nobody is asking for yet.
Deliberately scope out advanced features for v1, for example granular per-project data residency or custom retention policies per team, and say why: they add complexity without unblocking the most deals.
Define the tradeoff explicitly: shipping fast with the table-stakes set versus waiting to build a fully configurable control plane, choosing speed since a baseline unblocks most deals immediately.
Set a metric to know if the MVP scope was right: percent of previously-blocked enterprise deals unblocked by the table-stakes set within the first quarter.

Grounds the table-stakes list in what actually blocks deals today (per Sales feedback) rather than a generic checklist of security features.
Explicitly separates 'must have to unblock deals' from 'nice to have for power users' and defers the second category by name.
States a concrete tradeoff: shipping the baseline fast versus a fully configurable system, and picks speed with a stated reason.
Names a measurable success signal (percent of blocked deals unblocked) to validate the MVP scope after launch.

Listing every possible enterprise control as table stakes instead of identifying the true minimum bar.
No validation against real blocked-deal data, relying on assumption about what enterprises need.
No metric for whether the MVP scope actually worked after shipping.

How would you validate the table-stakes list with real enterprise customers before building?
What would you do if audit logs alone are not enough to unblock a specific large deal?
How would you decide what to build next after the MVP ships?