Disposable Software: The Missing Fourth Leg of our AI Workplace Productivity Stool
One of our leaders, Ishan Babbar, was facing a time consuming task. One that was going to require analysis of hundreds of data points, across multiple files as well as an understanding of a specific project. The kind of work that, done the traditional way, takes six to eight hours of meticulous, tedious effort, and often requires multiple iterations over the course of a project. He’d done versions of this task many times over his career and knew exactly what was required (and how painstaking it would be for his team).
This time, he spent twenty minutes with an AI developer tool and built something instead.
Not a workaround. Not a script duct-taped together. A purpose-built tool that could be used immediately, could be rerun any time it was needed during the project, and when he wanted a tweak. a different query, an inverse check to QA the output, he just asked, and a few minutes later a revised version was ready. What had previously been a multi-hour task, potentially repeated many times across the life of the project, became a five minute one. And here is the part that stuck with me: the moment the project was done, the tool was done. It was never meant to scale. It was never meant to be handed off. Nobody had to gather requirements for it, future-proof it, or get sign-off on a roadmap. It was paper towel. Use it, throw it away. That was totally ok, in fact, how disposable it was, was a feature, not a bug.
That seems obvious now, but it wasn’t until he showed it to me.
The Three Ways We’ve Been Thinking About AI
Up until this point, our Salesforce practice had been primarily operating with three mental models for AI adoption and utilization.
The first is general productivity; AI that is natively embedded in the tools our team already lives in. Our office suite, Slack, Salesforce of course – the platforms we use every day. Ambient efficiency, essentially. Make it so obvious, embedded and reflexive to use, people stop even thinking about it as AI.
The second is strategic tooling, solutions built with and that leverage AI; designed to be used by multiple team members, repeatedly, for a defined purpose. These require thought, requirements gathering, change management, training, and some degree of future-proofing. They are a mid and/or long term investment. Deployment and adoption takes time.
The third is delivery, AI embedded in our development workflow when we are building solutions for clients. An end to end world (admittedly things aren’t that seamless today, but we get better every day) where AI tools are used to improve requirements gathering, user story creation, testing criteria, development and QA.
All three of these are real, valuable, and we’re continuing to invest in them. But they share a common assumption: that a tool worth building is a tool worth maintaining. That the output and tooling should be something durable.
That assumption left an entire category on the table.
What This Actually Changed
Ishan didn’t need a meeting, planning or any team input to build what he built. He is an expert in the problem he was trying to solve already. He knew exactly what he wanted, he could describe it precisely, and he could ask for it to be built. The fact that it wasn’t perfect on the first iteration didn’t matter, the iteration was cheap. The fact that it wouldn’t work for anyone else’s project also didn’t matter, it wasn’t supposed to. The absence of scalability was a feature, not a failure.
This is a fundamentally different economic equation than anything we’d been applying AI to before. There is no Long Term Cost of Ownership calculation here, because there is no long term. There is no stakeholder alignment required, because the only stakeholder that truly matters in the moment is the person building it.
We are now actively socializing this across the Salesforce practice. The question we are asking the team to sit with is a simple one: Before you spend five or six hours on a task, ask yourself whether you could spend twenty minutes, thirty minutes, an hour even, building a disposable tool to do it instead. Not every task fits. But more of them fit than you would think, and the people best positioned to identify which ones are not our leadership team, they are the people doing hands-on gritty work.
The Part That Should Make Leaders Uncomfortable
There is something worth sitting with here. I did not come up with this. One of our team members did, on a project, because he had the tools and the instinct to use them differently. My only contribution is to try to foster an environment where conditions for it to spread.
That is increasingly what leadership looks like in an AI-forward organization. We can build strategy and set targets, our Salesforce practice’s 5% quarterly efficiency mandate, is an example of that, but the most interesting applications of AI are going to come from people who are deep in the work, not from people who are surveying it from above.
The job of leading a RevOps team, a team of Salesforce Practitioners or a scrappy small team tasked with deploying your organization’s first use cases for Agentforce is to make sure your team has the tools, the permission, and the language to act on what they discover. We made “Disposable Software” part of our vocabulary, that is how it spreads.
