← All days

Day 32

How to write an AI product strategy that engineers respect and executives fund.

Context

AI product strategy requires answering questions that don’t exist in traditional product management. The four pillars of AI product defensibility: proprietary data (unique training or fine-tuning data competitors can’t replicate), workflow integration (deep embedding in user workflows that creates switching costs), evaluation expertise (knowing how to measure quality in your domain better than anyone), and network effects (each user’s data improving the product for all users). Most AI startups have at most one of these. The best have two or three.

The required strategy question every AI PM must answer: “Why won’t OpenAI or Anthropic build this?” If your product is a thin wrapper around an API call, the model provider can replicate it with a prompt template. Defensible AI products have at least one of: domain-specific data the model provider doesn’t have, deep workflow integration the provider won’t build, or regulatory/compliance expertise the provider can’t easily acquire. If you can’t answer this question convincingly, your strategy needs rework.

The open-source moat question: “If Meta releases a comparable model for free tomorrow, does your product survive?” With Llama, Phi, and Mistral models approaching frontier quality for many tasks, any strategy that depends on model access as a moat is fragile. Your moat must be in the product layer — data, UX, workflow, evaluations — not the model layer. Products that survive open-source competition: those where the model is 20% of the value and the product is 80%.

Vibe-coding compresses time-to-competition. Tools like Lovable, Bolt, and v0 enable non-engineers to build functional prototypes in hours. Strategic implication: if your product’s value is primarily in the UI/UX layer, a competitor can replicate it in days instead of months. This makes workflow integration, proprietary data, and domain expertise even more critical as defensibility — the code itself is no longer a meaningful barrier to entry.

The model dependency map remains essential for strategy. Document every model you depend on, which provider supplies it, what happens if pricing doubles, and your migration path to alternatives. Include: primary model (e.g., claude-sonnet-4-6 for core inference), secondary model (e.g., claude-haiku-4-5-20251001 for classification/routing), embedding model, and any fine-tuned models. This map should be a living document reviewed quarterly.

Build vs Buy vs Partner vs Open-Source is the updated decision framework. Build when you need full control and the capability is core to your product. Buy (API) when speed matters and the capability is commoditized. Partner when you need enterprise distribution. Open-source (self-host) when you need cost control at scale, data sovereignty, or freedom from provider lock-in. Most products use a hybrid: open-source for high-volume low-complexity tasks, frontier API for complex reasoning.

Tasks (4)

  1. Write a defensibility audit (25 min)
    Pick an AI product you use (Cursor, Notion AI, Perplexity, etc.). Score it 1—5 on each of the four defensibility pillars: proprietary data, workflow integration, evaluation expertise, network effects. Where is it strongest? Where is it most vulnerable to OpenAI/Anthropic building a competitor? Save as /day-32/defensibility_audit.md.
  2. Answer the platform risk questions (25 min)
    For your product or a hypothetical AI product: write one-paragraph answers to (1) “Why won’t OpenAI/Anthropic build this?” (2) “If Meta releases a comparable model free, does the product survive?” (3) “If our primary model provider doubles pricing, what’s the migration plan?” Be brutally honest. Save as /day-32/platform_risk_assessment.md.
  3. Create a model dependency map (25 min)
    Document every model dependency: primary inference model, secondary/routing model, embedding model, evaluation model. For each: provider, version string, fallback option, estimated monthly cost, and what breaks if it’s unavailable. Save as /day-32/model_dependency_map.md.
  4. Build vs Buy vs Partner vs Open-Source matrix (25 min)
    For a vertical AI product (legal, healthcare, or finance): identify 5 key capabilities. For each, evaluate Build/Buy/Partner/Open-Source using criteria: control needed, speed to market, cost at scale, data sensitivity, and competitive differentiation. Present as a decision matrix. Save as /day-32/build_buy_matrix.md. Stage and commit your Day 31–32 work.

Interview question

How would you evaluate whether to build an AI feature in-house vs using a third-party API?

I’d evaluate across five dimensions.

Strategic importance: Is this capability core to our product’s value proposition? If yes, lean toward building. If it’s a commodity capability (summarization, classification), buy via API. Core capabilities need control over quality, latency, and iteration speed that APIs constrain.

Data sensitivity: Can we send this data to a third-party? Healthcare, legal, and financial data often can’t leave our infrastructure. This pushes toward self-hosted open-source models (Llama, Phi) or on-premise deployment via AWS Bedrock in the customer’s VPC.

Scale economics: At what volume does self-hosting become cheaper? For most tasks, API is cheaper under ~1M requests/month. Beyond that, self-hosted open-source models on dedicated GPUs often win on cost. Calculate the crossover point.

Iteration speed: Building takes months; buying takes days. For v1, almost always buy. For v2+, build the components where you need differentiation. The mistake is building everything from scratch for v1 and shipping 6 months late.

The open-source factor: Before buying an API or building from scratch, check if an open-source model handles the task adequately. Self-hosted Llama for high-volume classification is often 10x cheaper than an API and gives you full data control.

PM angle

The AI product strategy that gets funded answers three questions clearly: why the model provider won’t build it, why an open-source alternative won’t kill it, and where the defensibility compounds over time. Most AI product strategies fail because they describe what the product does, not why it’s defensible. Engineers respect strategy that acknowledges technical reality; executives fund strategy that shows compounding moats.

Resources