First of all, is this a place where there is significant uncertainty about the feature? Lean Startup-like approaches work best under conditions of uncertainty with unproven ideas. The easiest way to get someone's hackles up is to ignore work or testing that's already been done. Sometimes people have already validated an idea and the next chunk you can learn from <i>is</i> going to take some time.<p>Once I know that they've actually just been sitting around a table writing for an imaginary user, I have three options I've used:
If the feature is clearly segment-able, I pitch it as delivering value sooner, rather than "testing". "We can build the whole feature in the same amount of time, but start making money in one month instead of 9" is a compelling proposal. And then once I've shipped part of it, I go back with the outcome of that and say, "based on what we've learned, we could improve the outcome by making these changes..." It is almost never the case that we make it through a 9 month project, because we've learned so much by then and we prioritized the most valuable parts up front, but I often don't say "MVP" at all. Frame it in terms of what it delivers to the business, not the users.<p>Second, which is useful if you don't have the power to actually structure product development, is the JAQing off approach: "How are we going to know if the project is a success? What are we measuring? That's an interesting design decision: how has that been received by customers?" The goal is to reveal the extreme uncertainty we are operating under and make the easiest solution the one where they adopt a learning mindset and iterative development. I had a CEO who used this to great effect: he never told people they <i>had</i> to build things iteratively, but he showed up to about one out of every four product reviews and if you wanted to be able to answer his questions most easily you just fell into that pattern. (His questions were always, "what are we trying to achieve?", "how will we measure if we succeeded?", "what evidence do we already have that this is worth investing in?" and "have you actually tried this with the intended user? What was the response?")<p>Alternatively, I just build user testing into the product development cycle/plan. You can have a 9 month project and still be learning along the way. Developers have to build some part first after all; it might as well be a part that you can learn from. Instead of getting management buy-in you get team buy-in, which is often easier because a series of small achievements feels good and iterative development is SWE orthodoxy. For this approach, I'd use user testing, internal customers or even just Monday demos of the current state of the feature to the team building it. If engineering already has a feature-flag framework it makes this much easier; if not, adopting the technical tools to make testing easier can also lead to more testing.