But feasibility assessment is basically about going to the engineers and saying, "we want to spend 6 months on product X -- can it be done to satisfaction in that time?" That's often a very easy question to answer reliably.
Long-term planning approaches the problem from the ass end of things. It's going to the engineers and saying "design feature X on paper for us" and once they've spent a month doing that, management says, in the best case*, "well, this work cannot be done for real in the remaining five months, so never mind".
The original question would have been answerable in a day without going into too much detail.
----
* Best case. The more common case would be "well, now that we've spent a month planning this we better get the actual work done in the five remaining months, no matter what it takes!!"
We engineers can be really fast at refusing unrealistic estimates imposed by other departments, especially when we take them for loosers. But we are not very good at estimating as well, and we are often overoptmistic. I don't track my times too fanatically, but I do it +/- regularly and, still, I err way more than I think it's reasonable considering the data I have.
I don't think you are going to get much reliability on simply asking 1 question to an engineer, especially if you approach the matter with such overconfidence.
You might argue that an engineer would be more conservative and would avoid many mistakes by replying "no, it isn't feasible" more often than not, but then they would be wasting a lot of opportunities by discarding feasible projects, ruining the company as well, only in a different way
Is your experience really that engineers cannot reliably estimate feasibility given a fixed budget, and that they have to be treated like children and asked for something completely different?
If they can't do their own feasibility assessments, they will be producing bad work, because there are many feasibility questions that arise during design and development, and never even make it to the parents^Wmanagement.
Then I feel like that's the bigger problem that needs to be handled with training, and perpetually working around it is still a bad idea.
Long-term planning approaches the problem from the ass end of things. It's going to the engineers and saying "design feature X on paper for us" and once they've spent a month doing that, management says, in the best case*, "well, this work cannot be done for real in the remaining five months, so never mind".
The original question would have been answerable in a day without going into too much detail.
----
* Best case. The more common case would be "well, now that we've spent a month planning this we better get the actual work done in the five remaining months, no matter what it takes!!"