Kill 'Find the Root Cause Yourself' on the AI-Native CSM Scorecard

Chad Horenfeldt published a post this morning on what more than 150 customer success interviews at AI-native startups taught him, and most of it I would hand to a VP of Customer Success without a note. One line in skill one goes on the Kill List, because it describes a seat that costs the company more than the hire it replaces.

The short version

Horenfeldt's post, from 150-plus interviews for CSM and Implementation Manager roles at AI-native startups, lists six skills and eight traits, and almost all of it holds: discovery before solving, "tell me more," commercial judgment, a technical exercise where failing is fine and failing without asking for help is not, live debugging on site because take-homes are easy with AI, and scorecards per role. The line to kill: candidates may need to "find the root cause themselves instead of forwarding the ticket to engineering," with CSMs expected to triage, devise technical solutions, and be proficient prompt engineers. At an AI-native company the root cause lives in the core product, the customer layer, or the customer's data. A CSM who fixes the customer layer is editing the artifact that changes most and goes stale with the next model, without the score, rows, name, and undo that make the change checkable. A CSM who fixes the core is a second forward deployed engineer at CSM pay with no loop back to product. The replacement is three lines: triage to the layer and say which; read the handoff page and name the keys holder at the customer, whose fix it is; know the recall rule. And Horenfeldt's own screening question, pointed at a deployment the candidate inherited.

What he gets right, which is most of it

The post is built on offers, not opinions. Very few decisions, he says, came down to years of experience or logos. What the hires had in common: hands-on technical depth, AI fluency shown by having built something real (an automated QBR generator wired to several APIs, a churn-risk agent, a call-summary workflow), discovery before solving, clear and concise communication, commercial judgment, and building things that scale. Then the traits: high agency, curiosity, comfort with pace and ambiguity, humility and coachability, asking for help early, running toward the company rather than away from somewhere, empathy with a backbone, and self-awareness.

Three details I would copy into any scorecard this week. The most common role-play failure was candidates jumping to the product or a fix before understanding how the customer defines value, and "tell me more" as the underrated phrase. The technical exercise with a twist: failing it is not disqualifying, failing it without asking for help is. And the hiring note that take-homes are easy to complete with AI, so technical skill gets shown live, on-site debugging and live prompting.

His screening question for implementation roles is the best line in the piece: "Walk me through an exact implementation. What did you do, and what did other people on your team do?" The point is how deep the candidate goes, and whether they can separate their work from the team's.

The line that goes on the list

Skill one, hands-on technical depth. Every customer-facing role at an AI-native company is technical, he writes, and the question is how technical. Candidates may need to work with APIs, webhooks, and JSON, read logs, write some SQL or Python, and "find the root cause themselves instead of forwarding the ticket to engineering." CSMs and Implementation Managers were expected to triage issues, devise technical solutions, and be proficient prompt engineers. More technical roles, support engineers or FDEs, handle much of that, and for more technical builds FDEs may be needed.

Kill the root cause line.

A year ago Horenfeldt wrote that forward deployed engineers as CSMs is a trap, because getting into the weeds of solutions takes CSMs away from understanding their customers' outcomes. Month Two: The FDE Leaves, the Workflow Has to Stay agreed with him and put the rule in one sentence: the CSM inherits the page, not the keyboard. The root cause line hands the keyboard back.

Look at where the root cause of a ticket lives at an AI-native company. Three places. The core product, which is engineering's. The customer layer, which in the terms this series uses is the prompts, the configuration, and the eval rows for that one customer. Or the customer's data.

A CSM who fixes the customer layer is editing the artifact that changes most and goes stale with the next model, and "proficient prompt engineer" on the scorecard makes that the expectation. The Prompt Commit: Score, Rows, Name, Undo Under Every Prompt Change is the rule for what has to sit under any prompt edit: the eval score it moved, the rows it was scored on, the name on the change, and the way back. A CSM at 9 p.m. with a frustrated customer on Slack has none of the four. The edit lands, the next model release moves the score, and nobody can say which change did it.

A CSM who fixes the core is a second FDE at CSM pay. When Not to Hire Forward Deployed Engineers: The Honest Cases names the case: the seat only pays for itself if the work comes back through a loop into the product, and "nobody in product will read what comes back" is a reason not to post the req. A CSM who quietly resolves the same root cause for four accounts is the loop not running, invisibly, under a title nobody audits for it.

Why the line is tempting

The number is in Month Two. At day 60 the FDE's attention drops from one of three customers to one of twelve accounts, and the account is now held by someone who, in that post's words, cannot read the configuration. When the ticket arrives, the CSM is the person in the room. Fixing it feels like agency, which is the first trait on Horenfeldt's list, and it is.

Milos Mandic's State of FDE survey, as read yesterday in Milos Mandic Can't Tell From 24 FDEs. Seven of Them Already Answered., has seven of 24 FDEs still holding the systems they shipped after handover and twelve spending more than a tenth of the week keeping delivered systems running. The root cause line moves that tenth onto a cheaper calendar and calls it landing. On The FDE Scorecard: Count What Stayed, Not Who Was Sent, hours per deployment would not fall. They would change cost center.

The three lines that replace it

Triage to the layer. Core, customer layer, or data, and say which in the ticket. That is the technical depth Horenfeldt is right to want, and it is where the CSM's hands stop.

Read the handoff page and name the keys holder. Month Two's page has four lines, and the one that matters here is the keys line: the named person at the customer who can change the customer layer without calling the vendor. The fix on that layer is theirs, with the go-live eval set rerun before it ships, which is the split Kill the Correction Queue: The Agent Lands When the Fix Stops Waiting for Its Builder argued for last week. A CSM who can say the keys holder's name is doing the job. A CSM who is the keys holder is the trap.

Know the recall rule. Month Two's page ends with what brings the FDE back and how fast. Core bug, recall. Customer layer change the keys holder cannot make, recall. Data, the customer's team. The CSM who knows the rule forwards the ticket to the right place, which is not the same as forwarding it to engineering, and is the thing the root cause line was trying to prevent.

Then the interview. Horenfeldt's question is the right instrument pointed at the wrong deployment. For the CSM who will inherit agents: walk me through a deployment you inherited. What did the handoff page say. What did the customer switch off in month two. Who held the keys, and what happened the first time they used them.

Under AI Product Management the claim is that AI collapsed the cost of the parts the job was trained for and left the parts nobody trained for. The CSM scorecard is one of those parts. The old one rewarded the person who could fix it. The new one has to reward the person who knows whose fix it is.

This week: take the last five tickets a CSM resolved on an agent deployment and write three columns, which layer, who should have made the change per the handoff page, and whether the go-live eval set was rerun. If the second column says the CSM's name more than once, the root cause line is already on your scorecard, written or not.

Related answer: Should an AI-native CSM fix the customer's agent themselves?

Sources: Chad Horenfeldt, "What 150+ Interviews Taught Me About Hiring for an AI-Native CS Team," Customer Success & Failures, October 29, 2026, read in full. Chad Horenfeldt, "Forward deployed engineers as CSMs: It's a trap," 2025, as quoted in Month Two. Milos Mandic's State of FDE 2026 survey figures are as read on October 28, 2026 in Milos Mandic Can't Tell From 24 FDEs. Seven of Them Already Answered.. The day-60 ratio and the four-line page are in Month Two: The FDE Leaves, the Workflow Has to Stay.