November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
prioritizing the requirements and deciding the priority based on who will do the funding.
An MVP is supposed to be an experiment designed to provide maximum validated learning at the lowest cost/effort. It is NOT intended to be something for mass consumption in most cases - that would be an MMR or MBI depending on the school of terminology you follow.
What gets into an MMR or MBI and the sequencing of features into releases is the core of effective product management. There are many techniques for prioritization, but the root of all of them is being able to facilitate decisions with a group of often misaligned stakeholders.
MMR, MBI a? Never heard of it. We are not doing these. In our case, after an MVP is delivered, we get a lot of different feedback requests. We do like what I said earlier - prioritizing the requirements and deciding the priority based on who will do the funding.
Maybe I should read about MMR and MBI to know about them. Will do :)
MBI = Minimum Business Increment. This is similar to an MMR in that it contains everything required to deliver a slice of value to an end user (e.g. software, change management collateral, support collateral) but is applicable in all contexts and not just for marketable products.
Most of the times when folks say "MVP", they really mean MMR or MBI...
Prioritize enhancements based upon user or market segments. Determine the different user segments for the product or service and then prioritize them based on the benefit each provides back to the organization. For the top user segments, understand how each uses the product or service and how each uses it differently. Adapt the product or service for the top usage cases and consider splitting the product or service into unique offerings for each market.
The organization needs to prioritize what is learned from users and ensure that effort expended benefits both the user and the organization.
Every time I was starting a project where I was asked to lead the team to deliver a MVP, I Learned to clarify with different stakeholders what is their understanding of the MVP.
Then was a little bit easier push back or facilitate new features Vs enhancements. Doing this question also often helps you to learn what's the risk appetite of the organisation and stakeholders. Them put as mention earlier your priorities in order and clearly drive the product/service development using this commun ground. Focus on version MVP as your 1.0v then log all requests, ask sponsorship from the major stakeholders and plan a v.1.1 with the enhancements that the business still is considering a must to have. This away you will keep the momentum to continuing to deliver to expectations.
This way it's likely you can start working to secure more founding for the next stages. Then
remember to communicate back to business the road map and when a new feature is planned to be available i.e. v1.3 which is in three months or whatever is you time line, this away you are also managing expectations and eventually keep the noise down. It seems now you are having a problem with the adoption and priority...just an idea below.
The harsh reality is that it's impossible to please everyone. Focus on the 80% rule... 20% of your users are very keen to have the new tool / service they are with you, they are the enablers, 60% don't know they will go with the flow and 20% will be always resistant to change...and I see often PMs put effort on the last ones trying to convince them...this is the biggest waste of time and resources. Stop doing this and focus on the 20% than want to help and let them drive the 60% of the users that will go with the flow... eventually your product/service will be a success and the 20% of resistance will join the Wolfpack or leave...
If your backlog was prioritized well then you should cover the top use cases but it won't be perfect of course. Adoption is all about change management. Users experience the same thing differently and it is part of your job to ensure that their experiences are managed as changes. For effective change management, you need data and a good way to get this post your MVP release is to do a survey. Make sure you define proper categories so that you can understand what your focus areas are e.g. Usability, Training, Functionality, and Management. Usability and training speak for themselves, functionality might be missed functions and management is what we missed when we rolled out (communication and support). Remember that the questions themselves will not be categorized but rather the responses i.e. 'Is the Menu options easy to find?' could be a useability or training issue.
BTW such a survey does not only provide valuable data for you to manage the change well but it also shows the stakeholders that somebody cares, the MVP was not just thrown out there with a use it or don't use it attitude.
Please login or join to reply