AI-Native Product Design

Phase 15 · Document 03 · Startup Playbook Prev: 02 — Market Selection · Up: Phase 15 Index

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

You've found the pain (01) and the market (02); now you must design a product, not a demo. This is the doc where the whole technical curriculum (Phases 5–14) becomes product strategy. The defining failure of the era is the thin wrapper: a slick UI over a model API with no defensibility, no trust, and unit economics nobody modeled — it impresses for a week and dies. AI-native product design is the set of principles that turn an LLM from a party trick into a durable product: own a narrow workflow end-to-end, own the system of record or action layer, build evals before you scale, instrument cost from day one, gate high-impact actions with human approval, design for trust and auditability, and use model routing to control unit economics. These aren't nice-to-haves — they are the product and the moat (06).

2. Core Concept

Plain-English primer: the model is an ingredient, not the meal

An AI-native product is built around an LLM's capabilities, but the LLM is one ingredient. The product is the workflow it completes, the data it owns, the trust it earns, and the economics that make it sustainable. A "wrapper" mistakes the ingredient for the meal: it exposes the raw model with a thin prompt and a chat box, owns no data, earns no trust, and has no defense when the vendor ships the same thing. AI-native design is the discipline of making the model disappear into a valuable, defensible workflow.

WRAPPER (dies):     chat box → model API → text out. No workflow ownership, no data, no trust, no cost model, no moat.
AI-NATIVE (durable): own a NARROW WORKFLOW end-to-end → own the SYSTEM OF RECORD/ACTION → evals + cost + approval + trust + routing baked in.

Principle 1 — Don't wrap a model; own a narrow workflow end-to-end

The model is a commodity input (00); your product is the complete job done (01 JTBD). Pick one narrow workflow and own it fully — ingestion, the AI step, validation, the human touchpoints, the output, the integration into where work actually happens. Depth in one workflow beats breadth across many: it's what creates real value, switching costs, and a moat the vendor can't replicate (06).

Principle 2 — Own the system of record or the action layer

The deepest moat is owning where the work lives or what the work does:

• System of record — you become the place the data/state lives (the canonical contracts, the patient notes, the pipeline). Once customers' data and workflow live in you, switching is painful (06).
• Action layer — you own the actions taken in downstream systems (you don't just suggest the email — you send it, log it, and track the outcome, through deep integrations).

Owning one of these turns a feature into infrastructure customers can't easily rip out. A wrapper owns neither.

Principle 3 — Build evals before you scale

The model is non-deterministic; you cannot improve, trust, or safely change what you don't measure (Phase 12). Build the golden eval set and harness early — it's both your iteration engine and a moat (the eval set encodes "what good looks like for this workflow," which is uniquely yours, Phase 12.01). Scaling on vibes leads to silent regressions and lost trust. Evals are a product feature, not just QA.

Principle 4 — Instrument cost from day one

Every LLM call costs money, and naive designs have negative gross margins (05). From the first version, measure cost per request / per task / per user and design to control it (caching, Phase 7.05; right-sized models; routing, below). Retrofitting cost control after you've scaled is painful and sometimes fatal. You can't price or survive what you don't measure.

Principle 5 — Add human approval for high-impact actions

The model proposes; the app (and often a human) executes (Phase 10.05). For irreversible or high-impact actions (sending money, deleting data, emailing customers, clinical/legal output), insert a human-in-the-loop approval gate. This is simultaneously a safety control, a trust-builder, and a product design choice — and for many valuable workflows, "AI drafts, human approves" is the right product, not a limitation.

Principle 6 — Design for trust and auditability

In valuable domains, trust is the product. Users won't adopt (and enterprises won't buy) a black box that's "usually right." Bake in:

• Citations/grounding — show the sources behind every claim (Phase 9.08).
• Explainability — show why the AI did what it did; let users verify.
• Auditability — a record of what happened, for the user and for compliance (Phase 14.06).
• Graceful uncertainty — surface confidence, ask when unsure, fail safe. Trust features are adoption and enterprise drivers, not afterthoughts (Phase 14).

Principle 7 — Use model routing to control unit economics

Not every request needs your most expensive model. Route by difficulty: cheap/small/local models for easy cases, premium models for hard ones; cache repeats; escalate only when needed (Phase 5/Phase 8.05/Phase 11.06). Routing is the primary lever to keep gross margins healthy as you scale (05) — and it lets you adopt cheaper/better models as they ship without re-architecting.

Putting it together: the AI-native product = workflow + ownership + evals + cost + trust

These principles compound. The narrow workflow creates value; system-of-record/action ownership and trust create the moat; evals let you improve safely; cost instrumentation and routing make it economically viable; human approval and auditability make it adoptable in serious domains. A wrapper has none of these; an AI-native product is built from all of them.

