Class #4: MVP, Feature prioritization
This is getting interesting. Now that I have familiarized myself with my detailed persona Cindy (without having to shave my legs) I can identify the core features my app / website would need to have to solve her problem. I am going to then use that information to create a Minimum Viable Product (MVP) as part of my product strategy and to assemble the feature list.
To achieve this I am going to use two different tools, user scenarios and user stories. They sound the same but are in fact completely different.
A user scenario describes a situation in which the user faces the challenge that prompts them to solve the problem. It allows for an explanation of pain points and motivations and adds context.
Best practices for scenarios:
- They tell a story by creating context for an interaction between human and product
- Inform about location, device and other contextual details
- Describe motivations
- Highlight user expectations
- Are not system-specific (have nothing to do with your app)
Based on my persona, Cindy and my research I described a few potential scenarios:
- Cindy is a designer who recently moved into a new condo building. She doesn’t know many people and would like to expand her network and circle of friends. She finds that a lot of her neighbors seem friendly but doesn’t know how to approach them, elevator talk isn’t her thing. She needs to break the ice but wants to avoid awkward situations.
- Corey is a social person who loves meeting people. As a foodie he dines out at local restaurants all the time and is always on the lookout for the latest and greatest. He is looking for a recommendation from someone who lives in the same area.
User stories are a one-sentence summary of a feature told from the perspective of the person who desires the new capability. User stories are succinct and focus on one feature at a time. They can be part of an “epic” which describes a broader story encompassing multiple potential features.
User stories are based on a super-useful template:
As a role/persona, I want to do this so that way I benefit.
Based on my persona and research I described a few user stories:
- As a user I want to post pictures so I can show people where it’s best to bike in the neighborhood.
- As a user I want to get updates when someone commented on my post so I can stay in the loop.
- As a user I want to be able to message someone privately so we can share sensitive information.
- I want to be able to search information people posted in the past easily so I can be efficient.
- I want to fill out my profile with as little or as much information as I want so I can still feel safe.
- I want to check updates on my own schedule because I don’t always have time to socialize with people in my building.
Now that I am more familiar with “What Women Want”, or rather what my dear persona Cindy is looking for I can start listing out features so that I have a better understanding of what my Minimum Viable Product (MVP) could look like.
Minimum Viable Product
A MVP is a working, deployed version of the product that helps validate the product strategy.
- Focus on it’s target audience
- Provide enough value to use
- Demonstrate future benefit (generate returning users if applicable)
- Test hypotheses
- Accelerate design process and learning
- Provide a feedback loop for UX
- Should not focus on “product design” — focus on main task to accomplish without additional (nice-to-have) features
Most importantly, feature prioritization helps avoid feature bloat and scope creep and distinguishes between WANT and NEED. This is a crucial point in the design process as without it any project will fail either it’s budget, timeline or the sanity of the team.
Usually owned by the team and enforced by the Product- or Project Manager, feature prioritization also helps define the roadmap and schedule development and design agendas. It also highlights what the product is not going to be by creating boundaries of work (scope).
There are some great techniques available to help with this process:
- Feature Priority Matrix
- Feature “buckets”
Feature Priority Matrix
This matrix measures two axis, effort and impact. It is divided to four areas:
- Quick Wins — Low effort, high impact
- Fill Ins — Low effort, low impact
- Major Projects — High effort, high impact
- Dump or Reconsider — High effort, low impact
In class our task was to set up this matrix for a fictitious product capable of digitizing paper receipts. We came up with about 30 different features in a previous exercise that could be inserted in the matrix. I found that the biggest challenge was figuring out how much effort it’s going to take to develop a certain feature (even though I had a designer and a developer on my team). For this purpose, agile teams might use a technique called “Planning Poker”. However, I did find it useful in identifying where we could start with basic features, an approximate overview of what our MVP could be and what features were way too out there to even think of (dump, don’t even reconsider…).
A more simplistic way of defining categories of features is sorting them into buckets of “must have”, “nice-to-have” and “not needed”. While I found this approach to also be useful I found it to be a bit too rudimentary as considerations weren’t really based on any scientific detail.
The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories. More information about this model can be found here.
I would like to have done a test drive with this model as Tim mentioned that this is what he uses the most in his daily work and it seems to be more detailed than the previous two methods.
Since I am at the early stages of my product I am going to be using the Feature Priority Matrix to prioritize features for my project.
Here is version 1.0 of my feature list based on user stories and brainstorming: