small tweak
diff --git a/Modules.md b/Modules.md
index 1758f39..6953d35 100644
--- a/Modules.md
+++ b/Modules.md
@@ -928,7 +928,7 @@
2. The second step usually should be to check `go list -m all` to see the list of actual versions selected for your build. `go list -m all` shows you the final selected versions, including for indirect dependencies and after resolving versions for any shared dependencies. It also shows the outcome of any `replace` and `exclude` directives.
-3. A good next step can be to examine the output of `go mod graph` or `go mod graph | grep <module-of-interest>`. `go mod graph` prints the module requirement graph (including taking into account replacements). Each line in the output has two fields: the first column is a consuming module, and the second column is one of that module's requirements (including the version required by that consuming module). This can be a quick way to see which modules are requiring a particular dependency, including when your build has different version numbers required for shared dependencies (and if so, it is important to be familiar with the behavior described in the ["Version Selection"](https://github.com/golang/go/wiki/Modules#version-selection) section above).
+3. A good next step can be to examine the output of `go mod graph` or `go mod graph | grep <module-of-interest>`. `go mod graph` prints the module requirement graph (including taking into account replacements). Each line in the output has two fields: the first column is a consuming module, and the second column is one of that module's requirements (including the version required by that consuming module). This can be a quick way to see which modules are requiring a particular dependency, including when your build has a dependency that has different required versions from different consumers in your build (and if that is the case, it is important to be familiar with the behavior described in the ["Version Selection"](https://github.com/golang/go/wiki/Modules#version-selection) section above).
`go mod why -m <module>` can also be useful here, although it is typically more useful for seeing why a dependency is included at all (rather than why a dependency ends up with a particular version).
