Mastering Edge Cases as a Product Manager
- Cindy Adem
- Aug 1, 2024
- 5 min read
How to anticipate and navigate unique user stories for your product

What is an edge case?
This is a user experience that is different from the main or anticipated way of using or experiencing your product. Stay with me- before Uber launched the 'order for someone else' feature in a lot of markets like Nairobi, the ability to order a ride for my mother to take her from point A to point B was cumbersome. To place a request, I had to set the pickup location, talk to the driver after we've been matched, let them know they'll be picking up someone else instead of me and give them the number to call mom when they get there. I'd also have to send mum the driver's number so they can coordinate specific locations.
At that point, placing an order on behalf of someone else was an edge case; i.e, an atypical use of the uber app.
Now, with the updated feature, all I have to do is set the pickup location appropriately, uber will notice that it's different from my current location and will ask me if it's for someone else. I'll agree and with a click of the share button, both mom and driver have each other's locations and details.
Uber did not require that I make mum download the app on her phone and show her how to use it confidently before she can benefit from it. It simply saw a new way users like myself utilize the app and made the process simpler for us both.
Anticipating non-regular user stories is how you deal with an edge case as a PM.
Common Edge Cases and how to anticipate them
1. Transitions Between Account Types: The Shape-Shifting Challenge
What it looks like: Any kind of transition between account types with different kinds of permissions.
Example: YouTube Premium - switching between free and premium, or downgrading from premium to free.
How to plan for it:
1. List every account type like you're cataloging Pokémon.
2. Create a matrix to account for transitions between each. It's like playing chess, but with user accounts!
Mitigation strategies:
1. Always test transfer of data, settings, and permissions. For instance, if one account type should be able to see specific features/data that the other account type shouldn't be abe to- test those transitions with the same user account. You do NOT want to compromise on this.
2. Communicate changes clearly to the user so they're not left confused with 'where did all my buttons go'.
2. Missing Data Due to API Failure: The Blank Screen of Death
What it looks like: Any feature that relies on fetching data has a risk of not being able to actually fetch that data. It's not personal, glitches happen.
Example: Facebook's occasional "Oops, where did all my friends go?" moment when the friend list fails to load.
How to plan for it:
1. Consider each element of your interface that relies on fetching data. Make a list; check it twice.
2. Plan for outages of each kind. Because Murphy's Law is always watching.
3. Prioritize by highest likelihood of failure and biggest impact. It's like disaster planning, but for your platform!
Mitigation strategies:
1. Implement error handling, retries, and fallback to cached or default data. It's like having a safety net for your data trapeze act.
2. Notify users of issues in context of where outage occurs. And make it clear that it's not a user error and what they should do (if applicable) even if that is simply to Contact Support. Or check outtage reports . Don't leave them hanging!
3. Device Type and Version Compatibility: The "It Works on My Machine" Conundrum
What it looks like: When 90% of your users are on desktop with XYZ latest features but there's a smaller subset that's still uses a humble mobile OS.
Example: Using the Facebook web interface -not app- on mobile (i.e facebook.com) ... with limited connectivity. Thank goodness for Facebook Lite app though.
How to plan for it:
1. Consider every possible device type and OS version your product can be used on. Yes, even that ancient phone your grandma refuses to upgrade.
2. Plan for potential issues. Make a list; prepare for it to be a long list
3. Either come up with solutions that work across versions, or limit your product to specific versions and devices. Pick your struggle and communicate this choice with users.
Mitigation strategies:
1. Test UI/UX for different screen sizes and OS features. It's like dressing your app for every possible weather condition.
2. Ensure backward compatibility with older versions, based on the tradeoffs you're willing to make. It's okay to decide you just will not serve a specific user-base.
4. Accessibility Settings: Reasonable accomondation
What it looks like: Device accessibility settings can sometimes dramatically change the display of your product minimising usability. It's like giving your app a surprise makeover.
Example: iOS settings going extra large font, causing misalignment of elements and unreadable text.
How to plan for it:
1. Get data on the most common accessibility settings of users when using your app. Know your audience!
2. Consider the most common settings. It's like preparing for different dress codes at a party.
Mitigation strategies:
1. Design product to comply with accessibility standards. It's not just nice; it's necessary.
2. Test device with different accessibility settings. Be the user you want to see in the world.
3. Provide alternative content or functionality with different settings on. Because one size usually doesn't fit all.
5. Network Connectivity: The "No Internet" Nightmare
What it looks like: Users experiencing limited or no internet access while using your product. You probably know of the endless loop of death as you try to load a page.
Example: A user trying to finalise their Google Slide presentation on their way to the airport enroute to a client meeting. And they cannot move an inch because 'We're unable to connect to the internet'.
How to plan for it:
1. Consider the effects of poor connection or disconnection in the middle of your product experience. It's like planning for a game of "The Floor is Lava," but with data.
Mitigation strategies:
1. Implement offline functionality with cached data. Notion, G-Suite and other self-respecting products have been able to pull this off quite well. Because you don't want to be the reason someone fumbled a multimillion $$ contract.
2. Create error states that explain the error to users. Let them know why their cursor is not moving or their screen is frozen. And, if your software detects latency in an ongoing connection, advice the user to go offline mode soon as the connection is reestablished.
Now, edge cases can be an endless black hole of infinite possibilities. Whenever you think a user cannot surely got to a certain corner of the app- they do. You may not always be able to over-prepare for them, but if you keep an eye out on your analytics, on your support tickets and on the feedback from your users, you'll be able to build a rock solid list of possibilities - and decide which paths you prefer to take.
As always, test test test.
Until next time, keep living on the edge... of product excellence! Lol.
Question Time :)
Which of the following is a key strategy for addressing edge cases related to network connectivity?
Assume users will always have a stable internet connection
Implement offline functionality with cached data
Provide error messages that blame the user for network issue
Tell users to always use a VPN for more reliable connection