You deliver with the minimum you can get away with then improve from actual feedbacks, requests and data gathered from usage.
What people think they will want differs from what people will actually want which is not necessarily what data shows you should build. Build fast, improve incrementally.
The path highlighted in the article is exactly how you should not build a product. Don’t focus on all the things you could add, streamline your ideas as much as you can.
You're right - I think this is the only real way out of the dilemma. There are still some challenges with this approach, though:
* stakeholders often need or think they need a whole estimate up front. A developer may explain MVPs, sprints, agile, etc. and still get blank stares and "ok, that sounds good, but just give us a rough estimate how long will it take/how much will it cost. We promise not to hold you to it (yeah right)". In some examples, like governmental budgeting, etc. it can be hard to even proceed through purchasing without a whole-product estimate.
* developers can be seen as over simplifying by stakeholders who don't understand the approach. When presented with a MVP, they start complaining about the fonts, etc. and loose faith in proceeding.
* developers can be seen as over complicating by stakeholders who don't understand the approach. When a stakeholder's simple request for "just an app to capture urls" balloons into a major project with bells and whistles over 10 weeks of dev cycles, management steps in and says "I thought this was just supposed to be a simple app to capture urls".
The later two come down to developers communicating effectively and stakeholders truly understanding their staff and processes. The first, I honestly haven't found a great fix for. No matter how I explain, many customers generally want an estimate and budget I stick to.
What people think they will want differs from what people will actually want which is not necessarily what data shows you should build. Build fast, improve incrementally.
The path highlighted in the article is exactly how you should not build a product. Don’t focus on all the things you could add, streamline your ideas as much as you can.