Systems think in objects. Humans think in outcomes

Recently I attended a range of Salesforce events where conversation inevitably turned towards the latest announcements coming out of Salesforce. Agentforce featured heavily, as did Headless360 and the wider vision Salesforce continues to promote around artificial intelligence, automation and the future of enterprise software. What struck me was not the technology itself. It was the reaction to it. There was certainly interest in the rooms, but there was very little excitement. The discussion felt noticeably different from the conversations that often followed major Salesforce announcements a decade ago. Back then, organisations could immediately see how a new feature or capability might solve a problem they were actively facing. This time, the mood felt more subdued. While people acknowledged the potential of AI-powered agents and headless experiences, there was also a sense that many of these ideas existed in a future that had not yet arrived for the average organisation. During one of the events, I found myself in a surprisingly animated discussion with a developer. We were debating Headless360 and Salesforce's broader ambition to move beyond traditional interfaces towards a world where users increasingly interact through conversational experiences, intelligent agents and automated workflows. His position was clear and entirely logical. This is simply where technology is heading. Whether organisations are ready for it or not is largely irrelevant because, eventually, this will become the standard way people interact with enterprise systems. I understood his argument and, in many respects, I agree with it. Technology rarely waits for organisations to feel comfortable before moving forward. History is full of examples where new ways of working initially felt unfamiliar before eventually becoming commonplace. What fascinated me, however, was not the conclusion itself. It was the fact that we were approaching the same subject from entirely different perspectives. He was viewing the future through the lens of technology. I was viewing it through the lens of people. The more I reflected on that conversation afterwards, the more I realised that this difference in perspective may explain many of the challenges organisations experience not only with Salesforce, but with enterprise software in general. For decades, enterprise systems have been designed primarily around how organisations think. Increasingly, I believe the question businesses should be asking is what would happen if we designed them around how humans think instead. That distinction may sound subtle, but it has profound implications. Most enterprise software is built around structures, processes and data models. This is entirely understandable. Organisations need consistency. They need governance. They need reporting. They need data. As a result, systems are naturally organised around objects, records, workflows and relationships between information. From a technical perspective, this approach makes perfect sense. Human beings, however, do not think this way. A salesperson does not wake up in the morning thinking about opportunities, accounts and activities. A service advisor does not arrive at work thinking about cases, contacts and entitlement processes. A manager does not start the day considering dashboards, reports and record hierarchies. People think in terms of outcomes. They think about customer meetings they need to prepare for. They think about problems they need to solve. They think about conversations they need to have, decisions they need to make and objectives they need to achieve. Their mental model is fundamentally different from the model around which most enterprise software is constructed. This may sound like an academic observation, but it is something I encounter constantly through my work as a trainer. One of the principles that underpins almost every successful training programme I have delivered is what we often describe as "a day in the life of" approach. Rather than teaching Salesforce through objects, functionality and system features, we teach it through the reality of the user's working day. If I am training a sales representative, I do not begin by explaining the Opportunity object. I begin by asking what happens when they log in on a Monday morning. What information are they looking for first? Which customers require attention? What meetings are taking place? What actions need to happen before they leave for their first appointment? Similarly, when training managers, we do not start by exploring reporting functionality. We start by discussing the decisions they need to make. What information do they require to coach their teams? How do they identify risks within the pipeline? What signals indicate that intervention may be required? The distinction is important because people learn most effectively when technology is connected to context. They do not learn systems in isolation. They learn systems through relevance. This observation raises an interesting question. If training works best when organised around the user's day, why are so many systems organised around the underlying technology? The answer, I suspect, lies in the fact that technical professionals and end users often experience the world through different lenses. Most developers, architects and technical consultants have spent years learning how systems work. Their expertise lies in understanding data structures, integrations, workflows, logic and technical architecture. These are valuable skills and modern organisations could not function without them. However, many of the people designing enterprise systems have never performed the jobs those systems are intended to support. They have never managed a sales territory. They have never spent a day handling customer complaints. They have never worked as a field engineer managing multiple service visits under time pressure. They have never been responsible for onboarding students at a university or managing a busy admissions cycle. Again, this is not a criticism. It is simply a reflection of different professional experiences. The consequence, however, is that technical professionals naturally think in terms of systems, while end users think in terms of work. A developer sees an object model. A salesperson sees a customer conversation. An architect sees a workflow. A service advisor sees a customer problem that needs resolving before the end of the day. Both perspectives are valid, but they are not the same. The challenge arises when one perspective dominates the design process. This is where the thought experiment becomes particularly interesting. Imagine for a moment that Salesforce had been designed by trainers, behavioural psychologists and frontline workers rather than technical professionals. Imagine that every design decision was evaluated not against technical elegance, but against a single question: does this make the user's day easier? The resulting platform would almost certainly look very different. Rather than presenting users with collections of objects, records and navigation menus, the system would likely be organised around journeys and outcomes. The starting point would not be the data structure. The starting point would be the person's role and the activities they are trying to complete. A salesperson logging in might be greeted with a workspace centred entirely around the flow of their day. Upcoming meetings, customers requiring attention, opportunities at risk and actions needing completion would form the primary experience. The user would not need to think about which object contains the information they require. They would simply focus on what needs to happen next. A customer service advisor might see a completely different experience. Their environment would revolve around customer issues, response commitments, escalations and service priorities. Information would surface according to relevance rather than according to where it happens to reside within the system. Managers would experience yet another perspective. Their focus would naturally centre on coaching opportunities, performance indicators, emerging risks and decisions requiring attention. The system would be organised around leadership activities rather than around data structures. In essence, the platform would adapt itself to the way people actually work rather than expecting people to adapt themselves to the way the platform works. This may sound remarkably similar to some of the ambitions Salesforce is pursuing through Agentforce and Headless360. In many respects, it is. The irony is that I believe Salesforce may ultimately be moving towards exactly the right destination. The challenge is that many organisations have not yet addressed the underlying problem that makes that destination valuable. Headless360 assumes that users want to engage with outcomes rather than systems. I believe that assumption is largely correct. The problem is that most organisations have not yet spent sufficient time understanding what those outcomes actually are. Many Salesforce projects still begin with discussions about objects, fields, permissions, workflows and reporting requirements. Relatively few begin with detailed exploration of how a user's day unfolds. Requirements workshops frequently focus on what information needs to be captured rather than why the work itself is performed. As a result, organisations often create systems that are technically impressive but operationally disconnected from reality. This is one of the reasons trainers frequently identify challenges that project teams miss. Trainers spend their time observing behaviour. We watch users navigate screens. We see moments of hesitation. We hear frustrations. We witness confusion. We understand where confidence drops and where workarounds emerge. Most importantly, we develop an appreciation for the difference between what appears logical on a process diagram and what feels intuitive during a busy working day. The more complex organisations become, the more valuable this perspective becomes. Artificial intelligence will undoubtedly continue to reshape enterprise software. Conversational interfaces will become increasingly sophisticated. Automation will remove many routine tasks. Headless experiences may eventually become commonplace. None of these developments are inherently problematic. The real question is whether organisations understand the humans these technologies are intended to serve. Too often, transformation programmes focus on changing systems while paying insufficient attention to understanding work itself. The assumption is that if the technology is good enough, people will eventually adapt. Experience suggests the opposite is often true. The organisations that achieve the greatest success with Salesforce are rarely those with the most sophisticated technology. They are usually the organisations that possess the clearest understanding of their users. They know how people work. They understand the pressures they face. They recognise where friction occurs. They appreciate that technology succeeds when it complements human behaviour rather than attempting to replace it. This is why I believe every Salesforce project should involve far more observation than it currently does. Developers should spend time shadowing users. Architects should observe operational teams. Administrators should experience the environments they are supporting. Trainers should be involved much earlier in design discussions. Not because technical expertise is insufficient, but because technical expertise alone cannot fully explain human behaviour. Empathy is not a substitute for good design. It is a prerequisite for it. Perhaps that was the real lesson from the discussion at the event. The developer and I were not actually debating the future of technology. We were debating where organisations should focus their attention today. He was focused on where Salesforce is going. I was focused on whether businesses truly understand the people they are taking with them. Both conversations matter. However, if organisations fail to answer the second question, the first becomes significantly harder to achieve. The future of Salesforce may well be headless. It may be conversational. It may be powered by autonomous agents that handle large parts of our daily work. Before any of that becomes meaningful, however, organisations must solve a far more fundamental challenge. They must understand the difference between how systems think and how humans think. Only then can they begin designing experiences that genuinely place people first. And if they do that successfully, they may discover that the future Salesforce is describing feels considerably closer than it appears today.