3. Mental Model

   THE MODEL IS AN INGREDIENT, NOT THE MEAL. wrapper (chat box→API→text, no workflow/data/trust/cost/moat) DIES; AI-native makes the model DISAPPEAR into a valuable defensible workflow.

   7 PRINCIPLES:
     1. DON'T WRAP — own ONE NARROW WORKFLOW end-to-end (ingest→AI→validate→human→output→integration). depth > breadth [01 JTBD]
     2. OWN the SYSTEM OF RECORD (data/state lives in you) or the ACTION LAYER (you do the action, not just suggest) → infra you can't rip out [06]
     3. EVALS BEFORE SCALE — can't improve/trust/change what you don't measure; the eval set is a MOAT [12/12.01]. evals = a product feature.
     4. INSTRUMENT COST DAY ONE — naive designs = NEGATIVE margins; measure cost/request/task/user [05]; can't price what you don't measure
     5. HUMAN APPROVAL for high-impact/irreversible actions (model proposes / app+human execute [10.05]) — safety + trust + right product
     6. TRUST + AUDITABILITY = the product in serious domains — citations/grounding [9.08], explainability, audit [14.06], graceful uncertainty
     7. MODEL ROUTING for unit economics — cheap/small/local for easy, premium for hard, cache repeats [5/8.05/11.06] → healthy margins [05]

   COMPOUND: workflow=value · system-of-record/action+trust=MOAT · evals=safe improvement · cost+routing=viable · approval+audit=adoptable. wrapper has NONE.

Mnemonic: don't wrap a model — own a narrow workflow and the system of record/action around it; build evals before scaling, instrument cost from day one, gate high-impact actions with a human, design for trust and auditability, and route models to protect margins. The model is the ingredient; the product is everything you build around it.

4. Hitchhiker's Guide

What to look for first: what narrow workflow do you own end-to-end, and do you own its system of record or action layer? If the answer is "we put a chat box on a model," you have a wrapper — redesign.

What to ignore at first: breadth (more features/workflows), model-quality bragging, and chat-as-the-only-interface. Go deep on one workflow with the right (often non-chat) UX.

What misleads beginners:

• Building a wrapper. No workflow ownership/data/trust/cost = commoditized (00).
• Deferring evals. "We'll measure later" → silent regressions and lost trust; evals are day-one (Phase 12).
• Ignoring cost until scale. Negative margins discovered too late are fatal — instrument from day one (05).
• Full autonomy on high-impact actions. Skipping human approval breaks trust and safety — gate them (Phase 10.05).
• Black-box output in serious domains. No citations/audit = no adoption — trust is the product (Phase 9.08).
• One premium model for everything. Kills margins — route (Phase 8.05).

How experts reason: they own one narrow workflow and its system of record/action layer, treat evals, cost instrumentation, trust/auditability, and routing as core product (not QA/ops afterthoughts), insert human approval where impact is high, and make the model an interchangeable input they can upgrade/route. They design so the product gets better and more defensible with use (06), and so the economics work at the planned price (05).

What matters in production: end-to-end workflow ownership, system-of-record/action ownership (moat), a live eval harness, instrumented and routed cost (healthy margin), human gates on high-impact actions, and visible trust/audit features.

How to debug/verify: can you state the one workflow you own and where its data/actions live? Do you have an eval set and cost-per-task number? Are high-impact actions gated? Are outputs cited/auditable? Is more than one model in the routing? If any "no," you're closer to a wrapper than a product.

Questions to ask: what narrow workflow do I own end-to-end? do I own the system of record or action layer? do evals exist? is cost per task measured + routed? are high-impact actions human-gated? are outputs trusted/auditable? could the model be swapped without re-architecting?

What silently turns you into a wrapper: chat-box-on-an-API, no workflow/data ownership, deferred evals, unmeasured cost, full autonomy, black-box output, and a single premium model.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• The model is an ingredient, not the meal — a wrapper (chat box over an API, no workflow/data/trust/cost/moat) is commoditized and dies (00).
• Principle 1: own one narrow workflow end-to-end — depth beats breadth; it's where value and the moat come from (01/06).
• Principle 2: own the system of record or the action layer — turns a feature into infrastructure customers can't rip out.
• Principle 3: build evals before scaling — you can't improve/trust/change a non-deterministic system you don't measure; the eval set is a moat (Phase 12.01).
• Principle 4: instrument cost from day one — naive designs have negative margins; measure cost per request/task/user (05).
• Principle 5: human approval for high-impact/irreversible actions — model proposes, app+human execute (Phase 10.05); often the right product.
• Principle 6: design for trust and auditability — citations/grounding, explainability, audit logs, graceful uncertainty drive adoption in serious domains (Phase 9.08/Phase 14.06).
• Principle 7: route models to control unit economics — cheap/small/local for easy, premium for hard, cache repeats — the main margin lever (Phase 8.05/05).

9. Observations from Real Systems

• The durable AI products own a workflow, not a chat box — Cursor owns the code-editing loop, not "chat about code"; the winners integrate deeply into where work happens (Phase 11).
• Evals-as-moat is real — teams that built golden sets early iterate faster and defend against the vendor; those that scaled on vibes hit silent regressions (Phase 12.01).
• "AI drafts, human approves" is a winning pattern in legal/health/finance — trust + safety + adoption, not a limitation (Phase 10.05).
• Negative-margin AI products are common — startups that didn't instrument cost discovered their per-task spend exceeded their price; routing/caching/right-sizing rescued (or sank) them (05).
• Trust features sell enterprise — citations, audit trails, and confidence cues are repeatedly cited as adoption drivers in regulated buyers (Phase 14).

