Chapter 1: Model Families and the Competitive Landscape — The PM Version

Introduction

In Module 01, Chapter 11, we closed the mechanics loop: cutoffs, private knowledge, reasoning limits, and why the product stack must own truth — not the model alone.

This module shifts from how models fail to which models you pick and what that choice costs. You do not need a favorite lab. You need a decision framework that survives the next release cycle.

Compare models like infrastructure choices — not brand fandom.

1. Why PMs Need a Model Landscape Map

Engineers read release notes. Leadership reads headlines. Finance reads invoices. PMs sit in the middle — translating capability into scope, cost into roadmap, and risk into UX.

Without a landscape map, teams default to:

• whatever the last demo used,
• whatever procurement already signed,
• whatever scored highest on a benchmark none of your users trigger.

A landscape map is not a vendor brochure. It is a taxonomy: who builds foundation models, how they are licensed, what tiers exist, and which dimensions actually move your product.

2. Foundation Model Families — The PM View

A family is a line of models from one builder with shared training philosophy, safety posture, and API shape. Names change weekly; families are the stable mental buckets.

Families overlap in capability. Differences show up in how you deploy: hosted API vs your VPC, default refusals, context packaging, tool schemas, and commercial terms — not in who “wins” a generic IQ contest.

3. Closed APIs vs Open-Weight Models

Closed API models run on the provider’s stack. You get fast iteration, managed safety layers, and predictable SLAs — with data-handling terms and per-token economics you do not control.

Open-weight models ship weights you can host. You gain deployment control, fine-tuning freedom, and potentially lower marginal cost at scale — with engineering ownership for inference, patching, evals, and guardrails.

4. Frontier, Mid, and Small Tiers

Providers ship multiple sizes per family. PMs should think in tiers, not a single model name:

• Frontier — hardest tasks, highest cost/latency, widest modality; use sparingly on critical paths.
• Mid — default production tier for most user-facing reasoning with guardrails.
• Small — classification, routing, extraction, high-volume chat turns; pairs well with cascade architectures.

Tier strategy is a product decision: route easy work to small models, escalate on uncertainty signals, and cap frontier usage with budgets and feature flags.

5. General vs Specialized Models

General models aim for broad language, reasoning, and tool use across domains. Specialized models target a modality or task: code completion, embeddings, rerankers, speech, OCR, medical/legal tuned variants.

Anti-pattern: forcing a general frontier model to do cheap perception work (e.g., simple layout OCR) because it is the only model ID in the repo.

6. PM Comparison Table — Dimensions That Matter

Do not maintain a static “winner” column. Maintain fit against your constraints. Refresh cells when you run evals — not when a blog post drops.

7. Competitive Landscape — Builders, Hosters, and Integrators

The market has three layers PMs should separate:

1. Foundation builders — train base models (OpenAI, Anthropic, Google, Meta, Mistral, others).
2. Hosters / clouds — sell inference endpoints, GPUs, and managed fine-tuning (hyperscalers, Together, Fireworks, etc.).
3. Integrators — frameworks and gateways (LangChain, LlamaIndex, LiteLLM, internal platforms) that abstract providers.

Your product rarely commits to only one layer. You might call Anthropic on Bedrock, route Llama on your cluster, and log everything through an internal gateway. PM value is making those layers explicit in architecture diagrams and cost attribution.

8. The Wrong Question: “What Is the Best Model?”

Best for whom, on what task, under which constraints, measured how?

Public leaderboards answer benchmark authors’ tasks. Your users bring messy PDFs, acronyms, tool schemas, and compliance language. A model that tops a multiple-choice science suite may still fail your prior-auth letter workflow.

Replace “best” with:

• Sufficient — meets quality bar with acceptable cost/latency.
• Replaceable — abstraction layer so you can swap providers.
• Observable — you can detect regressions when versions change.

9. Qualities by Use Case — Fit Beats Fame

10. New Model Announcement Checklist

When marketing drops a new flagship name, run this checklist before rewriting the roadmap:

• What tier does it replace — frontier, mid, or small?
• Context window and modality — does it change RAG vs long-context assumptions?
• Pricing model — input vs output vs cached tokens; any batch endpoints?
• Safety delta — more refusals or fewer on your policy eval?
• Breaking changes — deprecated endpoints, new tool schema, different JSON modes?
• Your eval suite — schedule regression on top 5 production workflows, not a demo prompt.
• Rollback — can you flip a feature flag to the prior model ID in one deploy?

11. Common PM Mistakes

Chapter Summary

Closing Thought

The landscape will keep adding names. Your advantage is a stable decision language: constraints, evals, tiers, and deployment paths. Chapter 2 applies that language to a hands-on comparison between GPT, Claude, Gemini, and Llama on your prompts.

Chapter navigation