Minimum Viable Products for Enterprises

The page brings together several views on minimum viable products in enterprise software. It says lean startup uses MVPs to learn about customers with limited effort and money, but enterprises often struggle to define what counts as viable. It also notes that enterprise teams try to test hypotheses early, while still needing to account for features, revenue, and business needs.

Reading notes

#

• MVPs are meant to help teams learn about customers with limited effort and money.
• Lean startup aims to get user feedback, do user testing, and see whether people will use and pay for the product during development.
• Enterprise teams often find it hard to define the point at which a product becomes viable.
• Traditional enterprise development is described as inefficient because it tries to build the perfect product before release.
• Development teams are said to focus on MVPs so they can test hypotheses and let the product evolve gradually.
• In enterprise settings, a product can be viable when it has just enough features to start selling.
• Enterprise software differs from consumer software because the user of the MVP is often not the final buyer.
• That separation makes feedback harder to interpret, so teams need to filter noise from useful input.
• Enterprise buying decisions are often shaped by an overfeature culture, where more features are linked with robustness and enterprise readiness.
• One example describes using an MVP in a complex enterprise initiative to manage risk as stakeholder patience could run out.
• The text also distinguishes a minimum viable product from a minimum desirable product, which adds more scope and features in later iterations.
• A suggested step is to limit interdependent features in the MVP and keep the focus on viability.