[wpietri]

This makes me a little bonkers.

The MVP is a Lean Startup tool for exploring user needs in a startup context when the biggest risk is that you won't find product-market fit. (Which is the biggest risk for most startups.) It's a way of testing the hypothesis, "I think X is the basket of functionality needed to get users to keep using our product and get enough out of us that they'll happily pay us money."

If you're using it outside of that context, it's not an MVP. It's just a sparkling prototype. If your biggest risk is something other than product-market fit, please use a different risk mitigation strategy.

[wpietri]

Oh, and if your project hasn't explicitly thought through the risk, you may find out your biggest risk the hard way. If the team hasn't discused it, here's what I suggest:

Set up a 1-hour meeting. For the pre-reading, google a couple of articles on the kinds of risk to software projects. For the meeting, explain the goal is to find the the current top 5 risks. Open up a Google Sheet, label one column "Risk", and have everybody spend 10-15 minutes filling the column in. Then add a column called "Votes", and have everybody increment the votes counter by 1 for what they see as the top 5. Now sort by votes.

If people already agree on the top 5, great. If not, you'll need to get more consensus around the risk. One way to do that is to add two more columns called "Odds" and "Impact". (You can use H/M/L or 0-10 for most people; an especially numerate audience can use actual odd and actual cost.) Jointly fill those in, getting people to discuss why they would pick different things.

Once you have adequate consensus, move on to discussing them and how to mitigate them. Hopefully you end up with specific action items (which can include an MVP!). Then come back in 1-3 months to do it again; hopefully your big risks will go away and you'll have new risks. If you're lucky, the meeting will become unnecessary over time.

[LaundroMat]

It's not always easy for team members to openly discuss risk. The pre-mortem technique can help with that. Basically, it comes down to imagining being in a future where the project has failed miserably and asking team members to look back and identify what has gone wrong.

This framing allows people to speak more freely about their fears.

[wpietri]

Great point. I haven't tried that technique, but it sounds like a great way to get people to productively examine their fears.

[AtNightWeCode]

MVP is commonly used in agile development in the way the article talks about it. Products in the agile world are often features and not products.

[wpietri]

Ok? It's an incorrect usage. As somebody who was in on "Agile" since before it was "Agile", I'd say much of what happens in the "Agile" world is an incorrect usage. So it's no surprise to me that another term has been misappropriated.

[AtNightWeCode]

The key concept has been widely adopted by the agile community. I have encountered the problem where project managers have mixed the startup MVP concept and the agile MVP concept up though. So, I guess you have a fair point.

[wpietri]

Again, so? The "agile community" has adopted the notion of a "daily standup" where nobody actually stands up anymore. The "agile community" doing something a particular way isn't proof that they're doing it right. Indeed, given that the "agile community" these days seems to mostly consist of non-agile companies agile terms for non-agile activity, I'd argue it's evidence the other way.

[celloductor]

yes the author has taken it way out of context. imagine if auto manufacturers produced MVP vehicles without seatbelts etc.