I've seen "product driven management companies" do R+D the way OP saw things happening. There's no way to do true R+D with product driven budgeting. Perhaps "

I've seen "product driven management companies" do R+D the way OP saw things happening. There's no way to do true R+D with product driven budgeting. Perhaps "big corporate" has their own R+D and forbids divisions from doing R+D. Its really none of OPs business. The backlog is always two years because budgeting is done for two years and the goal posts will change continuously to keep the backlog long enough to keep the budget afloat. The goal posts always move continuously because R+D advances. If they close out and release 1.0 then the team and project have to shut down and transfer to the maint group. If you just keep the project eternally open then you don't have to re-create and open for bids and start entirely over to being version 2.0, you can just massage the requirements into 2.0 and keep going. The individual contributor layer might not be cutting edge R+D, OP probably wasn't using framework-of-the-month or language-of-the-month but at the business level it might have been interesting R+D, far away in logistics-land or something. A product driven company can bury paying for R+D this way if no one points it out, but if someone makes a formal report calling it out, that's a career limiting move so lets not look too close. The other thing I've seen blow up is the business changes faster than the coders can keep up. If you have small enough line of business revenues you can over invest into automation; to put it in terms HN can understand if you engineer a hyper-scalable startup and only ten customers show up, that's a lot of money down the drain. Even worse if they're ten HUGE enormous customers you can stay in business a long time even if the automation would never, ever pay off with only ten customers. Or logistics invented a strategy that is obsolete before the coders can code it. Some companies are really good at processing "build a bridge" Like a physical bridge cars drive over. Their internal systems will melt down conceptually at the idea of having a R+D dept with a permanent budget, even if it works and even if R+D makes a net profit. I had dealings with a place that, at a high level, made cranes, like industrial lifting cranes. They needed a R+D budget for R+D things but they only spoke business like a housing developer, you sign the contract, build the crane, find another contract. Smart companies that need to do R+D will find a way to do R+D even if they use really weird terminology to manage it. The way companies like this move from one R+D project to another is "whoopsie the eternal product development is over budget scrap and do something else". Now they're probably got an eternal "fake product" around actually doing R+D using AI algos in the cloud or something. Or they're doing bland IT support, just endless Python CRUD for an R+D experiment in doing JIT logistics in a post-covid chip shortage world where the R+D is not in IT but the R+D is outside IT in logistics or accounting or marketing or something. I can't guarantee this happened to OP but I've worked at places like that.