As someone involved in software product development, I try to use the word project as little as possible. The issue isn’t using projects as time-bound containers for investments. Or to rally an ad-hoc team for a temporary effort. That seems pretty reasonable to me. Rather, it is what we miss when we only look at projects and/or define our projects too narrowly. In my role as a product manager, I find that by saying project less often — even when my teammates say it frequently — I keep my eyes on the prize.
Take the example of a project that adds complexity to a product. The complexity outlives the project, must be maintained, and may eventually require refactoring or a rewrite to enable new capabilities (or accommodate unexpected growth). Sure, that future work can be encapsulated under a new project, but you’ve potentially lost some of the context and continuity.
Or consider the team that is focused on the mission of improving a specific metric (e.g. retention, adoption, revenue, etc.) Leadership agrees to fund the mission, provided the team can continue to generate impact. Is the project the whole mission, or should each of their efforts be accounted for (and managed) individually. Are you still “finishing projects” in this case?