Product-Management-Glossar

Ein Artefakt ist jedes strukturierte Arbeitsobjekt, das Teklens verwaltet – das Gegenstück zur freien Konversation.

Artefakte sind PRDs, Epics, Stories, ADRs und ähnliche Objekte mit klarem Typ, Status und Platz in der Hierarchie. Sie sind kontextfähig: Memories, Widgets und Conversations hängen an ihnen.

Ein PRD beschreibt, was ein Feature leisten soll und warum – und hängt unter einer Initiative.

Das PRD ist in Teklens die Brücke zwischen Initiative und Umsetzung: Problem, Ziele, Scope und Anforderungen, verankert in Code Intelligence und vererbtem Kontext. Aus ihm leiten sich Epics und Stories ab.

Ein Epic ist ein grösseres Stück Arbeit, das aus einem PRD abgeleitet und in Stories zerlegt wird.

Epics sitzen zwischen PRD und Story und bündeln Stories, die ein gemeinsames Ergebnis liefern. Sie erben den Kontext des PRDs.

Eine Story ist eine kleine, lieferbare Arbeitseinheit, die zu einem Epic gehört.

Stories sind das Format, in dem Teams umsetzen. Sie erben den vollen Kontext (Initiative → PRD → Epic) und können eigene Memories, Widgets und Conversations halten.

Ein ADR (Architecture Decision Record) hält eine technische Entscheidung, ihren Kontext und ihre Konsequenzen fest.

ADRs machen Architekturentscheidungen nachvollziehbar – warum so und nicht anders, welche Optionen verworfen wurden, welche Folgen das hat. In Teklens sind sie Artefakte mit eigenem Kontext.

Die Context Engine ist die geheime Zutat von Teklens: Sie zieht Kontext aus Code, Jira, Transcripts und Business-Inhalten ans Artefakt.

Die Context Engine kombiniert Context Server, Vector Store und Code Intelligence und liefert jedem Artefakt automatisch den passenden Kontext – geerbt, fokussiert und manuell gepinnt – statt dass du ihn pro Aufgabe zusammensuchen musst.

Kontext ist die vollständige Menge an Informationen, die dem aktuell bearbeiteten Artefakt zur Verfügung steht.

Kontext setzt sich aus Context Elements zusammen: vererbt von übergeordneten Artefakten, fokussiert auf das aktuelle Artefakt und ergänzt um gepinnte Inhalte.

Context Elements sind die einzelnen Bestandteile des Kontexts – Briefings, Analysen, das übergeordnete PRD, Memories und mehr.

Jedes Element trägt Metadaten, die der Context Server nutzt, um es korrekt einzuordnen und bei Bedarf einzublenden.

Inherited Context ist alles, was von übergeordneten Artefakten weitergegeben wird (Initiative → PRD → Epic → Story).

So muss eine Story nicht von vorne starten: Sie kennt automatisch das Ziel der Initiative, die Annahmen des PRDs und die Entscheidungen des Epics.

Focused Context ist der Kontext des aktuell im Fokus stehenden Artefakts (Focus Item).

Memories, Widgets und Conversations, die direkt am Focus Item hängen – getrennt vom geerbten Kontext, damit klar bleibt, was lokal entstanden ist.

Pinned Context sind zusätzliche Inhalte, die du manuell an einen Workspace hängst, weil sie für deine aktuelle Arbeit zählen.

Funktioniert wie das Anheften eines Ordners: Was du pinst, bleibt im Zugriff – auch wenn es nicht aus der Hierarchie geerbt wäre.

Der Context Server ist das Backend, das alle Memories mit den nötigen Metadaten speichert, um sie richtig einzuordnen.

Er entscheidet, welcher Inhalt zu welchem Artefakt gehört, vererbt oder fokussiert ist, und liefert die richtigen Elemente an Agents und UI.

Der Vector Store (Qdrant) ist die Datenbank hinter dem Context Server, in der Memories nach Relevanz durchsucht und bewertet werden.

