Reflections on a movement | Eric Ries (creator of the Lean Startup methodology)

Ries says an MVP is not a specific cheap-product tactic. Start with what you believe and choose an efficient way to learn whether it is true. The needed test changes with the hypothesis, customer and market.

He rejects the idea that minimum means a broken or deliberately poor product. If customers require a high standard, test one critical feature at that standard rather than every possible feature. His long-development examples are his account, not a universal timeline.

Ries describes moving from arguing with customers to taking notes on missing capabilities. Requests you never anticipated can be more informative than praise for your planned roadmap. Listen to the feedback as evidence without assuming every request must become a feature.

He distinguishes putting a product in front of a small customer group from announcing it widely. That can limit exposure while the team learns. It does not remove safety, legal or honest-disclosure duties, particularly in the high-stakes industries he mentions.

He says difficulty choosing an MVP often starts upstream with an unclear learning question. Identify the assumption and what evidence would inform it before listing features. His cut-the-list heuristic challenges excess scope; it is not an instruction to remove essential safeguards.

He gives an example where a technical signup problem could be mistaken for rejection of the value proposition. A result needs diagnosis, not a story attached immediately afterward. He argues for repeated learning rather than treating one experiment as conclusive.

Ries values doing one thing extraordinarily well, but asks whose definition of quality the work serves. Good engineering can preserve options and speed rather than oppose learning. A commitment to craft should not become an excuse to avoid customer feedback.