There is a concept in technology projects and for product releases as well, called the “M.V.P.,” or Minimum Viable Product. This idea is one you see frequently when project teams are using Agile methodology, and allows a smaller piece of finished work to be released to the customer in the hopes of gaining feedback. This feedback is used as the foundation for the next stages and to make sure the user experience and expectations align to the project milestones. This validates the project direction, identifies valued functionality, and can result in rethinking or reprioritizing upcoming features.
According to the Scaled Agile Framework, “In the context of SAFe, an MVP is an early and minimal version of a new product or business solution that is used to prove or disprove the epic hypothesis. As opposed to story boards, prototypes, mockups, wire frames and other exploratory techniques, the MVP is an actual product that can be used by real customers to generate validated learning.” M.V.P. is useful when it is managed effectively by the team, but often, it doesn’t live up to its potential. We see this when M.V.P. and “reality” collide, meaning the M.V.P. becomes the O.V.P. (only viable product). The concept is proven and sound but the execution fails to achieve the best outcome. Why does this happen? A few things can derail the M.V.P. effort and make it almost worth skipping. (I said “almost”, please don’t send me hate mail to all the SafeAgile followers out there!)
Reasons why MVP fails:
Deferring to a Mythical Future Phase – The MVP is used as the feature deployment itself, and never looked at again. It could contain 85% of the Epic goals, but further improvements are abandoned. The users pay the price when this happens, because they are most likely being told they got something that is “good enough” and it will get fixed in a future phase.
Changing or Competing Priorities – Priorities shift the team focus and resources away from finishing the Epic. The M.V.P. is dropped off and left to wither away along with the initial project goals.
Personal Bias – The team may get feedback from the users about the M.V.P. that conflicts with their own preconceived beliefs, and so the feedback is ignored. The M.V.P. may actually get to the users as a finished product, but it isn’t useful (or worse then the original solution) and they work around it.
There are probably 10 more reasons that cause the M.V.P. to not be useful, but these are some of the most common. What can be done about this situation for the companies out there that are using a form of Agile, and want to have an M.V.P.? While one size does not fit all, here are some ways to combat the distractions to fully realize the M.V.P. potential.
Proactive and corrective actions:
Every team must include a “follow-up and feedback” task, for every feature that is deployed in an M.V.P. With an assigned owner, a due date every week to report during the group's product owner and/or scrum master meetings, and action items from those results. This avoids the tossing the product over-the-wall syndrome, and identifies responsible owners from each team.
Just like when a product is deemed ready for G.A., a target team needs to set up proactive support for the M.V.P. and users. Daily meetings, frequent check-ins, opening tickets when issues are found. By treating this as if it is the final product, a faster feedback loop and response cycle will occur allowing for adjustments.
The M.V.P. period must have a start and end date. Even if it is just 1 or 2 weeks long, set a finish line to once again create a sense of urgency. After the period is over, have a meeting with all the team members and users, to review the feedback and responses. Fully transparent reviews, where everyone can participate will greatly improve the coordination between the teams, and give clarity on the next steps.
Unfortunately, sometimes there are changes in company priorities due to outside elements or changing leadership. A new M&A acquisition comes in with integration timelines that will derail any currently running Epics. However, if an M.V.P. has been released, the product manager needs to negotiate on this timeline and urgency. The cost of stopping and picking it back up in 6 months’ time, may be a compelling enough reason to shuffle the project list to let it complete. If there are outside resources that can be used, that could be another way of keeping the current epic moving along. In reality though, you understand that sometimes, you just have to accept the current situation for the benefit of your company. But keep the delayed project in front of the team so that it can be picked up and restarted as soon as possible.
When a team gets feedback that is contradictory to their expectations, it can be a hard pill to swallow. They may have been working on this for several sprints and are now being told that the baby is ugly. Instead of processing the new information and plotting a new course, they determine that they really do know better and carry on with the original plan. The end result is a disaster with the project team deeming it “finished” and the users feeling betrayed and ignored. This can happen when a team has worked together for a long time, has a leader with an ego (or fear of failure) and others are unwilling to voice a “negative” opinion. By taking the actions in step #1 of actively soliciting feedback and reporting it to the larger leadership group, it makes it hard to ignore feedback. If after the group meetings, there is still a team that is looking to move ahead with the original plan, the overall product manager needs to step in and guide the team to do the right thing. This situation is a failure of leadership ultimately, and if it is happening in your organization, it needs to be brought to light.
Conclusion
If you are one of the few companies that are doing the M.V.P. correct, kudos to you! If you are not, have a deep-dive discussion with the full project team and any users, and identify the blockers to success. The teams that can learn and grow from these kinds of challenges are the ones that will be the most successful and productive overall. Implementing this kind of change requires a thoughtful approach to understand the human element involved while keeping an eye on the final goal.