Please login or join to subscribe to this thread
I admit I have a concern with this approach to project delivery. My goal has always been to provide the best possible solution (BPS?) within the constraints provided (budget, time and site conditions) rather than minimum viable.
Much like buying a car. If I tell the dealer I want a vehicle to provide reliable transportation from A to B for a family of five and am prepared to pay $40,000, I don't expect to be offered a $5,000 van from the used lot as "minimum viable". I expect best available for my budget.
I love the concept of MVP. The problem is in explaining to people that it doesn't mean bare-bones. That's an unfortunate side-effect of using adjectives such as "minimal" and "viable". It can be somewhat helpful to change "viable" to "valuable". Plus, it doesn't change the acronym.
Good question. In the context of software development I try to avoid attaching too much significance to a MVP or v1 wherever possible. I find it's more important that iterations deliver a *potentially* releasable, production quality product. The points at which releases happen then become mainly a matter of customer relations and practicality. Crucially the decision can be taken when the product looks good enough rather becoming hostage to an early and unreliable forecast.
If the user base is expected to be very different after go live than before it then ensuring useful, relevant customer feedback from v1 is going to be important. I guess that's what you are thinking of when you refer to "lost momentum". I don't think there is any one right answer here. However, people generally are amenable to incremental releases of technology. Continuous product improvement is familiar to people in both their professional and personal lives - so version 1 perhaps isn't such a big deal as in the past.
With all respect to Peter, software products are rarely like buying a car and tend to be much more like buying a service. The acceptable threshold on day 1 may be lower if people expect and can see evidence of the service getting better each day thereafter.
I think it is important to understand that an MVP is an experiment designed to answer a question about product/business viability. As such, it does NOT need to be a v1. That would be an MMR (if we are talking about a commercial product) or an MBI (if we are talking about an internal enhancement or replacement of an existing solution).
If one understands the purpose of an MVP and has effectively educated stakeholders who don't try to make it more than it should be, it is a great strategy.
I always point to Zappos.com's startup as a good example of the MVP approach.
This is a great concept especially when you work with new technology that stakeholders are not that familiar with or you have open work packages that needs to be progressively elaborated. It's better to have v1 deployed & allow end users to have hands on experience with the product/service. This exposure helps to prioritize the best enhancements that can be done to v1 to make it better suited to business processes.
Saves plenty of time at planning. You no longer need to plan out every detail or enhancement at the start but can rather relase v1 & progressively improve on it in multiple iterations while completely exploiting the know how gained from using v1 as a BAU business activity
MVP is great to ensure you get to market before your competition BUT then we need to acknowledge and include the customer. Sound obvious? Well from my experience not so much. We often neglect to understand the customer journey i.e. from a software viewpoint we develop for developers. I've had cases where MVP included the ability to add new records but not the ability to delete them. Sure that will come is always the response but as we know in an Agile backlog we often find something with a higher priority.
Thank you all for your valuable comments - yes it is true there is no ''one-size fits all'' nor any approach is risk free. good luck with your en devours - cheers
I had been using it for a while and my experience with it was awesome!
I mainly use it to get a simple version of the product out into the hands of the users and make sure that my team was on the right track. We used the MVP to gather feedback, study them, and improve our next iteration of the product.
This is so especially if the users are venturing into a new area, and not really knowing what they need or want in the product. In this way, many issues and needed changes can be identified before we used up all the budget and timeline in developing the ‘perfect product”, only to find that it did not meet all the user's needs.
from my perspective, whole lot of companies do consider MVP, when launching new services & products. also pertinent during covid-19 situations, given funding/resource challenges.
but MVP to me must be usable, functional etc. & not simply a prototype.
in principle PMI organisation is also using MVP concept - as per the attached document, which is publicly available
any more inputs on MVP especially published guidelines etc.. most welcome !
Please login or join to reply