Yesterday, Salesforce and Anthropic announced Claudeforce.
Salesforce’s CRM data now lives inside Claude. It launches with 37 prebuilt sales skills covering things like meeting prep, deal health review, and pipeline review. Pilot customers have it now, open beta in September, and more functions beyond sales later this year.
Most of the coverage is calling it a productivity story. Users get answers faster. They spend less time navigating the CRM. They don’t have to hunt through reports and screens to find what they need. I think it’s something else.
I think it’s one of the clearest previews yet of what is coming for almost every knowledge-work role.
Because something fundamental is changing about enterprise software: The menu is disappearing. And when the menu disappears, the skill that matters changes.
How enterprise software worked so far
For thirty years, adding functionality to enterprise software required engineering. That was expensive. So every request from every customer went through a brutal prioritization filter, and only a small fraction survived it.
What survived got built. It became a screen, a menu item, a standard report, a workflow.
Think about what that means for the person using the software. Someone else did the hard thinking - a product manager somewhere looked at a thousand requests and decided which twenty questions were worth being able to answer. Those twenty became the menu.
By the time the software reached the user, the judgment had already been exercised. The user’s job was to know which menu did what. Where’s the pipeline report? Which screen updates the close date? What’s the fastest way to get to the account history? Which dashboard should I look at before my customer meeting?
That’s a real skill. But it was primarily an efficiency skill. Two people in the same role differed mostly in how fast they could navigate. The ceiling was the same for both of them, because the ceiling was the menu.
What changes now
When you can ask for any report instead of picking from the reports that exist, the standard reports start to matter less. So do the standard workflows. Over time, a lot of them will disappear.
But something else disappears with them: the centralized prioritization filter.
That filter didn’t actually vanish, it just moved to a different spot in the command chain. It used to happen once, centrally, in a product planning meeting. Now it happens thousands of times a day, at the individual level, every time someone decides what to ask.
Which means that for you as a user, the ceiling is no longer the menu. The ceiling is the quality of the question you ask.
What This Does to Jobs
I want to spend a minute here, because I think this part is underrated. Almost everything we built around knowledge work assumed the question was already given. The software gave you the menu. Your manager gave you the goal. Your job was to navigate from one to the other.
Now the menu is disappearing. And that has consequences far beyond the software itself.
Job descriptions assumed it. “Proficient in Salesforce” was a real requirement that meant something specific: this person knows where things are and how to get things done in the system. That sentence is about to mean much less. When there is no longer a fixed “where,” anyone can learn the interface in an afternoon.
Onboarding assumed it. Two weeks of systems training, then you’re productive. But those two weeks were largely teaching someone else’s prioritization decisions, encoded as screens, reports, and workflows. When the screens go away, what exactly are you onboarding people into?
The answer has to become context, not navigation.
What matters here? What have we tried? What does the customer actually care about? Which signals matter and which don’t? That knowledge is much harder to transfer than “click here, then click here.” And almost none of it is written down.
Performance measurement assumed it. Calls made. Tickets closed. Records updated. Reports produced. These metrics measure throughput through a fixed workflow. They were reasonable proxies when everyone was doing essentially the same work at different speeds. They’re going to become increasingly misleading. Because two people can produce identical volume and wildly different value when the system no longer determines what work gets done.
Seniority assumed it. A surprising amount of what we called experience was accumulated menu knowledge. The person who knew the weird path for an edge case. The person who remembered which report you actually had to pull because the obvious one was wrong. The person who knew exactly which sequence of screens would get you to the answer. That knowledge is depreciating fast. Domain judgment is doing the opposite.
And then there’s middle management. A lot of management work has involved translating a goal into a set of tasks and workflows: here’s what needs to happen, here’s who does it, here’s the process, here’s how we’ll measure it.If an individual can increasingly go from goal to output directly, that layer has to justify itself differently. Not disappear. Justify itself differently.
The manager’s value shifts from distributing work to providing context, setting priorities, making trade-offs, developing judgment, and creating the conditions for good decisions. And that brings me to what I think is the biggest consequence of all.
The variance inside a single role is about to get much wider.
Imagine twelve people in the same role, with access to the same tool and the same data.
One asks:
“Give me a list of my highest-revenue accounts.”
Another asks:
“Which accounts that were highly engaged six months ago have gone quiet, what changed in their behavior, and which three should I intervene on this week?”
Both may get a good answer in ten seconds. Their output is not going to look the same at the end of the quarter. And the difference won’t have much to do with how quickly either person can navigate Salesforce. It will come down to what they thought to ask, why they thought it mattered, and what they did with the answer. That’s judgment.
For most of the history of knowledge work, the software did some of that thinking for us. It constrained the questions, standardized the workflows, and quietly embedded someone else’s prioritization decisions into the tools we used every day. As those constraints disappear, the difference between people doing the same job is going to become much more pronounced.
Execution efficiency was the differentiator for a long time. It is about to stop being one.
The unfortunate part is that judgment isn’t something most roles were designed to develop, because the software had already done much of the choosing. Now that execution is becoming abundant, judgment is becoming scarce.
So what do you actually do about it? How do you transform yourself to operate and succeed in your career going forward? Here are five things that I would recommend:
A shameless plug - I teach these practices and several frameworks that are essential going forward, in my AI Strategy Masterclass, a five-week certification course for senior leaders. Next cohort is starting October 3rd.
You’ll learn how to find the problem worth solving instead of the one you were handed, how to pressure-test a decision with mental models that surface what everyone else is missing, how to make trade-offs and say out loud what you’re refusing to do, and how to build the case that gets a decision funded.
It’s judgment, taught as a set of frameworks you can use on the decisions you’re already responsible for. Join me and learn the skills you need to grow in your career.
1. Start from the decision, not the request
Situation. Someone drops a request on you, or you sit down in front of the tool yourself. The old instinct kicks in: find the report that matches the request. The menu trained you to do this for years, and it worked, because the menu had already narrowed the field to things worth asking.
Task. Find the actual problem before you produce anything. The request you were handed is a symptom of a decision somebody needs to make, and it is frequently the wrong articulation of it.
Action. Before you ask the system anything, write one line naming the decision the answer will change. If you can’t name one, stop. You’re producing an artifact, not doing work.
Then walk the request up a ladder, three steps minimum:
What was I asked for?
What is that a symptom of?
What decision would actually change if I understood that better?
An example. “Pull churn numbers for Q3” is the request. The symptom underneath is that somebody is worried about renewals. The decision underneath that is whether to move resources onto retention this quarter. That last version tells you to look at something entirely different, probably leading indicators in accounts that haven’t churned yet.
Do this out loud with your team for a few weeks. It feels slow. It stops feeling slow around week three.
Result. You stop being the fastest person at answering the wrong question. Your team starts arriving with problems instead of requests, which is the change you actually want.
2. Ask what got cheap, and what got valuable
Situation. A new capability lands in your function. Everyone’s first reaction is to ask what it can do. That’s the wrong first question, because the answer is always “a lot” and it doesn’t tell you anything you can act on.
Task. Locate where the advantage moved. Any time something becomes free, something adjacent becomes scarce. Find the pair and you’ve found where to point your team.
Action. Sit down with two columns. On the left, what just got dramatically cheaper in your world. Be specific. Not “analysis.” Which analysis, done by whom, that used to take how long.
On the right, what does that make scarce? The test for the right-hand column is whether it’s something the tool can’t produce.
Here, reports got free. So what’s scarce? Knowing which report matters. Knowing what to do about the answer. Having context about the customer that isn’t in any system anywhere.
Then do the thing most people skip, which is act on it. If your team’s time was going into the left-hand column, it needs to move to the right-hand column. That’s a reallocation decision, and it’s yours to make.
Result. You get a defensible answer to “where should my team spend its time” that isn’t based on what they happen to be good at today. And you get an early read on which of your team’s skills are appreciating and which are depreciating, which is information you owe them.
3. Work out what the old workflow was doing that nobody noticed
Situation. Standard reports and workflows start getting replaced by ad hoc queries. Everyone treats this as pure upside. More flexibility, less rigidity, faster answers.
Task. Find the second-order effects. The standard report had a hidden job nobody wrote down, and it goes away silently.
Action. Here’s the hidden job. Everybody ran the same report, so everybody’s numbers meant the same thing. Pipeline meant one thing. An at-risk account meant one thing. Active user meant one thing. The definition was baked into the query, and nobody had to agree on it, because nobody could change it.
Now everyone generates their own version. Four people bring four numbers to your Monday meeting. All four are correct. None of them match.
So do this. List the five to ten terms your team makes decisions on. Pipeline, qualified, at risk, active, churned, whatever they are for you. For each one, write down the definition the old report was using. You’ll find that some of them nobody actually knows, which is itself worth knowing.
Then decide which definitions are shared and which are personal. Shared ones get written down and everyone uses them. Personal ones are fine, as long as people label them when they bring a number into a room.
Result. You keep the flexibility without losing the shared vocabulary. And you avoid the meeting where forty minutes goes into reconciling numbers instead of deciding anything, which is a meeting I promise you are going to have otherwise.
4. Draw the line between recommending and doing
Situation. These systems don’t just answer questions anymore. They take action. Updating records, sending things, moving work along a pipeline. That’s a different category of thing, and it usually arrives without a corresponding decision about governance.
Task. Decide, explicitly, where the machine acts on its own, where it recommends and a person signs, and where it doesn’t touch anything at all.
Action. Take the actions the system can perform and sort them into three buckets. Machine decides. Machine recommends, human approves. Human only.
The sorting rule I’d use is reversibility. If the action is easy to undo and low stakes, let the machine do it and stop spending human attention on it. If it’s hard to undo, or it’s visible to a customer, or it commits money, it needs a human in the loop no matter how confident the system is.
Then ask the harder question for each item in the middle bucket: what does approval actually mean here? If a person clicks approve on forty recommendations a day without reading them, you don’t have a human in the loop. You have a human in the way, which is worse than either alternative, because it creates the appearance of oversight without the substance.
Write the whole thing down. One page. Revisit it when the capability changes, because it will change and the line should move with it.
Result. The line gets drawn deliberately by someone accountable, instead of being set by whoever configured permissions on a Tuesday. Which is what happens by default, and it means a technical decision quietly stands in for a judgment call.
5. Check whether your picture of the tool is current
Situation. You’re making decisions about where AI fits in your organization. Those decisions rest on a picture of what it can and can’t do. That picture came from somewhere, probably a demo you saw, an article you read, or a pilot that disappointed you eleven months ago.
Task. Find out whether the picture is still accurate. This cuts both ways, and being wrong in either direction is expensive. Overestimate and you commit to something that doesn’t work. Underestimate and you defend a position that’s already gone.
Action. Two things, one internal and one external.
Internally, the workflows you’re replacing encoded assumptions about your business from whenever they were built. Nobody wrote those assumptions down, because they never had to be stated. Before you replace a workflow, ask what it assumed was true. Sometimes it’s still true. Sometimes it stopped being true in 2022 and you’ve been optimizing against it since.
Externally, once a quarter, block ninety minutes and actually test the thing you assume the technology can’t do. Not read about it. Not delegate it. Sit down and try it yourself. Write the date next to your conclusion, because the conclusion has a shelf life and you want to know when it was formed.
Result. Your strategy rests on the current state of the world rather than a memory of it. That sounds obvious. In practice, most AI strategy I see is built on a picture that’s twelve to eighteen months stale, and nobody has checked, because checking wasn’t anybody’s job.
Where this goes
Claudeforce is a sales tool today. It won’t stay one. The same pattern is coming for finance, operations, support, HR, and everything else that currently runs on somebody else’s menu.
When it arrives in your function, the question won’t be whether your team can use it. They’ll figure that out in an afternoon.
The question will be whether they know what to ask for. And that is a very different skill from knowing how to navigate a system.
The menu is disappearing. The judgment is coming back to the human.