Traditional software development often begins with technical considerations—choosing frameworks, setting up infrastructure, and structuring the codebase based on programming paradigms. However, any software development process is the response to a business need. For example, a bank may request a system to process loan applications automatically. Engineering teams do not build things out of nowhere; they have specific requests to build something. You might be familiar with the software engineering process of gathering requirements, requirements elicitation, and so on. Once the requirements get translated into user stories (if you follow this approach), the connection between the engineering team and the business teams is lost, and only figures like the product owner, project manager, and so on are keeping this link. In fact, these people are seen, from the perspective of the engineers, as the ones who interact with the non-technical people and relieve them from the burden of meaningless chats about things that businesspeople would not understand. From the perspective of businesspeople, these figures are the ones who try to help them make some sense with the engineering team and explain to them what the problems are and why things are not like they expected.