Prioritization Case: Choosing the Feature Scope of a Minimum Viable Product

How do you decide which features go into a minimum viable product (MVP)? ```hint Name what it must prove An MVP exists to answer a question about the product. Decide what that question is before ranking anything, then check which features the answer actually depends on. ``` ### Clarifying Questions - Is this a brand-new product, or a new capability inside a product that already has users and a brand to protect? - Is the MVP meant mainly to test whether people want the product, or to be the first version paying customers will depend on? - Which constraints are fixed: a launch date, the team's size, or legal and security requirements that cannot be skipped? - Should I illustrate the process with a specific product? ### What a Strong Answer Covers - What the MVP must prove, stated as the riskiest assumptions about the target user and their problem. - A repeatable method for cutting a long candidate list down to a minimal set, with explicit criteria and a way to rank borderline features. - Separation of features needed to test the idea from those needed for trust, safety and compliance, and from nice-to-haves that can wait or be handled manually. - Success criteria and a decision rule set before launch, and how the results shape the next iteration. - A worked example that applies the method to a concrete product. ### Follow-up Questions - An executive insists on a feature you cut from the MVP. How do you respond? - After launch, early users mostly use a feature you treated as secondary. What do you do next? - How would your approach change for an MVP released under a large, well-known brand, where a weak first version can hurt the brand?