How Spoon Theory informs software design

This is a guest blogpost by Jennifer Sherman, Chief Product Officer, Unit4.

My partner has had six knee surgeries in our 12 years together.  This means that I, someone whose biggest physical injuries in life have been a stubbed toe and a couple of slips and falls, have learned a lot about pain management in the last decade.  There is one concept that has arisen from the world of pain management that I think everyone could benefit from understanding and using in how we think about the role of technology in our work; and that is the notion of spoon theory.

Originally developed as a communication analogy for pain management in healthcare settings, a spoon is an arbitrary unit of measure for energy.  Each of us has a certain number of spoons of energy every day. Every task requires a certain number of spoons for completion. As you go through the day completing tasks, the goal is to preserve energy by managing the number of spoons spent.  This feels like a weird but compelling goal framework for design teams who want to deliver functionality that allows users to complete tasks with minimum effort.

The challenge in traditional enterprise resource planning (ERP) is that users have always had to spend too much mental load interacting with applications. This is because they are designed to be horizontally applicable to as broad an audience as possible – for example, HR or finance professionals – without regard to the nuanced differences that their operating environments bring to their days. The result is very generic software that struggles to bring real efficiency gains and spoon savings. In fact, I left the world of ERP some years ago because I thought that it took vertically oriented applications (those that understand not just your role but your business context) to really improve the experience of work for people.

ERP should be a low spoon endeavour

Here I am, back in the world of ERP but only because I see the opportunity for verticalised ERP players to use AI technologies differently; in a way that can significantly improve what the ERP can do for its team.  ERP finally has a shot at becoming a less spoon intensive endeavour.

The goal of product design is to support users to do their jobs at greater scale, velocity and with richer insights. The good news is that innovation is making it possible to fulfil this while minimising the effort on the part of the user, but it is not achieved overnight. It is an iterative process. For example, imagine integrating a conversational AI tool into workflows around project management tasks:

In the first instance the user could ask the AI agent questions such as: “How’s my project doing? Am I on budget?”

The AI agent might respond by saying, “You’re doing good, but it’s running a little late.”

The user could probe this response and in the process build-up the AI’s learning: “What if I added Julia to the project? Based on her billable rate would I catch up but also remain under budget?”

The AI might confirm this is a good decision as Julia knows the client. In this scenario, the AI is beginning to earn the user’s trust, which is critical.

In subsequent product design stages, AI agents can execute whole strings of workflows:

For example: “Good morning, I’ve been watching your projects, and it looks as though this one is going to be late, but Julia is available and she’s worked with this client before and you would still be under budget. Would you like me to go ahead and add her to the project?”

Or… “I see you have had a resignation, would you like us to raise a job req?”

Or… “I see you have had a resignation, but I notice that person was not utilised so you do not need to raise a req. Would you like to use that resource for something else?”

In these scenarios, the ERP is working directly with agents that go out and complete tasks, then report back to the user.

The meaning gap

Now for an ERP to really remove that mental load from the user, it must be able to understand the meaning behind its own tasks like the user can.  It must reason like each team member reasons.  AI-enabled workflows layered on top of an ERP will only get you so far.

I reach for an example from my childhood here. We were staying in a hotel in India, and at check-in the staff told us that we might not want to leave our windows open if we had food in our rooms. No explanation. We heard the instructions, didn’t think much of them, and stood by helplessly one morning while our room was raided and ransacked by a horde of monkeys after our room service.

The staff gave us rules. What they didn’t give us was understanding. If we had known there were fearless monkeys in the area that would climb through open windows to find food, we wouldn’t have needed the instructions at all. We would have reasoned our way to the right behaviour.

ERP has worked the same way for decades. Rules, workflows, validations, screens. The system tells you what to do and stops when you don’t comply, but it doesn’t understand why. It cannot reason about what should happen next, adapt to a situation it isn’t designed for, or anticipate what you need before you know to ask. That cognitive work lands on you, the human, who supplies the meaning the software lacks. Every spoon spent on that translation is a spoon not spent on higher value work.

The case for vertical understanding

This also explains why broad, horizontal ERP design has always been a spoon problem.

Public sector organisations manage grants that carry the weight of promises and statutory obligations. Professional services firms run projects that are contractual commitments and reputational assets. Nonprofits carry donor intent that shapes every allocation decision. Encoding those distinctions is what turns a general-purpose system into one capable of reasoning about the work. The depth of domain understanding determines the depth of reasoning.

That is the direction enterprise software is heading: AI creates the conditions for software to operate with genuine understanding of the industries it serves, and the technologists who are asking how deeply they can encode that understanding are the ones building systems that will matter.

ERP as a member of the team

Spoon theory brings useful precision here. Our goal is not just efficiency but also a meaningful reduction in effort. There are plenty of automation tools, but I predict that next generation AI-enablement in ERP will be owned by those who ask, “Where is the cognitive load being carried, and what can we do about that?”

For most ERP users, the answer is that they are still doing translation work. Converting business reality into system language. Bridging what they know about their work and what the software can represent. That is where spoons are lost, and solving it requires a different kind of software than most organisations are running today.

The teams I think about are not looking for a better interface to the same system. They want a system that has done enough research, option weighing, risk analysis so that they can focus on what actually requires their judgment. The finance professional should not be spending energy on bank reconciliations. She should be deciding whether the organisation is working with the right suppliers. The HR professional should not be opening requisitions. She should be thinking about the skills the organisation needs to build.

That shift, from working in the business to working on the business, is only possible when software understands the business deeply enough to carry the rest.

When ERP gets there, it stops being a system you operate and becomes something that works alongside you. The spoon spend drops, and for the right reasons. Tasks that once required sustained human attention get handled by software that understands enough to handle them well. What remains is the work worth doing; the work of the mission. That is what this transformation is really about, and we are just at the beginning of it.