Singles or Home Runs? The Question Every AI Initiative Should Answer First

Every organization right now — large, small, public, PE-backed — is under pressure to swing for the fences with AI. The hype cycle rewards bold claims and transformational announcements. Patience looks like falling behind.

That pressure is forcing a strategic bet most organizations don't realize they're making: should we be swinging for a home run, or banking a single? Most are answering that question by default, swinging big because the moment demands it, without ever diagnosing whether the conditions actually support it.

That diagnosis depends on three things, and almost every failed initiative I've seen got at least one of them wrong. First, the market: is the need already established and understood, or still being discovered? Second, the users: do we actually understand what they need, including the needs they've never articulated themselves? Third, organizational capability: does the team have the structural muscle, the methodology, the accountability, the sustained commitment, to deliver a home run even if one is warranted?

The market question gets the most attention. The other two are where most of the real damage happens, especially on internal-facing initiatives, where "they're our own employees, we already know what they need" feels true and usually isn't.

When the market hasn't been created, and the users were never understood either

An investor-backed industrial AI venture believed it was racing to capture an established market before competitors got there first. Multiple product variants were built simultaneously, each a bet on a different version of what the market might want, all pursued at once because the assumed window to capture share was closing.

The market diagnosis was wrong: the market hadn't been created yet, and the proliferation of variants was creating confusion rather than optionality among the early adopters willing to engage.

But the user diagnosis was wrong too, and it compounded the problem. The product had been built largely around how internal experts understood the underlying process, not around how the actual intended users experienced or needed it to work. That's a common and dangerous shortcut: the people closest to the technical problem assume their own mental model is the user's mental model. It rarely is. The result was a product that made sense to the people who built it and confused the people it was meant to serve, layered on top of a market that hadn't decided it wanted any version of this yet.

The fix addressed both failures together: portfolio rationalization to stop the variants that didn't meet a validated threshold, and a reset of the development process to ground product decisions in observed user behavior rather than internal expertise.

Result: $10M+ in finance-validated annual cost reduction. Delivery cycle compressed from 18 months to 3 months.

When the users are right in front of you, and still misunderstood

This same failure, assuming internal familiarity equals user understanding, shows up even when the market and the organization are mature. At a global consumer goods business, the first attempt at automating order management wasn't actually an AI system. It was a set of predefined templates mistaken for one, and it broke with the slightest variation in real-world inputs, because real orders never arrive in the clean, consistent format the templates assumed.

The team had documented the process. They had not observed how the process actually varied in practice, order by order, customer by customer. Once that gap was identified, the requirements were rebuilt around a true AI system, one designed to learn and adjust through deliberately engineered human-in-the-loop feedback mechanisms rather than rigid rules. That redesign gave the system the ability to handle natural process variation instead of breaking on it, and gave users enough confidence in the tool to actually rely on it. That confidence was the real unlock: it created a credible path to the throughput improvement and effort savings the business was originally trying to achieve, which the templated version had never been capable of delivering regardless of how it was tuned.

Known users, long operating history, and the assumption of understanding was still wrong until someone went and rebuilt the system around how the work actually varied.

When the market and users are proven, but the organization hasn't built the capability to swing big

A major North American consumer lending business had a different version of the same problem. The market and field sales user base weren't in question. But what the team had been delivering, in response to a steady stream of field feedback, was a string of small, responsive improvements, not because that was genuinely what the business needed, but because that was what the organization had learned how to deliver.

The development team was running Kanban, a methodology that allows priorities to shift daily or weekly in direct response to whatever the field was asking for that week. That responsiveness felt like good listening. It was, in a narrow sense. But it meant the team was solving for what users were asking for rather than what would actually change their ability to perform, the same trap as building from internal assumptions, just dressed up as customer-centricity. Leadership's complaint was that the program kept delivering small improvements with no game-changers, and the diagnosis underneath that complaint was that nobody had stepped back to ask whether the requests themselves represented the real opportunity.

The fix was structural, and it had two parts. The first was methodological: moving the team from Kanban to Scrum, trading the comfort of constant responsiveness for the sustained, multi-sprint commitment a genuinely bigger outcome required. The second was about whose input actually shaped the work. The team had been listening primarily to the best performers and the loudest voices, the people most likely to ask for things and most confident asking for them. We deliberately rebuilt the input group to include high and low performers, metro and rural markets, tech-savvy users and skeptics alike. The people who had mastered the existing workflow had the most to unlearn and the least motivation to do it, and designing around their feedback alone would have optimized for the wrong baseline. The full distribution surfaced needs that the most vocal users had never thought to mention, because their workflow had already adapted around the gap.

Result: The platform redesign delivered within nine months. 1.5 hours of daily planning time returned to every field associate. The implementation was recognized as best-in-class, with an invitation to present at Dreamforce. Proving the organization could deliver a home run on this platform built the credibility and confidence to make a bigger bet on the next one, a separate initiative that went on to deliver a 13% improvement in sales funnel pull-through. The first win didn't just produce its own result. It changed what the organization believed it was capable of attempting next.

Why this matters right now

Most organizations today are running multiple AI pilots simultaneously, and a meaningful share of them are failing. The instinct in that environment is either to retreat from AI investment entirely, or to force the next attempt to be the home run that proves the technology works. Both instincts are wrong.

The organizations building real AI capability right now are deliberately banking singles first, smaller, well-diagnosed initiatives that build the organizational muscles a home run actually requires, before attempting the bet that demands sustained commitment and real risk. That sequence isn't caution for its own sake. It's the only way to build the capability a home run depends on.

It's also worth saying plainly: doing this the right way is not slower. Every example above, the market and user diagnosis at the industrial AI business, the rebuilt AI system at the consumer goods business, the methodology and input redesign at the consumer lending business, was delivered in six to nine months, start to finish. The diagnosis isn't the delay. Skipping it is what produces the delay, just later, after the rework starts.

The lesson for PE sponsors and operating partners

This diagnosis matters most in mid-market, PE-backed transformations, because the hold period removes the runway that large corporates have to recover from a misdiagnosis. A portfolio company that swings for an AI home run without validating the market, the users, and its own organizational capability burns capital and time it cannot get back.

Part of why this diagnosis goes wrong so consistently is who's making it. Executives often greenlight AI investment based on strategic ambition, with limited grounding in whether the market or the user need has actually been validated. IT often builds based on technical feasibility, with limited visibility into whether the business problem is real or whether the team has the operating muscle to deliver at scale. Neither view alone is sufficient. The correct diagnosis requires combining strategic intent, user observation, and an honest read of organizational capability, assessed together rather than handed off in sequence.

The question every operating partner should ask before approving the next AI initiative isn't "how big should this bet be." It's "have we actually validated the market, the users, and our own capability to deliver, or are we assuming all three, and how long should that actually take?"

Part of a series on value creation in PE-backed businesses. It builds on my earlier pieces: transformation starts with the right question, complexity is a margin problem, portfolio discipline determines what gets built, and clarity about your starting point comes before any of it. This applies the same principle one level deeper: knowing where you stand, on the market, the users, and your own organization, determines how hard you should swing, and getting that right doesn't cost you the time you think it does.