When designing and building a product, you'll be faced with many "what-if" questions from your stakeholders (and yourself). What if the user forgets their password? What if the bluetooth disconnects halfway through? What if X..Y..Z.
While it's important to take these scenarios seriously, it's even more important not to get bogged down by them.
Let's assume that 90% of the time the user takes the happy path, 8% of the time they take the unhappy path and 2% of the time they walk backwards into a wall - this is an edge case - it's not likely to happen but it can.
First things first
When designing a new product or feature - we should first solve the problem of the happy path, then tackle the unhappy path(s) and finally decide if edge cases are worth solving.
Trying to design for all 3 paths at the same time can inadvertently make us treat all 3 as equally important when they're not.
Another problem with designing for all 3 paths upfront is that we're working from the assumption that we know all of the things that can go wrong. This is unrealistic if you're building a software product in which devices, networks, servers and humans are involved.
So we should always aim to build our happy path and then solve the unhappy paths. You will often find at this point that you've uncovered new unhappy paths, or that one you considered important before is invalid now. Once you have a working product in front of you, you will see much more clearly the kinds of problems your users could encounter.
When it comes to edge cases, we should have an honest conversation about the likelihood of each these occurring and the user experience when they do. Depending on the scenario, we may decide to consider these as "accepted risks" and not worth engineering effort.
It can be an arduous process to try to imagine all of the things that could go wrong and design solutions to those problems while also designing how your product or feature will work 90% of the time.
Get to the first milestone by building the happy path and solve the unhappy paths from there.