10. Common Misconceptions

11. Engineering Decision Framework

AI-NATIVE PRODUCT DESIGN (turn the validated pain/market into a durable product):
 1. WORKFLOW: pick ONE narrow workflow and own it end-to-end (ingest→AI→validate→human→output→integration). Not a chat box.
 2. OWNERSHIP: own the SYSTEM OF RECORD (data/state) or the ACTION LAYER (do the action) → switching cost + moat [06].
 3. EVALS: build the golden set + harness BEFORE scaling — iteration engine + moat [12/12.01].
 4. COST: instrument cost per request/task/user from day one; design for control (caching [7.05], right-sizing) [05].
 5. ROUTING: route by difficulty (cheap/small/local ↔ premium), cache repeats [5/8.05/11.06] → protect gross margin [05].
 6. APPROVAL: human-in-the-loop gate on high-impact/irreversible actions (model proposes / app+human execute) [10.05].
 7. TRUST: citations/grounding [9.08] + explainability + auditability [14.06] + graceful uncertainty → adoption in serious domains [14].
 → If you can't name the workflow you own + the data/action you own → you're building a WRAPPER. Redesign.

12. Hands-On Lab

Goal

Turn the chosen pain/market (01/02) into an AI-native product design that applies all seven principles — and explicitly is not a wrapper.

Prerequisites

• The validated pain + ICP/beachhead from 01/02.

Steps

1. Name the workflow: the one narrow workflow you own end-to-end (ingest → AI step → validation → human touchpoints → output → integration). Diagram it.
2. Choose ownership: decide whether you own the system of record or the action layer (or both), and how that creates switching cost (06).
3. Eval plan: define the golden set and the key metric(s) for this workflow — to build before scaling (Phase 12.01).
4. Cost + routing plan: estimate cost per task and design the routing/caching strategy to protect margin (05/Phase 8.05).
5. Approval + trust design: mark high-impact actions for human approval (Phase 10.05); specify the trust features (citations, audit, uncertainty) (Phase 9.08/Phase 14.06).
6. Wrapper check: explicitly answer "what do we own that a chat-box-on-an-API doesn't?" — if you can't, redesign.

Expected output

An AI-native product design doc: the owned workflow, the system-of-record/action ownership, an eval plan, a cost+routing plan, human-approval points, trust/audit features, and a passing wrapper check — ready to scope as an MVP (04).

Debugging tips

• If your design is "chat about X," you have a wrapper — find the workflow and the ownership.
• If there's no eval or cost number, you've deferred the two day-one disciplines.

Extension task

Identify which model(s) each step routes to and the swap plan if a cheaper/better model ships (Phase 5).

Production extension

Carry the design into the MVP (04) and unit-economics model (05); wire the eval/cost/approval/trust pieces using Phases 12/7/10/9/14.

What to measure

Workflow ownership depth, system-of-record/action ownership, eval-plan completeness, cost-per-task + routing, approval coverage of high-impact actions, trust-feature presence, wrapper-check result.

Deliverables

• A workflow diagram (owned end-to-end) + the system-of-record/action ownership.
• An eval plan + a cost+routing plan.
• Human-approval points + trust/audit features + a passing wrapper check.

13. Verification Questions

Basic

1. What's the difference between a wrapper and an AI-native product?
2. Why own a narrow workflow end-to-end rather than offering breadth?
3. What does "own the system of record or action layer" mean?

Applied 4. Why build evals before scaling, and why are they a moat? 5. Why instrument cost from day one, and how does routing protect margin?

Debugging 6. Your product is a chat box over an API. How do you make it AI-native? 7. You discover negative gross margins at scale. What design choices fix it?

System design 8. Design an AI-native version of a document-automation product applying all seven principles.

Startup / product 9. How do trust and auditability features drive adoption in regulated domains?

14. Takeaways

1. The model is an ingredient, not the meal — a wrapper has no moat and dies; AI-native design makes the model disappear into a valuable workflow.
2. Own a narrow workflow and its system of record/action layer — that's where value and defensibility come from (06).
3. Evals and cost instrumentation are day-one disciplines — the eval set is a moat; unmeasured cost means negative margins (Phase 12.01/05).
4. Gate high-impact actions with human approval and design for trust/auditability — often the right product in serious domains (Phase 10.05/Phase 9.08).
5. Route models to protect unit economics — the model is an interchangeable input you can upgrade and route (Phase 8.05).

15. Artifact Checklist

• A workflow diagram owned end-to-end (not a chat box).
• A stated system-of-record / action-layer ownership.
• An eval plan (golden set + metric) to build before scaling.
• A cost + routing plan protecting margin.
• Human-approval points on high-impact actions + trust/audit features + a passing wrapper check.

Up: Phase 15 Index · Next: 04 — MVP Design