Stop Guessing Which Process to Automate First

TLDR: Most small and mid-size companies start AI projects by picking processes based on gut feeling rather than data, which is why 74% of them never make it past the pilot stage. A systematic scoring approach — evaluating each candidate process on AI readiness, pain level, strategic impact, and implementation ease — is the difference between a compounding ROI and a stalled initiative.

Summary:

There is a pattern that plays out inside companies attempting AI adoption that is so consistent it is almost boring to describe. Someone in a meeting says "we should use AI for something." The room agrees. Then everyone picks a different process to automate, each choice driven by personal visibility, executive whim, or simply the path of least resistance. Customer support gets the chatbot because it is loud. Reporting gets automated because the CEO saw a demo. Onboarding stays untouched because the compliance team is intimidating.

Six weeks later, the initiative stalls. The technology did not fail — the selection did. A 2024 McKinsey survey found that 74% of companies struggle to move AI pilots into production, and the leading blockers are unclear business cases and misaligned priorities, not technical complexity. That is worth sitting with for a moment. The failure mode is upstream of the engineering entirely.

The argument made here is that you need a scoring rubric applied before a single hour of development time is committed. Not a vague framework, but a specific set of criteria: how AI-ready is the underlying data, how much pain does this process currently create, how tightly does it align to business goals, and how hard is it to actually implement. When you score every candidate process against those four dimensions and rank them in a transparent table, the emotion gets removed from the decision.

The proposed solution is a 5-prompt chain meant to be run in a single sitting inside any major AI tool. The chain starts with a 12-question business diagnostic, moves through process scoring and ranking, deepens the detail on the winning candidate, generates a 7-step transformation guide with named owners and KPI tables, and finally stress-tests that guide for weak spots before you commit. The output is described as a document you hand to your team on Monday morning — not a strategy deck, not a list of ideas, but an actionable plan.

What is notably missing from the visible portion of this newsletter is the actual prompt chain, which is locked behind a subscription paywall. The framing is compelling and the diagnosis is accurate — selection failure is real and underappreciated. But the methodology cannot be evaluated without seeing whether those five prompts actually produce the structured output claimed, or whether they are generic enough that any reasonably specific prompt would do the same job. The McKinsey citation adds credibility, but the 74% figure is about moving from pilot to production, which is a different failure mode than picking the wrong process at the start — so the evidence and the argument are not perfectly aligned either.

Key takeaways:

74% of companies fail to move AI pilots into production, with unclear business cases and misaligned priorities as the primary causes — not technical complexity.
Process selection based on gut feeling or visibility is the most expensive mistake in AI adoption.
A scoring rubric covering AI readiness, pain level, strategic impact, and implementation ease gives teams an objective basis for prioritization.
A structured prompt chain can take a team from "we should do something with AI" to a documented transformation plan in a single session.
The same methodology can be packaged as a consultant deliverable, suggesting real commercial utility beyond internal use.

Why do I care:

As someone who has watched countless "AI for X" initiatives spin up and quietly die inside organizations, the core diagnosis here resonates hard. The problem is never that the technology was wrong — it is that nobody did the boring work of asking which problem was actually worth solving before reaching for the tool. What I appreciate about this framing is that it pushes the conversation upstream, into strategy and prioritization, rather than immediately into implementation details. The scoring criteria proposed are sensible for a senior developer evaluating where to invest automation effort: data readiness matters enormously, because you cannot automate a process that produces inconsistent or unstructured outputs, and strategic alignment matters because the project that saves a junior employee ten hours a week will get cancelled the moment priorities shift. The paywall cuts off the most useful part of this piece, which is a shame — but the diagnostic framing alone is worth the read.

Stop Guessing Which Process to Automate First