I think the most important function of a good Product Management team is to understand what parts of the go-to-market impact tech decisions and spend 80% of their energy into pinning those down as firmly as possible. There is a happy medium between JIT delivery of specs for random features and a hard two-year roadmap that can't react to business changes.
YNGNA is generally true, but Product's should have a very clear vision of what kinds of entities the system is going to handle over then next 36 months before they start asking for specific functionality. I've seen extra shit get built, but I've also seen e.g. a travel booking system that was built without a "flight" being a first class entity. Flights were deduced on the front end from attributes attached to seats... which worked well until a PM asked for the UI to show fully-booked flights, which HAVE no available seats that make it to the front end. Same product couldn't handle the booker and traveler being different people, when they knew from day 1 that it would be a necessary feature. It would have been little extra work to incorporate into the data model from the beginning, even if the two values were always the same for a while.
I think the majority of the technical debt I've seen that isn't ci/cd related is disconnect between the domain model the product team is working in and the data model the engineering team is working with. Formalizing that domain model is now one of the first things I do when joining a team, so everyone agrees on precisely what the major nouns and verbs are and how they interact. Not just for the current system, for where we think we will be in 2-3 years. With everyone doing agile, it's amazing how many incompatible, un-written assumptions you discover that hadn't been ironed out.
YNGNA is generally true, but Product's should have a very clear vision of what kinds of entities the system is going to handle over then next 36 months before they start asking for specific functionality. I've seen extra shit get built, but I've also seen e.g. a travel booking system that was built without a "flight" being a first class entity. Flights were deduced on the front end from attributes attached to seats... which worked well until a PM asked for the UI to show fully-booked flights, which HAVE no available seats that make it to the front end. Same product couldn't handle the booker and traveler being different people, when they knew from day 1 that it would be a necessary feature. It would have been little extra work to incorporate into the data model from the beginning, even if the two values were always the same for a while.
I think the majority of the technical debt I've seen that isn't ci/cd related is disconnect between the domain model the product team is working in and the data model the engineering team is working with. Formalizing that domain model is now one of the first things I do when joining a team, so everyone agrees on precisely what the major nouns and verbs are and how they interact. Not just for the current system, for where we think we will be in 2-3 years. With everyone doing agile, it's amazing how many incompatible, un-written assumptions you discover that hadn't been ironed out.