Beware: How Niche Use Cases can “NUKE” your team’s productivity and ruin your customers’ user experience.
As a product manager in innovative areas in a large corporation, I get to work on and with diverse teams from around the world. While this is very rewarding, it can sometimes be challenging. At times, I and/or my teammates realize we are spending a lot of time on certain use cases that are experienced by only a few of our users or is a very small part of a particular user’s experience. I think of these use cases as niche. The use cases may be interesting or propose unique challenges to the design and engineering teams; however, they have little impact on the actual user experience. As a product owner, it is important to make sure the team can recognize Niche Use Cases (NUCs, pronounced “nukes”) and ensure they are prioritized appropriately.
What are some examples?
Examples help demonstrate when teams might face a NUC. Here are a couple that could be generalized for your industry or area of focus.
Product evaluation — Enabling users to evaluate your offering is critical! Users need to be able to see how easy it is to use your product and the value provided. Hopefully, this helps transition the user from the Evaluate stage to the Embrace stage. This use case is exciting and interesting for all the product teams. They have a chance to measure ease of use and highlight the value of what they’ve done. It is also easy to measure how well you have done because one of the first stages of engagement is Evaluate. Even though this stage is critical, it makes up a small percentage of the end to end user’s experience… if all time is spent on evaluation, the experience for the users who have decided to purchase the offering (Embrace) may suffer.
Data sync — Throughout my career, I’ve spent a lot of time implementing data sync solutions. These have mostly been on enabling mobile and web clients getting access to data in a concurrent manner. This could be data like email and address books or generic data stored in json documents. In every data sync project I’ve worked on, the engineering team ends up spending an exorbitant amount of time trying to understand the edge cases dealing with data conflicts, when multiple clients modify the same data at the same logical time. While this is an important use case that must not corrupt data, there are usually simple solutions that involve end user involvement. We have learned through experience that these conflicts occur rarely and should deserve a proportional investment from the design and engineering teams.
Why might this happen?
I assume we are all on teams that are lean and agile. In these cases, our teams prioritize by focusing on a Minimal Viable Product (MVP) and execute using sprint planning, backlog grooming, and iteratively improving based on user feedback. This usually works, but sometimes a NUC can be hidden within a user story. The team working on the user story might not realize the importance (or lack thereof) to the bigger picture. In a similar way, multiple teams may be contributing to a larger user experience. One of the teams might not realize they are spending time on a NUC that might be very relevant to their scope, but actually niche to the full picture.
Are there exceptions?
Of course! Any product must prevent disastrous outcomes, no matter how rare. In the data sync example above, a data conflict must do no harm. You may recall a certain rare issue with Samsung batteries. This disastrous outcome deserves team investment to be avoided. If you think you may be spending too much time on a NUC, make sure to ask yourself and the team, “Could this result in a disaster for our users?” If so, address it!
How can we identify NUCs getting too much attention?
As a product manager, engineering lead, or design lead, it is our responsibility to the focus and invest the team’s time where we will get maximum return on that investment. Part of that process is being able to identify and avoid NUCs. Ask yourself:
- What percentage of our target users will exercise this use case?
- How much of their time will be spent there?
- How frequently will they return to the use case?
- Is there potential for a disastrous user experience?
Based on your answers, you should be able to maximize your team’s productivity and create great user experiences.
