Good resources to teach a PM about YAGNI?

This doesn't make sense to me. YAGNI doesn't really relate to product management. When a PM talks about future extensions of the product, they're literally stating that "we're gonna need it". You can disagree with that, and argue why you won't need that feature, but that disagreement is separate from YAGNI.

In short, you shouldn't refer the PM to YAGNI (since it's completely irrelevant) and instead discuss your ideas as to why those features are not necessary.

What helps me the most is to point out to the PM that software development is done better when engineer has an understanding of the whole system. So, I tend to ask PM to spell out the entire system as they desire, instead of spelling out the MVP and future extensions separately. You can first discuss what's the end-goal with the product, and then discuss what belongs in MVP, or earlier versions of the product.

When I run into this I like to suggest "lets sketch out the design of the whole system, and then only build the part we need right now". This helps make sure you're not building yourself into a corner, while also letting you focus on just building what you actually need.

I think you'd have better luck explaining the concept of Minimum Viable Product instead of YAGNI, as it's more business-centric.

Forgive me if the assumptions I'm making here are incorrect, obviously or belittling. It seems you're an engineer trying to help a PM here. Ideally they can get mentorship from a more senior PM inside or even outside your organization.

I stress finding mentorship because what you're bringing up speaks to this individual not quite getting one of the key pieces of a junior PMs job - controlling scope. If they don't understand that and iterative development they likely need a larger education in the job itself and how to be effective at it.

If the PM is defining the solutions, you have a much bigger problem than YAGNI. A PM's job is to define "problems" - i.e. the functionalities of the software - and it's on the dev team to solve them.

> to things the PM assumes we're going to need in the future

I'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.