Capstone: Dein AI Product Case
Worum es geht
Abschnitt betitelt „Worum es geht“Du hast neun Kapitel durchgearbeitet: Foundations, Strategy, Design, Technical Literacy, Evaluation, Agentic AI, Ethics, Execution und Leadership.
Das Capstone Project verbindet alles. Du waehlst ein AI-Produkt oder -Feature — idealerweise eines, das Du tatsaechlich bauen oder verbessern willst — und erstellst einen vollstaendigen AI Product Case dafuer.
Kein Quiz, kein Multiple Choice. Ein Dokument, das Du einem Hiring Manager, einem Stakeholder oder Deinem Team zeigen koenntest.
Die Aufgabe
Abschnitt betitelt „Die Aufgabe“Erstelle ein AI Product Case Document (10–15 Seiten), das die folgenden acht Bereiche abdeckt.
1. Problem & Opportunity (Kapitel 1–2)
Abschnitt betitelt „1. Problem & Opportunity (Kapitel 1–2)“- Ist AI die richtige Lösung? Wende die 5 Check-Fragen aus Kapitel 1 an.
- Build / Buy / Blend — wie setzt Du die AI-Komponente um?
- PMF-Risiko-Assessment — bedroht AI Deinen bestehenden Product-Market Fit oder staerkt sie ihn?
- Opportunity Sizing mit RICE-A (Reach, Impact, Confidence, Effort + AI Complexity)
2. Product Design (Kapitel 3)
Abschnitt betitelt „2. Product Design (Kapitel 3)“- Welches UX-Pattern waehlt Dein Produkt? (Copilot, Agent, Generative, Hybrid)
- Trust-Strategie: Wie baust Du Vertrauen auf? Confidence Indicators, Explainability, Fallbacks.
- User Onboarding: Wie fuehrst Du User an die AI-Features heran, ohne zu oversellen?
3. Technical Approach (Kapitel 4)
Abschnitt betitelt „3. Technical Approach (Kapitel 4)“- Prompting / RAG / Fine-Tuning — welcher Ansatz und warum?
- Model Selection mit Cost/Quality/Latency Tradeoff
- Erwartete Kosten pro Query und monatliches Budget
4. Evaluation Plan (Kapitel 5)
Abschnitt betitelt „4. Evaluation Plan (Kapitel 5)“- Golden Dataset definieren: Wie viele Beispiele, welche Verteilung, wer labelt?
- Metriken festlegen: Precision, Recall, F1, Hallucination Rate, Latency — je nach Use Case
- Red Team Plan: Welche Angriffsvektoren testest Du? Prioritaeten?
- Ship/No-Ship Kriterien: Ab welchen Schwellenwerten wird gelauncht?
- Bias-Check: Welche Gruppen koennten benachteiligt werden?
5. Agent Architecture (Kapitel 6, falls relevant)
Abschnitt betitelt „5. Agent Architecture (Kapitel 6, falls relevant)“- Autonomie-Level: Auf welcher Stufe (L1–L5) operiert Dein Produkt?
- HITL-Pattern: Approval Gate, Escalation Trigger, Parallel Review oder Checkpoint Audit?
- Tool-Strategie: Welche Tools braucht der Agent? Wie wird Zugriff kontrolliert?
Falls Dein Produkt kein Agentic Pattern nutzt: ueberspringe diesen Abschnitt und begruende kurz warum.
6. Ethics & Governance (Kapitel 7)
Abschnitt betitelt „6. Ethics & Governance (Kapitel 7)“- Responsible AI Reality Check: Die 6 Schritte anwenden
- Guardrails: Welche Leitplanken setzt Du? Wo ist das Over-Blocking-Risiko?
- Privacy-Tier: Welches Datenschutz-Level braucht Dein Produkt?
- EU AI Act Einordnung: Welche Risikokategorie? Welche Pflichten?
7. Execution (Kapitel 8)
Abschnitt betitelt „7. Execution (Kapitel 8)“- AI PRD schreiben: Mindestens die 7 Sektionen aus Kapitel 8 abdecken
- Lifecycle-Phase bestimmen: Exploration, Evaluation, Production oder Continuous Improvement?
- Data Quality Plan: Woher kommen die Daten? Wie sicherst Du Qualität?
- Cross-functional Setup: Wer arbeitet zusammen? Welche Rollen?
8. Go-to-Market & Leadership (Kapitel 9)
Abschnitt betitelt „8. Go-to-Market & Leadership (Kapitel 9)“- Pricing-Modell: Usage-Based, Per-Seat, Freemium, Feature-Tier?
- KPI-Dashboard: Drei Ebenen — Quality, Business, Operational
- Team-Struktur: Welche Rollen brauchst Du? Centralized, Hub-and-Spoke oder Distributed?
Qualitaetskriterien
Abschnitt betitelt „Qualitaetskriterien“Dein Capstone ist gut, wenn:
- Jeder Bereich eine begruendete Entscheidung enthaelt, nicht nur eine Beschreibung
- Tradeoffs explizit benannt sind (z.B. “wir akzeptieren hoehere Latenz für bessere Qualität”)
- Zahlen enthalten sind: Kosten, Metriken-Schwellenwerte, Timelines
- Mindestens ein Risiko identifiziert ist, das zum Scheitern fuehren könnte
- Das Dokument für einen nicht-technischen Stakeholder verständlich ist
Hinweise
Abschnitt betitelt „Hinweise“- Es gibt keine “richtige” Lösung. Es gibt gut durchdachte und schlecht durchdachte Cases.
- Nutze die Templates als Startpunkt für einzelne Sektionen.
- Wenn Du in einem Bereich unsicher bist, geh zurück zum entsprechenden Kapitel.
- Real > hypothetisch. Je naeher Dein Case an einem echten Produkt ist, desto wertvoller das Ergebnis.