[vishnugupta]

That makes lot of sense.

Back in my student days we were taught about a role called "system analyst" I think it was part of COBOL. They have deep domain expertise and work with programmers to automate business workflows. Their job is to identify the entities you pointed out (patrons, trips etc.,) and clearly document all the interactions and workflows. They then figure out what kind of workflows need to be automated, to what extent and so on. They also are supposed to ensure that disruptions to existing systems/processes/people are kept at a minimum level. Note that these system analysts are not air-dropped product-managers but rather people who have been working inside the system for decades. They know all the edge cases, context, and more importantly history so they know why a certain Chesterton's fence exists.

I haven't come across such folks in my professional life. So engineers are expected to learn and automate a domain at the same time. It just doesn't work that way. No wonder many of the IT systems have been a disaster. Implementors discover, to their horror/surprise, that the real world is full of edge cases. Take Uber for example. The first launch didn't include tipping. It was a monumental effort to retrofit that into their payment processing and ride handling systems.