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

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.