MVP FAQs: Feature Selection, Costs, and Best Practices for Startups
The Minimum Viable Product (MVP) remains one of the most powerful — and most misunderstood — concepts in product development. It's not about building something "minimal" in quality; it's about focusing ruthlessly on what matters most to your early customers.
Below are the questions I'm asked most frequently about MVPs — from why they matter for startups to how to select features and measure success.
Key Takeaways
MVP = smallest subset that delivers value to users as early as possible
Feature selection requires balancing user value, feasibility, and cost
Mindset: Think as a user, act as an entrepreneur
Cost savings come from building only what's needed to learn
Still relevant: The philosophy behind MVPs is timeless, even if terminology evolves
Q: Why should a startup follow the MVP approach?
I believe that startups should naturally think in terms of MVPs.
The MVP approach, if applied properly, allows startups to ship their product earlier and satisfy their early customers, by solving their core problem. This way, startups can avoid the development and operational costs of those not-yet-needed features. Startups can make better use of their limited resources, and launch features according to top priorities and needs of their target customers.
Startups need to move fast and follow truly flexible, adaptive product development patterns. The experimental nature and the limited resources of the typical early-stage startup, require laser focus and smart prioritization; which is the basis for defining a Minimum Viable Product: the MVP is all about identifying the smallest subset of the product, which can be built first to deliver value to your users, as early as possible.
The Minimum Viable Product is about what to build when – in what order; it is about learning from customers and adapting. It is perfectly aligned with a good startup strategy – it is a great beginning for a startup, a framework to balance excitement and pragmatism.
Q: How do you select features for a Minimum Viable Product (MVP)?
Feature prioritization can become quite tricky and complicated. To assign good priorities you need to combine strategic thinking, product vision, empathy, market insights and also sufficient technology understanding and domain expertise.
My strategy when prioritizing features is based on deeply understanding the problem, the impacted users, the competition and the state of the art. To prioritize wisely, I ensure that - as a product development team - we envision the ‘ideal’ state and that we are able to clearly articulate how to get there. I emphasize on the need to understand what is already available in the market, along with the opportunities and the constraints of current technologies.
I do believe that having a bold vision and the ability to ‘think big’ is critical for prioritization. If you are aware of the full potential, the ‘big picture’ of your product, prioritization gets easier and more meaningful. In fact, the more features you have to prioritize, the better the final priorities will be: when you have your ‘full product’ described at the feature level, the relative importance of each particular feature becomes more clear; while the risk of ‘opportunity cost’ – from features that you didn’t consider to build – drops. This is why I encourage the product team to define not only the obvious features, but also ‘crazy ideas’ and creative ways to solve the problem for our users.
To get the first definition of the MVP, I work closely with the product development team to ensure that each of the features in the backlog gets assessed in terms of value to the user, feasibility, and cost. This assessment process leverages all the knowledge, the signals, and the insights we have -- everything we know about the users and their pain points. The objective is to assign a single value to each product feature, reflecting its importance in solving the problem for our customers; as early and inexpensively as possible.
During this process (which could have many iterations - reviews with stakeholders and refinements), we keep ranking the backlog by ‘importance’. When the prioritization is stable enough, we draw the line separating the MVP from the rest of the backlog. This is the first definition of the MVP.
Depending on the case and the complexity of the product, I might consider additional research techniques to validate assumptions and get more detailed insights from users. Or visualization tools to provide clarity on the product backlog, the priorities and the roadmap.
Q: What’s your advice to a Product Manager for developing a successful MVP?
In short, my advice would be: Think as a user; act as an entrepreneur.
‘Thinking as a user’ implies empathy and a deep understanding of the market and customer needs. ‘Acting as an entrepreneur’ implies strategy, wise use of the available resources, and responsiveness to signals from the market – along with the right approach to balancing risk. This is the right mindset to have when defining your Minimum Viable Product and your overall product strategy.
Think as the CEO of your product - ensure that there is a solid, inspiring product vision there and that your product management team and your stakeholders deeply understand the vision and the roadmap. State your assumptions and validate them as soon as you get the right insights and data. Build a data-driven culture but also emphasize on critical thinking when interpreting your data. Make sure that your team appreciates the culture of experimentation and values how data-driven decisions can improve your product development efforts.
Use Agile engineering practices, stay connected to your customers, get ready to make pivots when there are strong signals from the market. Step back, look at the product ‘from a distance’; ask for honest feedback from people outside your domain.
Define a solid success measurement framework for your MVP. Make a small investment to build a ‘product performance dashboard’ that automatically quantifies product engagement metrics and user feedback into KPIs vs targets. Measure, interpret, react.
Q: How expensive is to develop an MVP?
Assuming there is a good definition of the MVP and also proper execution, you will avoid unnecessary costs by building only what is needed to achieve your short-term goal: to engage with your customers, cover their core needs and learn. With the MVP you are building a smaller first instance of your product; successful execution means smaller engineering/ development and operational costs.
In some cases, the MVP could even generate early revenue streams – which, depending on the business model and the stage of the startup, could prove to be important for further product development and user base growth.
Q: Is building MVPs still relevant?
I believe that the ‘MVP way’ reflects a particular approach or philosophy for building products – which should and will be there as ‘common sense’ for product development. Moreover, when building digital products in this rapidly changing technology landscape, you must constantly apply critical thinking about the definition and prioritization of product features – or you can easily get distracted and take risky paths. I strongly believe that – regardless of the actual terminology used – building ‘smaller’ and more focused products to ‘start smart’ makes perfect sense and will be there as the basis for modern product development.
Defining the right MVP is critical — too small and you don't learn enough; too large and you waste resources on unvalidated assumptions. Our advisory services help startups and corporate innovation teams: - Define MVP scope based on real customer insights - Prioritize features using proven frameworks - Build measurement systems that drive learning Explore Innovation Advisory →
Go Deeper For a comprehensive treatment of MVP methodology in the context of corporate innovation, see The Innovation Mode — covering everything from opportunity discovery through MVP definition to scaling. Learn more about The Innovation Mode →
Related Reading
The MVP Explained — A deeper dive into MVP methodology
The Product Concept — Structuring your product thinking before MVP definition
The Problem Statement - Getting clarity on the problem you're solving
60 Leaders on Innovation — Expert perspectives on product development and innovation