Embeddings ermöglichen semantische Suche: Ähnliche Inhalte werden gefunden, auch wenn sie nicht wortwörtlich übereinstimmen.

Code Intelligence ist Kontext aus dem echten Codebase, der dem Focus Item zusätzlich zum übrigen Kontext zur Verfügung steht.

Statt zu raten, was im Code steht, liest Teklens Repositories aus und verankert Spezifikationen in den tatsächlichen Komponenten und Datenstrukturen.

Ein Workspace ist die dynamische Arbeitsumgebung, die automatisch um jedes geöffnete Artefakt aufgebaut wird – ohne manuelles Setup.

Im Workspace stehen der passende Kontext, Memories, Widgets und Conversations bereit. Statt Projekte vorab anzulegen, baut Teklens den Workspace zur Laufzeit.

Eine Memory ist ein gespeicherter Kontext am Artefakt – du kannst sie hinzufügen, ändern oder entfernen.

«Merken» ist auch eine Aktion: Jedes Ergebnis, jeder Entwurf, jedes Widget kann als Memory abgelegt werden und bleibt damit im Kontext des Artefakts.

Ein Widget ist ein generiertes Ergebnis – etwa eine Risikoanalyse oder Schätzung – und wird automatisch als Memory abgelegt.

Teklens ist stark grafisch ausgerichtet – z. B. Impact-/Feasibility-Matrix. Widgets entstehen aus Skills und bleiben am Artefakt sichtbar und referenzierbar.

Conversations sind alle Chat-Nachrichten, die zu einem Artefakt gehören.

Sie sind Teil des Focused Context und können als Memories gehoben werden, sobald ein Ergebnis dauerhaft bleiben soll.

Related Conversations sind alle einzelnen Chats zu einem Artefakt – standardmässig als eine konsolidierte «virtuelle» Konversation angezeigt.

Die einzelnen Threads bleiben einzeln auswählbar, sodass du Herkunft und Verlauf nachvollziehen kannst.

Ein Agent ist der Worker, der Aufgaben ausführt und dabei die jeweils passenden Skills lädt.

Ein Agent bündelt Skills und Capabilities (z. B. Product Manager, Architect). Welcher Skill läuft, bestimmt, unter welcher Persona die Arbeit erscheint.

Ein Skill ist eine einzelne Fähigkeit (z. B. ein Story-Draft-Skill); seine Ausführung erzeugt ein Widget oder Artefakt.

Skills sind die atomaren Bausteine, aus denen Agents Aufgaben zusammensetzen. Jeder Run nutzt genau die Skills, die das Artefakt verlangt.

Ein Run ist eingeplante oder wiederkehrende Arbeit, die einer Initiative zugeordnet ist.

Runs sorgen dafür, dass eine Initiative kontinuierlich überwacht oder vorangetrieben wird – etwa tägliche Status-Updates oder periodische Analysen.

Ein Handover ist ein Paket, das jeder Agent aufnehmen kann, um die Arbeit weiterzuführen – optional mit MCP-Verbindung zu anderen Apps.

Das Handover bündelt Kontext, Skills und Rückkanäle, damit Arbeit ohne Reibung von einem Agent (oder Tool) zum nächsten wandert.

Eine MCP Connection erlaubt einem externen Agent oder einer App, auf die relevanten Daten zuzugreifen und sie zurückzuschreiben.

MCP (Model Context Protocol) macht Teklens-Kontext für externe Werkzeuge nutzbar – lesen und schreiben in einem definierten, sicheren Vertrag.

Eine Initiative ist eine Sammlung von Artefakten, die die Stages Discover → Define → Build → Operate durchläuft.

Im Unterschied zur Roadmap-Initiative (Jira/Linear) ist die Teklens-Initiative der konkrete Container, in dem PRDs, Epics, Stories, Memories und Runs zusammenlaufen und Kontext vererben.

Die Dropbox ist der Standard-Container – alles, was nicht ausdrücklich zugeordnet ist, landet hier (wie ein Desktop) und kann später in eine Initiative verschoben werden.

