(To view prior posts in this series, click here.)
I think I’ve mostly failed to limit product development to minimum viable product (MVP).  The essence of MVP is counter-intuitive to entrepreneurs who know what needs to be built.  MVP is downright anathema to some  wh have actually confirmed suspicions by speaking to customers, e.g. through customer development. Why limit what is built if you’ve confirmed with customers they want it all?
The problem is that the fact that customers tell you they want a feature doesn’t prove anything.  The proof is in the payment.  The more you build before you test, the more difficult is “ceteris paribus,” i.e., the need to hold “all other things being equal” in order to determine causality between product and payment.  In the real world of product development, of course, as with Economic models, one can’t truly hold all other variables constant.  But the hyperbole demonstrates an ideal and when Eric Ries’ team commits code to production every 30 minutes they are about as close to achieving that ideal as one can imagine.
Progress is progress, however.  Incremental improvement is good.
[Side note:  I’m a terrible, undisciplined programmer.  Thankfully, ’tis not my profession.  But I’ve always preferred to code small bits and test precisely because I was so poor.  I never look up syntax first and never get my code right on the first try.  The less I coded before testing, the easier to find the mistake, down to the missing ‘;.’  The more I changed before testing, the harder to find all my errors.]
Interestingly, like “having too much money” can thwart MVP, so too with outsourced development.  It can be so inexpensive that “why not build it” overrules MVP pragmatism.  In the end, I believe we’re building too much, too soon.  The CEO has justified it by believing that the product will be usable in his existing business, even if the start-up fails.  This is reasonable and I’m glad failure won’t mean he has wasted his money.  But without MVP, it’s not merely about (potentially) lost money, it’s about lost learning.
Despite my feeling of a larger “failure,” progress has been made:

• We all understand the number one objective is monetization.  (Though I continually have to persuade the principles to not give stuff away initially.)
• We use MVP terminology.  (This may sound fluffy and I suppose it is to a certain extent.  But in my view, in this case it represents a milestone in education.)
• There’s a lot we’re not building and we’re not “launching.”  We’ve successfully held at bay (so far) the strong inclination among some to:

build->alpha->beta->launch->market->sell

It sounds cliché, but in your discussions with management, board members, clients, or engineering, marketing and sales colleagues, tie activities back to objectives.  Boil business objectives down from the big picture to the incremental.
Whenever I hear all that needs to be done from these people who in all honesty, have bigger brains than I, I inevitably counter with something like:

I agree with all that; it sounds exactly right on to me.  But in reality, they’re just good guesses, right?  I think we should test them first.  What do you think?

More often than not, they’ll say “well, of course.”  Every engineering, project management, marketing, and business development plan should include phrases akin to “we believe x, y, z” and “we’re going to test x, y, z.”
Again, incremental “wins” are good progress.