We gave one AI model the same strategic business question three times, set up in three different ways, and got three very different answers. A plain AI and an AI with a simple persona prompt both produced balanced, hedged advice. Only a persona built with specific thinking mechanisms produced concrete predictions, dollar figures and things to measure on Monday morning.
What we tested and why
This report lays out what the question was, what each answer said, and why the quality gap between them matters if you are using AI for serious strategic work.
All three versions used the same model, Sonnet 4.6:
- Vanilla AI: the AI answers the question directly, with no special instructions.
- Persona AI: the AI is given a set of rules, built with Impersonato’s own persona construction procedure, that force it to think like a forensic accountant investigating a failure that has already happened. The choice of persona does not really matter here. The experiment shows how different the output can be when a persona is properly constructed.
- Ablated Persona AI: the same persona, but with certain cognitive elements removed, keeping only the general approach. (“Ablation” means removing one part of a system to see whether that part matters.) This is closer to a typical, shallow “prompt engineering” approach. It is the control experiment: it tells us whether Impersonato’s cognitive mechanisms do real work or are just decoration.
The business question: should Rippling launch a fourth product?
Rippling is a workplace software company. Instead of making one product, it builds several connected products (“clouds”) that share data. If you hire someone in the HR cloud, that person automatically shows up in the IT cloud to get their laptop, and in the Spend cloud to get a corporate card. The pitch is that this integration makes the bundle harder to leave than any single-product competitor.
By early 2024, Rippling had three such clouds and was generating $570M in annual recurring revenue, growing more than 50% per year. Each new cloud had crossed $1M in revenue within 5–6 months of launch, which is strong evidence the model works.
The CEO then announced that fresh investor money would fund a fourth cloud in “a completely different area.”
The question: should Rippling keep expanding into a fourth product line, or stop at three and focus on making the existing three more profitable first?
This is a classic strategic tension. On one side, the integrated-bundle story only works if you keep adding to the bundle. On the other side, most software companies that succeeded at scale did so by going deep on one thing, not broad across many. There is no textbook answer.
Answer 1: the plain AI gives a balanced consultant’s memo
The vanilla AI produced a competent, balanced memo. It laid out the case for expanding (the integration advantage is real, slowing down gives ground to competitors like Deel and Ramp, and cross-selling gains compound). It laid out the case against (focus wins in software, the operating team is thin, and public companies at this scale were already profitable). Then it landed on a middle path:
“Proceed with Cloud 4, but with structural guardrails: a dedicated Cloud 4 team… explicit financial targets on the three existing clouds… a pre-committed decision gate at 18 months.”
This is the kind of answer you would expect from a capable generalist consultant after two days of work. It is not wrong, but it is not surprising either, and it does not tell the CEO anything he has not already heard from his board.
Answer 2: the fully built persona predicts specific failures
The output opened with a dated end event, as if the failure had already happened:
“On 14 September 2027, Rippling’s board accepted Parker Conrad’s restructuring proposal: the fourth cloud… was spun out into a separately-capitalized subsidiary at a $180M post-money, down from the $1.1B internal carrying value.”
It then identified three specific mechanisms that would have caused this. Each came with early warning signs that were, in theory, visible; a decision point where another path was available; and a dollar estimate for the cost of the mistake compared with the cost of the fix.
Failure mechanism 1: the cross-sell trap. Selling Cloud 4 to existing customers makes them re-examine their whole contract at renewal. A re-examined bundle almost always loses items, because buyers look for things to cut. So cross-selling the new product causes the old products to erode. The standard metric Rippling’s CRO watches (net revenue retention, measured in dollars) stays healthy because seat counts keep growing. It cannot detect that customers are dropping modules. The signal that would have caught it early: the phrase “let us look at the whole relationship” appearing in renewal call transcripts 3.2 times more often than before. The fix: a separate Cloud 4 sales team for 18 months, costing $14M, against $240M of revenue lost to the re-examination effect.
Failure mechanism 2: the integration tax. Building a financial-services cloud required entirely new infrastructure, because moving money is regulated differently from HR data. This took up 41% of core engineering capacity. As a result, the integration work that made the three existing clouds feel like one product never got built, and customer satisfaction on the existing clouds fell. The decision behind this was a build-versus-buy call in February 2025. Rippling could have acquired a small regulated fintech for $90M that already had the infrastructure. Instead it chose to build in-house on a budget of $38M, and the build actually cost $147M.
Failure mechanism 3: the CEO’s calendar got hijacked. Financial services needs the CEO personally in regulatory meetings with state licensing boards, federal regulators and banking partners. Conrad’s time shifted from 70% product / 30% external to 35% product / 65% external. In the same period, focused competitors shipped features that closed Rippling’s lead in the original three clouds. Nobody at Rippling was tracking the CEO’s time as a budgeted resource. A Chief Operating Officer role to take on the regulatory work existed on paper, was costed at $1.8M, and was not filled.
Instead of a recommendation, the output ended with three specific monitoring tools to set up before starting: a weekly dashboard tracking how many products each customer has, a monthly report on where engineering time actually goes, and a quarterly review of the CEO’s calendar sent to the lead board director. Each costs very little. Each would have caught the relevant failure months before it became irreversible.
Answer 3: the simplified persona drifts back to generic advice
This is the control experiment. We kept the general idea of the persona (“imagine a failure and work backward”) but removed the cognitive mechanisms.
The output opened: “If the fourth cloud underperforms, there is a risk that…”
It identified four risks, and labelled one of them as essentially uncontrollable (macroeconomic conditions). Each risk was described in general terms. The recommendations were to “track retention cohorts carefully,” “hire a strong COO,” and “set quantitative decision gates.” The phrase “there is execution risk here” appeared word for word. That is the exact language the full version was specifically designed to avoid.
Once you strip away the framing, the answer is essentially the same as the vanilla answer.
How the three AI answers differ
Tense and stance. Vanilla and ablated both hedge: could, might, if, would. The full persona commits to a specific dated event and treats it as something that has already happened. This is not a matter of style. It forces specificity. If you have to say “by October 2026, 41% of engineering was on Cloud 4” rather than “engineering resources may be strained,” you have to either invent a plausible number or make a real argument for why that number would come about.
Specific signals versus broad categories. Vanilla and ablated both recommend tracking categories of things: net retention, attach rates, cycle time, survey data. The full persona names specific signals with thresholds: this phrase in renewal calls, this percentage of engineering capacity, this ratio of CEO time. The first set tells you what to care about. The second tells you what to look at on Monday morning.
Dollars on the table. Vanilla and ablated do not put a single dollar figure on the alternative paths. The full persona names $90M (acquire), $147M (what the build actually cost), $14M (separate sales team), $240M (preserved revenue) and $1.8M (unfilled COO). These numbers are estimates, not audited figures. Still, a specific estimate can be checked and argued with, while a vague concern cannot.
The shape of the output. Vanilla and ablated both end with the same recommendation: proceed carefully, hire a COO, set decision gates. The full persona refuses to give a go/no-go at all. Instead it hands the CEO three cheap monitoring tools to set up before deciding, on the argument that the decision itself is fine and what was missing was the monitoring.
What this means for executives using AI for strategy
Removing the mechanisms is the whole point of the experiment. The ablated version kept the general approach of the full persona (think like a forensic accountant, imagine the failure, reconstruct the chain of events), and that was not enough. Without the cognitive mechanisms, the AI drifts back to the same balanced, hedged, category-level answer the vanilla version produced.
The AI’s default mode, weighing pros and cons in the conditional tense, is hard to escape without specific mechanisms that guide how large language models (LLMs) “reason”. Procedures alone (“follow these six steps”) are not enough: the AI will follow the steps and still produce generic output.