YAGNI includes time to fix things when YNI (you need it). YAGNI is not prematurely optimizing for complexity.
If a PM (or an eng for that matter) can justify the need for the complexity, either because they are extracting 2-3 use cases in to a generalizable solution, or they have 1 but know that 2-3 or more are coming real soon, then bring on the complexity.
The first time you do it, just get the job done as described.
The second time, look for ways the two might be similar, but don't spend a lot of time on it.
The third time, generalize and assume there will be a fourth, fifth, sixth, etc. time.
In the example the top poster gave, the first time it was requested, I would just write up some code for triggering the notification. The second time, maybe there's a shared class (or whatever) for notifications with text passed in. The third time, now maybe we need the ability to specify notification text in config or DB or through user-triggered actions.
Ideally, the business should have their processes defined before ever implementing them technically. So these architectural questions should mostly be addressable from the start. Knowing hoe the processes look upfront can actually lead to some wonderful designs rather than constant reactors. We had a system that we knew from the start would have multiple UI layouts for multiple workflows that shared mostly similar data. We were able to build the UI to dynamically build the pages based on the data.
To be clear, I'm NOT advocating for premature abstraction, as a PM I live and die by "rule of three" when making decisions re: "let's just quickly solve this one bespoke need", vs "let's think about this more systematically".
But customers will never tell you all their requirements up front, and it's a PM's job when hearing a need from a customer to take the time to figure out if it's a single unique stand-alone problem, or simply one instance of an entire category, the other 3687 of which your customers are going to come asking for the moment they realise it's a category of problem your product is able to help with at all.
Perhaps it’s better to ask what will put the greatest cognitive strain on the developers.
Generally I want to program for the specific case first and hopefully make it so small that it doesn’t hurt to throw it away when the requirements change. But if the specific case means the whole team has to be burdened with a lot of really obscure hospitality domain knowledge, maybe it’s quicker and easier to build the abstraction.
Right, this is why a bad PM is worse than no PM. "Just build this one use case, and since it's so simple, I promised it by nex week". Instead of digging deeper, as you suggest.
If a PM (or an eng for that matter) can justify the need for the complexity, either because they are extracting 2-3 use cases in to a generalizable solution, or they have 1 but know that 2-3 or more are coming real soon, then bring on the complexity.
It's a balance, for sure.