>
to things the PM assumes we're going to need in the futureI'm curious - do you know the PM is just assuming these things will be needed, or are you assuming they're assuming? PMs often (necessarily) have a much broader view of the customer base and the future needs of the product than a dev team, and this can lead to some tension if those future needs aren't articulated well.
Two things to came to mind when I read your question:
1. My understanding of YAGNI has always been developer-focused, i.e. don't implement features no one asked for until they're needed. YAGNI discussions I've had are more focused on architecture and the abstractions chosen for an implementation. Implementation details the PM needn't worry about.
2. One could argue that a PM asking for that feature is when it crosses into the "needed" category, assuming they're doing their job correctly. In other words, the fact that a PM is asking makes me question whether the principle of YAGNI actually applies at all (based on a definition of YAGNI that involves implementing things no one asked for "just in case").
It's the PM's job to help the dev team understand why it's needed though, and the root cause here could just be that they're not communicating well. Unless you're also working with customers and taking their direct feedback on feature needs, you can't just "YAGNI" a requirement you don't agree with.
As a former full stack dev who turned to product management later in my career, I've had to convince my dev teams many times that a feature is needed, and customer feedback and subsequent adoption data proved that it was indeed the right choice.
But I always went to bat based on well articulated use cases and problems my customers had been begging us to solve. It's possible your PM hasn't done the research, but only after understanding where the requirement originally came from could you have a real discussion about YAGNI.
> we've been trying to reinforce that we need specific user stories that explain the exact need, and it's just not working.
The #1 priority should be focusing on the customer's problem, not the feature itself. I've often found the XY Problem [0] a helpful tool when trying to get people focused on the right things, and "Fall in love with the problem, not the solution" also comes to mind.
Asking for a specific solution with no mention of the problem is often the big issue, and a hyper focus on articulating the problem itself can go a long way in navigating these conversations. If your PM isn't doing this already, that is a big issue. But trying to convince them of YAGNI won't help if they have other reasons to believe it actually is needed.
- [0] https://xyproblem.info/
Editing to add: This also depends very much on the stage of the product. If you're still not at MVP, you should focus on defining what MVP looks like, and a lot of things might just clear up. If the product has existed in the market for some time, focus on validating the user problems that are leading to these requirements.