Die Dropbox reduziert Setup-Reibung: erst arbeiten, dann strukturieren.

Ein Folder hat dasselbe Prinzip wie eine Initiative, aber ohne Stages – einfach ein Ort, an dem du Dinge ablegst.

Folders sind nützlich, wenn du Material gruppieren willst, ohne dass es einen Lifecycle durchläuft.

Das Cowork-Äquivalent, das Teklens ersetzt: Teklens baut Kontext automatisch, statt dich pro Initiative ein Project anlegen zu lassen.

Statt vorab ein Projekt pro Vorhaben zu konfigurieren, eröffnest du ein Artefakt, und der Workspace samt Kontext entsteht automatisch.

Ein Issue ist die kleinste verfolgbare Arbeitseinheit in einem Tracker – Story, Task oder Bug.

Issue ist der Oberbegriff für jede einzelne, zugewiesene Arbeitseinheit mit Status, Owner und Verlauf. In Jira heisst dieser Vorgang offiziell «Issue» und hat einen konfigurierbaren Typ.

Eine User Story beschreibt eine Anforderung aus Nutzersicht: «Als … möchte ich … damit …».

Die User Story ist die kleinste fachliche Anforderung, die für sich Wert liefert. Sie wird mit Akzeptanzkriterien geschärft und in einen Sprint bzw. Cycle gezogen.

Ein Task ist eine technische oder organisatorische Aufgabe ohne direkten Nutzer-Bezug.

Tasks erfassen Arbeit, die getan werden muss, aber keine User Story ist – etwa Migrationen, Spikes oder Setup-Arbeiten.

Ein Bug ist ein Defekt: Das Produkt verhält sich anders als spezifiziert.

Bugs dokumentieren fehlerhaftes Verhalten mit Schritten zur Reproduktion, Erwartung und Ist-Zustand. Bug-Cluster zeigen, wo das Produkt strukturell schwächelt.

Ein Epic bündelt mehrere Stories zu einer grösseren Initiative mit gemeinsamem Ziel.

Epics strukturieren grössere Vorhaben über mehrere Sprints hinweg. In Jira ist ein Epic ein konfigurierbarer Container; in Linear entspricht ihm das «Project» mit Fortschrittsbalken und Zieldatum.

Eine Sub-task zerlegt ein Issue in kleinere, einzeln verfolgbare Schritte.

Sub-tasks gliedern die Umsetzung eines Issues, ohne ein eigenes Backlog-Item zu sein. Linear nennt sie «Sub-issues».

Ein Sprint ist ein fester Zeitraum (meist 1–2 Wochen), in dem ein Team eine geplante Menge Arbeit liefert.

Der Sprint ist die Iterationseinheit aus Scrum. In Jira werden Sprints manuell geplant, gestartet und geschlossen. Linears «Cycle» ist das Pendant, läuft aber automatisch.

Ein Cycle ist Linears automatische Iteration – der Fokus liegt auf Team-Momentum statt fixer Commitments.

Cycles starten und enden automatisch; nicht abgeschlossene Issues rollen in den nächsten Cycle. Das entspricht funktional dem Jira-Sprint, ohne dessen manuelles Zeremoniell.

Das Backlog ist die priorisierte Liste aller noch nicht eingeplanten Arbeit.

Aus dem Backlog ziehen Teams Arbeit in Sprints bzw. Cycles. Es ist die zentrale Quelle für Priorisierung und Refinement.

Triage ist der Eingangskorb für neue, noch ungeprüfte Anfragen, die erst bewertet werden müssen.

Im Triage-Schritt werden eingehende Bugs und Ideen gesichtet, priorisiert und einem Team zugeordnet – bevor sie ins Backlog wandern. In Linear ist Triage ein eigener, fester Zustand.

Story Points schätzen den relativen Aufwand eines Issues statt absoluter Stunden.

