Cross-functional teams and dysfunctional teams
I had the opportunity to work in a cross-functional team a couple of years ago which was some of the best times I have worked as a developer. There were no boundaries between the people in the business who had the role of the client and us developers. We'd make a prototype in no time. We'd see their reactions and hear their honest comments, positive or negative.
During that time, we made so many achievements. We made the site responsive in 2 weeks with 2 developers. We rebuilt our entire CMS platform with a much simpler architecture and made is faster in less than 6 months. Having the cross functional team in place made it so much easier to agree on certain changes and getting the requirements first hand.
I have also worked in other teams with different approach and culture in handling requirements and relationship with the product management. Although they keep referring to themselves as cross-functional but we rarely see the face of the stakeholders. They do meetings once in a while to explain their ideas and we do a demo when everything is implemented (which often takes months). The link between the team and the stakeholders is broken and that is damaging in many aspects.
The Management
When there is no direct link between the stakeholders and developers, the requirement is passed through hoops to get to the developers and it takes way too long. By the time they are implemented they might not be what the stakeholders wanted or it might be way too late and the competitors have already filled the market with their product. If it doesn't meet the requirement, the developers end up patching the code under pressure. The code turns into a bad state and eventually becomes very difficult to maintain. It becomes very expensive to add new features, bugs are found often and the stakeholder lose trust in the developers gradually.
The above happens when the manager is insecure. They are in dilemma of the desire to have control and be hands-off (as sometimes they don't know how everything works). They want to be the ultimate decision maker because they think they know the best for the team and don't trust the team for managing their own work stream. The manager stands as a proxy between the developers and the stakeholders, thinking he/she is protecting the developers and keeping them in the right path. However, as the manager doesn't trust the team, he often doubles the estimations trying to "meet the deadline" with the cost of overestimations.
Reference: Do Employees Quit Companies or Managers?
Broken, expensive product
So far we have an unmaintainable product that is expensive to run and managers who double the estimates. There's no trust in the team which gradually demoralises the members and make the product that is already costly to run even more expensive to maintain as the team are beyond demotivated to focus and put half effort to solve the problem which is their main responsibility
The result
The product owner only sees one and only one thing. The cost. If it is too expensive to run the product, he will find a way to cut costs. As the product is broken out of hand, the product owner, will seek different means of replacing it. Outsourcing and buying off the shelf products are the two most popular options. In either case, the above mentioned manager has no role or little involvement.
Months pass, and years pass, the product is rebuilt in a country that is perceivably cheaper than here or an off the shelf product is forcibly used with major customisation that makes it equally as unmaintainable as the previous product.
People leave, new senior managers come with new managers under them.Directions change and they decide to build the product again from scratch. Restart. Will there be a lesson? I doubt that but I hope maybe this time they have that link in place!