If you don't understand the end-to-end scenario, it's easy to do something that is ultimately self-defeating.
For example, my 3yr old daughter recently learned to play hide-and-seek. The goal of the game is to hide and avoid being found while the "it" player searches for you.
She's got the part about hiding down. But then once hidden, she shouts out "Daddy, come and find me!!". Given that I'm not deaf, it's kind of self-defeating.
This comes up often in performance scenarios. We've all heard some story where somebody tries a premature optimization and it ends up slowing things down. For example, somebody goes and adds caching to something, and the overhead of maintaining the cache drowns out any perf wins.
Another example is adding some cool feature that's an innate security hole.
A more general example is adding an feature X, but you need feature Y in order to use X. For example, to create a new ICorDebug object in CLR V2, you needed to pass a version string of the debuggee. But V1 didn't have a way to get a version string from a running process, so we also had to add a 2nd new API, mscoree!GetVersionFromProcess in order to enable the attach scenarios.