You have the mandate. The founder signed it off at the board meeting, probably with some enthusiasm. But three months in, every time you push for a company-wide AI rollout, the conversation drifts. Questions without conclusions. Concerns that stay vague. The founder is engaged enough to have opinions but distant enough that nothing actually moves.
There is a specific fix for this, and it does not involve another presentation or a new budget ask.
Spencer Stuart documented a version of this approach in their CEO power-user playbook, built around a 90-day hands-on agenda. The principle underneath it is simpler than the framework. Automate one of the founder’s own daily tasks first, privately, before anything else happens at a company-wide level. Everything else follows from there.
What is the founder sandbox?
The founder sandbox is a deliberate, private experiment. You automate one of the founder’s own daily tasks before making any company-wide moves. No announcement, no training programme, no budget pitch. You pick a task the founder does every day that costs them real time, build a simple workflow around it, and let them try it on their own terms. Spencer Stuart called this the CEO power-user agenda.
The structure Spencer Stuart describes runs across roughly 90 days, with the first four weeks focused entirely on personal task automation. The objective at that stage has nothing to do with demonstrating ROI to the board or producing a case study. It is about giving the founder a felt experience before they are asked to sponsor anything publicly.
In practice, this might mean building a tool that summarises the weekly board or management pack before the founder reads it. Or a digest of their inbox filtered to the messages that genuinely need their response. Or a first draft of the recurring update they send to investors or the wider leadership team every Friday. The technical complexity of those tasks is low. Their emotional weight for the founder is high, because they happen every day, eat real time, and cannot simply be passed to an assistant.
That is why the sandbox works as a starting point.
Why does a private win convert better than a company-wide pitch?
A company-wide AI push asks a founder to approve something they have not yet experienced. For many founders, particularly non-technical ones, that approval requires visible confidence about a domain where they privately feel behind. The private sandbox removes that pressure. The founder encounters AI as a tool that solves their own problem, in their own time, without an audience. The experience does the persuading.
The psychology here is well-documented in the delegation research. Founders who built success on domain expertise feel exposed stepping into an arena where they are novices relative to their own reports. In investor-backed businesses, where boards monitor everything, that exposure carries a political cost too. A private experiment creates a face-saving entry point. There is no visibility, no risk to status, and no need to project confidence in front of the team.
The change-management evidence makes the mechanism clear. Research consistently shows that technology rarely fails on technical merits; it fails when the human and leadership layer is underestimated. When the person with final authority over an AI programme has a personal reference point for the technology, they advocate for it from experience. A board presentation gives the founder information. A private win gives them experience, and experience is what changes behaviour.
MIT’s NANDA research found roughly 95 per cent of generative AI pilots stall or produce no measurable commercial result. The cause is workflow integration failure, not model quality, which means the human layer is where it breaks. A founder who has never personally used an AI tool for their own work has no context to push through that human layer on behalf of the business.
How do you choose the right first task?
The task needs to meet three conditions. It should be high-friction, meaning genuinely repetitive and time-consuming for the founder. It should be theirs, handled personally rather than delegated to a team member. And it should be low-risk, with no sensitive data, no client exposure, and no decisions with commercial consequences if the output is occasionally off.
Tasks that typically pass all three include a pre-read summary for the weekly board or management pack, a digest of the founder’s inbox filtered to the messages they need to act on, first drafts of the recurring communications they write to investors or the leadership team, or action points from a standing one-on-one series.
Tasks that look right but fall short include market research and competitor intelligence, which is interesting rather than tedious (low friction, high personal investment), strategy inputs where occasional imprecision is unacceptable, or anything that requires the founder to spend significant time explaining their thinking to the AI before it can help.
The selection discipline is to pick the task for founder convenience, not for AI performance. AI performs well across a wide range of tasks. What the sandbox is testing is whether the founder will use a tool consistently enough to form a genuine view of it. A task they actually dislike doing is the one they will reliably return to.
When does the sandbox work, and when does it stall?
The sandbox works when the task genuinely matters to the founder as an individual, when the friction it removes is real and daily rather than theoretical. It stalls when the task was chosen to make the technology look capable, rather than because the founder cares about getting it done faster. The distinction sounds obvious but is easy to miss under the pressure of wanting to demonstrate value quickly.
The other common failure point is ownership. If you build the sandbox yourself and run it on behalf of the founder, it stays your tool, not theirs. The founder needs to use it, even imperfectly, and experience whatever friction or satisfaction that involves. Building it carefully and then presenting the outputs as a polished demo misses the point entirely. What the sandbox is trying to produce is a founder who has personally experienced something working, not a founder who has been impressed by a demonstration.
Timing also matters. Founders in a high-pressure period, a fundraise, a difficult client departure, a senior hire going sideways, will not give a sandbox their attention however well it is designed. Four weeks is short enough that you can usually wait for a quieter window. Starting when the founder is distracted gives you four weeks of polite tolerance rather than a genuine trial, and polite tolerance does not change the dynamic.
What comes next once the sandbox has run?
Once a founder has used an AI tool that saves them real time, the question about whether AI is worth investing in stops being abstract. They have a personal answer. That shift is more useful than any business case document, because it changes where the resistance sits. The founder moves from an observer of the AI programme to someone with a stake in it continuing.
There are two practical follow-through moves worth making in the weeks after. The first is a direct conversation with the founder, acknowledging what worked and what didn’t, then asking whether there are other tasks in their week with the same shape. This is a conversation, not a debrief. The answers will tell you more about where to take the broader programme than any upfront discovery session would have done.
The second is visibility. A founder who uses an AI tool in their own work, even in small ways, sends a signal to the organisation that this is how we work now. You don’t need to manufacture a case study or run an internal communications campaign around it. A founder who is visibly interested in AI because they have found it useful creates adoption momentum that a senior operator cannot create through advocacy alone.
A single private win, handled well, does more for an AI programme than months of company-wide lobbying. That is the point of starting here.
