[j45]

Disagree. Absolutely possible.

I currently build MVP's, in 30-90 days if it can be pushed that fast. I'm a lean practitioner for over 10 years starting in manufacturing.

You want to help your MVP's become long term customers by helping them grow and make money. If they don't get this, it's a real risk to their business, let alone your relationship with them.

For MVP's: You have to invest in understanding your tools and how long it will take to identify and build only the features that customers can't live without.

My original consulting business is for established businesses, but they were all smaller 4-7 years ago.

[iktorn]

"build only the features that customers can't live without" - who makes this call? What if you disagree on this? What if the customer learns something new after 2 weeks and needs to change the scope?

[j45]

Who makes the call?

If it's truly a lean MVP, the end user/paying customer. Is it an MVP is if no one is getting out of the building and talking to customers/users before designing or writing a line of code?

Completing the problem solution fit, product market fit, and engaging in customer development prior to writing a line of code has to happen if we are wanting to be honest when using a term like MVP.

If you feel this is a binary issue: ultimately the person signing the cheques make the call, and you have a choice on whether to accept said cheque for managing said potential headache.

The grey area in between:

If the customer wants to do whatever they do and call it an MVP by sprinkling the lean dust on it to justify it, you have to recognize it for what it is and either adjust your approach, or decide if that kind of work is something you can live with. No process can correct development pagentry, management/design by committee, and failing to get out of the building.

Building an MVP requires getting through the build - measure - learn loop as quickly as possible.

Interrupting you mid-cycle if it's that ground breaking (customers are saying I'm trying to find a way to give you money) requires answering "Did we really understand anything before hallucinating an MVP ourselves"?

It leaves a few options:

- Change the scope

- Change the deadline

- Change the budget

- Trade features -- something that was important can no longer be important as a result of what was traded.

Avoiding this is the business skills development we all constantly need that I mention to in my initial post.

For me, I try to make sure I understand, and the customer understands why we're doing the things we want first and hopefully minimize the above.

I don't rush customers into building something, but rather rush into understanding what our experiment is, and why we're testing those things. It helps create a checklist to test our assumptions/discoveries against when the next great insight comes in.

[kubaf]

Dont you think that what you are describing sounds like a huge overhead. Rather then tweaking the product you have to "trade features" with customer.

It's also something that is very difficult to scale. It's hard to expect that every person who is good on the job is also good in negotiating with customers.

[j45]

Project management is a real part of software development.

I make no statements about whether the developer should do the project management -- only when a good process happens, results are good.

The developers who can manage a process that they're a part of is a skill that we should all aspire to, though, because people aren't hiring us for just our technical prowess, but rather, our ability to interface those skills to finding and completing business goals.

I do agree that avoiding the scope changes while doing an iteration is essential, and can be often lessened or deferred until the next .. sprint.