There is an example in the video “Make impacts, not software” I linked to.
Here’s another one from my experience.
A software application exported document-like data from a tool, then that data was imported into another tool at a different company.
One day, stakeholders requested to export document fragments. That would have been a significant development effort, as it would not only have required creating a diff between an old and a new version, but also account for the fact that the data at the other company could have changed in the meantime.
Eventually, it turned out that the real reason the stakeholders wanted to export the fragments was that they were unhappy with the performance of the application. So by improving the performance — which was easier in that case — the need for the feature went away.
So, to summarize: sometimes, you can shorten a user journey. Sometimes, you develop what was requested, and sometimes you develop something completely different. The key point is: have a conversation with the users, and find out why something is needed.