All hail the product people that have to do this.

In my experience, virtually none of the product people do this, at least initially. The requirement to begin with covers about 10% of this flowchart, then engineers start asking questions about edge cases, and pretty soon you’re sitting through your third meeting trying to just get everyone on the same page of what the requirements are, let alone how to build it.

You missed the part where you ship it with the 10% covered and then those "edge cases" get reported by pissed off customers who keep getting alerted despite their notification preferences.

Not to mention these notifications cross multiple devices so depending on how the teams are split there might be totally different teams managing the frontend toggles to change them and the backend services that persist those toggles... and then maybe a team or two to actually handle the sending.

Maybe another team that's just dealing with the WebSockets - gotta get notified about new messages if you have the app open, too.

Same here. I guess this is the ethos of Agile? Start somewhere and iterate on requirements/edge cases as they're needed/arise?

Though I kind of hate this approach. As when you begin with just 10% and keep tacking on things for edge cases, you tend to get a crummier solution in the end than you otherwise would have. But that's why refactoring is a thing right? Oh wait, management is against that because they don't acknowledge technical debt...

Let me just slip this in here: https://www.youtube.com/watch?v=P4VBqTViEx4