The “Must Have, Should Have, Nice to Have” framework is often used to determine essential features in product development. While it can help identify priorities, for experienced product managers, it can actually work against the core principles of MVP thinking.
The issue lies in how the word “should” warps your mindset. As soon as you label a feature as “Should Have,” you stop thinking about viability and start compromising. This creates a mental narrative where the feature feels necessary, but you can’t include it because you’re trying to keep things minimal. This approach shifts the focus away from what’s necessary for learning and testing, and toward what feels like a reluctant omission.
Instead, shift your mindset. Start from zero, assuming your users currently have nothing. As you layer on user stories and functionality, ask yourself: “Now, does the user have a product that solves a real problem? Will they use it? Would they pay for it? Is it viable?”
The point at which you feel yourself starting to say yes—and possibly even when you’re on the tipping point between yes and no—is a great place to hone in on the MVP. That tipping point is where you’ve provided enough value to learn from real-world feedback without overbuilding.
To move from mindset into action, focus on building just enough to test your core hypothesis—nothing more. The MVP should be a tool for validating assumptions, not perfecting the product.
In the end, MVP thinking isn’t about what you can live without—it’s about what you can learn with. The faster you cut through the noise of “should” and “nice,” the quicker you’ll deliver real value and actionable insights for your product.
The issue lies in how the word “should” warps your mindset. As soon as you label a feature as “Should Have,” you stop thinking about viability and start compromising. This creates a mental narrative where the feature feels necessary, but you can’t include it because you’re trying to keep things minimal. This approach shifts the focus away from what’s necessary for learning and testing, and toward what feels like a reluctant omission.
Instead, shift your mindset. Start from zero, assuming your users currently have nothing. As you layer on user stories and functionality, ask yourself: “Now, does the user have a product that solves a real problem? Will they use it? Would they pay for it? Is it viable?”
The point at which you feel yourself starting to say yes—and possibly even when you’re on the tipping point between yes and no—is a great place to hone in on the MVP. That tipping point is where you’ve provided enough value to learn from real-world feedback without overbuilding.
To move from mindset into action, focus on building just enough to test your core hypothesis—nothing more. The MVP should be a tool for validating assumptions, not perfecting the product.
In the end, MVP thinking isn’t about what you can live without—it’s about what you can learn with. The faster you cut through the noise of “should” and “nice,” the quicker you’ll deliver real value and actionable insights for your product.