> Long term planning is meant to give people an idea of what's coming after.
This is precisely the problem though. Your statement is contradictory because if (as you say) long term plans don't in fact work, that "having an idea of what's coming" is complete fiction.
And trust me, confidently believing in fiction is much much worse for effective planning than proactively preparing your product for uncertain outcomes.
If I am 100% sure our product will be doing X and not Y in 18 months, I'm going to build that product with a strong bias toward X and zero consideration for Y. If I don't know what's coming, I'm going to build it with weak contracts toward both and a heavy emphasis on being refactor-/pivot-friendly. Which of those approaches will serve my company better when we unexpectedly end up switching to Y after a year?
I think parent’s point still stands: expecting that X and not Y will come in 18 months might be worse than not expecting anything, if X actually comes in 36 months.
Even within the same organization, it’s such a gamble when:
- X might never come if the project takes too long or gets deprioritized. 18 months is a long time, perhaps half of an engineer’s average time in the company. X’s sponsor going away could mean the project stays in limbo for the rest of its life
- X might become Z when you realize midway that X wasn’t a good idea in the first place, or the assumptions behind X changed enough for the project to not make sense anymore. The org might not care for the cost to readjust now that X is gone, but you’re still worse off than if you weren’t waiting for X.
That's fair. This isn't a binary, and the ideal is likely somewhere in the middle.
Still, I do think there's quite a large portion of detail-planning that can be radically different dependent on the high-level expectations, even where the range of high-level outcomes is small.
i.e. (random off-the-top-of-my-head example): I'm building a piece of software offering some kind of service to end-users. We're considering staff-curated -vs- user-generated & curated content & we opt for the user-gen approach as we don't think the first option will scale. As we get into the market, we quickly realise the demand for content is high, we're in a good position to adjust our pricing upward, but engagement in content-provision & curation activities is low. So we decide to pivot to staff-curation.
The above pivot doesn't involve a radical product change (the offering remains similar overall), but does involve radical technical changes under the hood. A long-term-planning oriented company may have invested heavily in building robust (expensive & complex) community features that may be thrown out later. A short-term-planning oriented company would more likely hedge their technical decisions - leverage some 3rd-parties temporarily during user-testing, maybe test earlier, be more sensitive to priority changes.
>And trust me, confidently believing in fiction is much much worse for effective planning
Absolutely TRUE - and this becomes a political problem in some organizations, depending on whether you're around people who can handle hearing the truth (whether they just don't want to hear bad news, or whether they don't understand complex webs of interdependencies that can cause time estimates to be wrong).
The refactor question is not just about the next 18 months. How likely the project will be in active development in 5 or 15 years?
That’s something long term planning can give you a reasonable idea about. If your working on Madden 24 then the business model is about minor changes every year, while most games are one and done.
This is precisely the problem though. Your statement is contradictory because if (as you say) long term plans don't in fact work, that "having an idea of what's coming" is complete fiction.
And trust me, confidently believing in fiction is much much worse for effective planning than proactively preparing your product for uncertain outcomes.
If I am 100% sure our product will be doing X and not Y in 18 months, I'm going to build that product with a strong bias toward X and zero consideration for Y. If I don't know what's coming, I'm going to build it with weak contracts toward both and a heavy emphasis on being refactor-/pivot-friendly. Which of those approaches will serve my company better when we unexpectedly end up switching to Y after a year?