Über relative Schätzung (oft Fibonacci) wird Komplexität, Risiko und Umfang abgebildet. Daraus ergibt sich die Velocity eines Teams.

Eine Roadmap zeigt geplante Initiativen über die Zeit – das «Was» und «Wann» der Produktstrategie.

Die Roadmap verbindet Strategie mit Delivery und macht Sequenzierung und Abhängigkeiten sichtbar. In Jira liefert «Advanced Roadmaps / Plans» diese Sicht.

Eine Initiative bündelt mehrere Epics bzw. Projekte zu einem übergeordneten strategischen Ziel.

Initiativen sind die oberste Planungsebene und verbinden Vision mit konkreten Vorhaben. Beide Tools nutzen den Begriff auf der höchsten Aggregationsebene.

In Linear ist ein Project ein zeitlich begrenztes Vorhaben mit Lead, Zieldatum und Fortschritt – das Pendant zum Jira-Epic.

Linears Project hat Fortschrittsbalken, Zieldaten und Verantwortliche standardmässig eingebaut, während ein Jira-Epic erst konfiguriert werden muss, um sich so zu verhalten.

Ein Milestone ist ein wichtiger Termin- oder Ergebnis-Marker auf der Timeline.

Milestones markieren bedeutende Zwischenziele. In Linear gliedern sie Projects; in Jira übernimmt diese Rolle meist «Version / Release».

Ein Release (Version) bündelt Änderungen, die gemeinsam ausgeliefert werden.

Releases gruppieren abgeschlossene Arbeit zu einem Auslieferungspaket und sind die Basis für Release Notes. In Jira ist die «Version» ein eigenes Objekt pro Projekt.

Ein Workflow ist die Abfolge von Status, die ein Issue von «To Do» bis «Done» durchläuft.

Jira erlaubt pro Issue Type frei konfigurierbare Workflows mit Übergängen und Regeln. Linear setzt auf wenige, vorgegebene Workflow-States für Geschwindigkeit.

Ein Board visualisiert Issues in Spalten nach Status – als Kanban- oder Scrum-Board.

Boards machen Arbeit und Engpässe sichtbar. Ein Kanban-Board zeigt den kontinuierlichen Fluss, ein Scrum-Board den aktuellen Sprint.

Ein Label ist ein frei vergebbares Schlagwort, um Issues zu kategorisieren und zu filtern.

In Linear sind Labels zentral: Statt vieler Issue-Typen unterscheidet man Bug, Feature oder Chore über Labels. In Jira ergänzen Labels die strukturellen Issue Types.

Mit Queries und Filtern findet und gruppiert man Issues nach beliebigen Kriterien.

Jira nutzt die mächtige, aber lernintensive Abfragesprache JQL. Linear setzt auf einfache Filter und eine Command Palette für schnelle Suche.

Akzeptanzkriterien legen fest, wann eine Story als erfüllt gilt – die testbare Definition von «fertig» pro Story.

Gute Akzeptanzkriterien sind konkret und prüfbar und decken Edge Cases ab. Sie verhindern, dass Defekte erst in QA oder Produktion auffallen.

Die Definition of Done ist die teamweite Checkliste, die jedes Issue erfüllen muss, um als abgeschlossen zu gelten.

Anders als Akzeptanzkriterien (pro Story) gilt die DoD für alle Issues – z. B. Code-Review, Tests grün, Doku aktualisiert, deployt.

Ein PRD (Product Requirements Document) beschreibt, was gebaut wird, für wen und warum – die Grundlage für Epics und Stories.

Das PRD bündelt Problem, Ziele, Scope, Non-Goals und Anforderungen. Code-verankerte PRDs referenzieren die tatsächlich betroffenen Komponenten und Datenstrukturen.

Velocity ist die Menge an Story Points, die ein Team pro Sprint im Schnitt abschliesst.

Velocity dient der Vorhersage: Wie viel passt realistisch in den nächsten Sprint? Sie ist teamspezifisch und nicht für Vergleiche zwischen Teams gedacht.