Native Alpha Audit

Use this skill when the user wants to figure out what their organization's real competitive advantage is, run a "Native Alpha audit," find out whether a claimed strength is actually evidence-backed, or produce a current, defensible statement of what the…

This skill is Labor as Code™ for the "find" half of Chasing Native Alpha's method: establishing a benchmark, building a rigorous Native Alpha claim, and tracing where the claimed advantage actually lives in the organization. It generalizes the book's own worked examples (the digital health company's implementation speed, the care management company's follow-through) into a repeatable audit for the reader's own organization — it does not retell those examples, and it never invents an org's advantage where the evidence doesn't support one. Where the book leaves a judgment call to the reader that depends on facts only they hold — which outcome to investigate, what actually happened in a given quarter — this skill asks the question and records the answer the human gives; it never guesses one to keep moving. But once the evidence is assembled, the skill states its own read of what that evidence shows, with its reasoning - that reading is what Step 5 exists to produce.

Native Alpha is the advantage a person, team, or company already has — legible, credible, useful, durable — never invented or narrated into existence where the evidence doesn't support it. This skill exists to find that advantage where it is real, and to say plainly when the session cannot find it.

Before running

Confirm with the user, in plain conversation, before starting the audit:

1. Which organization, product, or team is under audit — a whole company, a single product line, a team's own working method. The audit narrows fast; a vague scope produces a vague claim.
2. Who is in the room, or should be consulted before the claim is treated as final. The book's own rule: bring the claim to someone in finance, someone closest to the customer, and someone who operates the capability, and do not average their answers when they disagree — investigate the disagreement. This skill cannot talk to those people; it can only tell the user which questions to bring to them and flag where the session's own inference needs their correction.
3. What evidence already exists (customer interviews, retention data, usage data, financials, support/incident history) versus what will have to be gathered fresh. Do not let the session invent numbers it wasn't given.

Step 1: Choose the outcome and name the reasonable alternative

Ask the user to pick one to three consequential outcomes — results that matter to customers or the business, not engineering-only outputs (release frequency and cycle time may explain an outcome; they rarely settle whether it's alpha).

For each outcome, establish the benchmark before anything else. This is the book's own warning: "the easiest way to manufacture alpha is to compare against an alternative nobody would actually choose."

• What is the reasonable alternative — a competitor, a substitute, a customer workaround, a commodity service, the organization's own prior performance, or an AI-enabled new entrant?
• Would a different, more skeptical benchmark reverse the conclusion? If the user can't answer this, the benchmark isn't settled yet — ask again rather than proceeding on a soft one.
• Competitors are the weakest benchmark. If the only comparison on offer is "we're better than Competitor X," push back: ask what customer outcome improved because of the difference, and how the user knows. A competitive comparison alone is not evidence of alpha.

Where useful, run more than one comparison side by side (internal — versus our own history; market — versus credible competitors; substitute — versus the customer's actual alternative, including manual work; frontier — versus what a capable new entrant could assemble today with AI). Use the comparison that would actually change a funding decision, not the one that flatters the claim.

Have the user fill in this sentence exactly, word for word, without "innovative," "leading," "proprietary," "world-class," or "best-in-class":

The outcome we produce is ______.
The reasonable alternative produces ______.
The measurable difference is ______.
We believe the difference comes from ______.
The evidence that would prove us wrong is ______.

If the third blank is empty, this is a capability claim, not an alpha claim — stop here and say so rather than continuing to Step 2. If the fifth blank is impossible to answer, flag it as an article of faith, not evidence.

Step 2: Build the four-part Native Alpha claim

Every real Native Alpha claim needs all four parts. Walk the user through each one and refuse to move on if a part is missing — naming a resource ("we have excellent engineers") is not an outcome; naming a sentiment ("customers love us") is not a benchmark.

Test the draft claim against the book's own catalog of ways organizations manufacture false confidence — flag any of these the user's evidence resembles, and ask for the harder version instead of letting it stand:

• Benchmark shopping — comparing against an obsolete internal baseline or a weak competitor instead of the reasonable alternative available now.
• Hidden exposure — crediting the capability for a result actually produced by a favorable market, a regulatory deadline, an unusually easy customer segment, extra headcount, or concentrated risk.
• Short windows / survivorship bias — one good quarter, or a sample that only includes the customers, products, or experiments still around to be counted.
• Gross alpha — ignoring maintenance, review, support, failure, switching cost, and opportunity cost.

Step 3: Trace the claim through the organization

For a small organization, trace backward from the end customer — few layers separate the work from the result. For a larger organization or business unit, trace the contribution forward through every internal handoff to the enterprise or end-customer outcome, and do not let two units claim the same result without an attribution test.

Build a one-page map connecting:

Circle only the systems that directly carry the distinctive mechanism. Everything else still has to work, but it does not automatically earn strategic treatment — say this explicitly if the user's first draft circles "everything we're proud of" (the book's own observed failure mode).

Step 4: Surface hidden assets, don't just inventory the obvious ones

Ask what advantage might be sitting in a person, a relationship, or operating history rather than a system diagram. For each candidate, capture:

List no more than ten candidates. Do not turn this into a knowledge-management project — the book's instruction is to start with the two assets whose loss would change an important outcome fastest, and stop there.

Step 5: State the current position — and say what's still just narrative

Close the session with a short, honest statement, not a pitch:

• What we believe our Native Alpha is.
• What outcome and benchmark support that belief.
• What is genuine evidence versus what is still a plausible story awaiting a test.
• What would change our mind.

Then state the skill's own read, built from the four-part claim (Step 2), the trace (Step 3), and the evidence gathered along the way: does this rise to a defensible Native Alpha claim, is it still a capability claim short of alpha, or is the evidence genuinely split between two readings (for example, finance's numbers and the customer-facing evidence point to different sources for the same outcome)? Say which, and cite the specific evidence the read rests on - a claim earns "yes, this is Native Alpha" only when all four parts (outcome, benchmark, source, evidence) hold and the threat is named; anything short of that gets named as a capability claim or an open gap, not rounded up.

What this skill does not do

This skill never invents an organization's Native Alpha where the evidence doesn't support one, and it never lets its own stated read override people with first-hand knowledge the session doesn't have: finance, the customer-facing side, and the people who operate the capability get the final say, informed by this skill's read, not overruled by it. If the evidence is thin, the correct output of this skill is "you have a capability claim, not an alpha claim, and here's the gap" — not a confident-sounding advantage invented to fill the silence. If people in the room genuinely disagree about the source of the difference, and their disagreement traces to facts this skill cannot adjudicate (who saw what, when), the skill's job is to preserve and present that disagreement as live, named alternatives - not smooth it into a single verdict neither side's evidence actually settled.