Product Management Glossary

An artefact is any structured work item Teklens manages – the opposite of a free conversation.

Artefacts are PRDs, epics, stories, ADRs and similar objects with a clear type, status and place in the hierarchy. They carry context: memories, widgets and conversations attach to them.

A PRD defines what a feature should do and why, and sits under an initiative.

In Teklens the PRD bridges initiative and delivery: problem, goals, scope and requirements, anchored in code intelligence and inherited context. Epics and stories are derived from it.

An epic is a large piece of work derived from a PRD, broken down into smaller stories.

Epics sit between PRD and story and group stories that deliver a shared outcome. They inherit the PRD's context.

A story is a small, deliverable unit of work that belongs to an epic.

Stories are how teams ship. They inherit the full context (initiative → PRD → epic) and can hold their own memories, widgets and conversations.

An ADR (Architecture Decision Record) captures a technical decision, its context and its consequences.

ADRs make architectural decisions traceable – why this and not that, which options were rejected, what the consequences are. In Teklens they are artefacts with their own context.

The Context Engine is the secret ingredient of Teklens: it pulls context from code, Jira, transcripts and business content to the artefact you're working on.

The Context Engine combines the Context Server, Vector Store and Code Intelligence to give every artefact the right context automatically – inherited, focused and manually pinned – instead of forcing you to assemble it per task.

Context is the full set of information available to the item you're currently working on.

Context is made up of Context Elements: inherited from artefacts above, focused on the current artefact, and extended with pinned content.

Context elements are the individual pieces that make up that context – briefings, analyses, the parent PRD, memories and so on.

Each element carries metadata the Context Server uses to place it correctly and surface it when relevant.

Inherited context is everything passed down from items above you in the hierarchy (initiative → PRD → epic → story).

This means a story doesn't start from scratch: it automatically knows the initiative's goal, the PRD's assumptions and the epic's decisions.

Focused context is the context belonging to the single item currently in focus (the focus item you're working on).

Memories, widgets and conversations that attach directly to the focus item – kept separate from inherited context so it's clear what originated locally.

Pinned context is extra items you attach to a workspace by hand because they matter for your current work.

Works like pinning a folder: what you pin stays in reach – even if it wouldn't be inherited from the hierarchy.

The Context Server is the backend that stores all memories with the metadata needed to place them correctly.

It decides which content belongs to which artefact, whether it's inherited or focused, and serves the right elements to agents and UI.

The vector store is the database behind the Context Server that lets memories be searched and scored by relevance.

Embeddings enable semantic search: similar content is found even when wording doesn't match exactly.

Code intelligence is context drawn from the actual codebase, available to the focus item alongside the other context.

Instead of guessing what's in the code, Teklens reads repositories and anchors specifications in the components and data shapes that actually exist.

A workspace is the dynamic working environment built automatically around whatever item you open – no manual setup needed.

The workspace surfaces the right context, memories, widgets and conversations. Instead of setting up projects up front, Teklens builds the workspace at runtime.

A memory is a saved piece of context attached to an item – you can add, edit or remove them.

“Remembering” is also an action: any result, draft or widget can be kept as a memory so it stays in the item's context.

A widget is a generated output such as a risk analysis or estimation; every widget a skill produces becomes a memory automatically.

Teklens is graphics-oriented – e.g. impact/feasibility matrix. Widgets are produced by skills and remain visible and referenceable on the artefact.

Conversations are all chat messages tied to an item.

They're part of the focused context and can be promoted to memories whenever a result should persist.

Related conversations are all the separate chats tied to one item; by default shown as a single consolidated “virtual” conversation.

The individual threads remain selectable, so you can trace origin and history.

An agent is the worker that carries out tasks by loading the relevant skills when needed.

An agent is a bundle of skills and capabilities (Product Manager, Architect, …). The skill that runs determines which named persona is credited.

A skill is a single capability (for example a story-draft skill); running one can produce a widget or artefact.

Skills are the atomic building blocks agents compose tasks from. Each run uses exactly the skills the artefact requires.

In the Skill Studio you configure reusable skills – templates, checklists and checks that run the same way in every Activity.

The Skill Studio is the configuration layer for skills: recurring artefacts and checks (epic criteria, security checks, compliance) are defined once and run reproducibly on every matching item – grounded in the real code.

A run is scheduled or looping work assigned to an initiative.

Runs keep an initiative continuously monitored or moving – e.g. daily status updates or periodic analyses.

A handover is a package any agent can pick up to continue the work, optionally with an MCP connection to other apps and a way to push information back.

The handover bundles context, skills and a write-back channel so work moves frictionlessly from one agent (or tool) to the next.

An MCP connection is a link that lets an external agent or app access the relevant data and write back to it.

MCP (Model Context Protocol) makes Teklens context usable by external tools – reading and writing under a defined, secure contract.

An initiative is a collection of artefacts that moves through stages (Discover → Define → Build → Operate); it ties everything together.

Unlike a roadmap initiative (Jira/Linear), the Teklens initiative is the concrete container where PRDs, epics, stories, memories and runs come together and inherit context (initiative → PRD → epic → story).

The dropbox is the default container; anything not explicitly assigned lands here (like a desktop) and can be moved into an initiative later.

The dropbox reduces setup friction: work first, structure later.

A folder is the same idea as an initiative but without stages – just a place to drop things.

Folders are useful when you want to group material without it running through a lifecycle.

The Cowork equivalent Teklens is replacing: Teklens builds context automatically instead of making you set up a project per initiative.

Instead of configuring a project per effort up front, you open an artefact and the workspace and context are assembled automatically.

LLM data controls are the technical and contractual measures that determine how your data is processed, stored, used for training and protected when you use an LLM.

The umbrella term covers six building blocks: no training, zero data retention, a DPA, regional processing, a technical allowlist and log hygiene. Only together do they give a defensible answer to the question "what happens to our data?" – the question most AI projects in Switzerland and Germany get stuck on in security review.

No training means the LLM provider does not use your prompts, files and responses to train or improve its models.

The distinction matters: it says nothing about whether data is stored temporarily. A provider can commit to not training and still retain your prompts for 30 days for abuse monitoring. Checking only for "no training" gives you half the answer.

Zero data retention (ZDR) means the provider does not store prompts and responses after processing – apart from clearly defined technical, legal or security-related exceptions.

ZDR is stronger than no training because it covers storage, not just use. For regulated buyers in Switzerland and Germany, ZDR is usually where a security review turns: nothing stored at the provider means no extra place your data can be compromised. The defined exceptions still belong in the contract – read them.

A DPA is the data-processing contract between customer and provider: it governs how personal data is processed, protected, shared and deleted.

In Germany it is the Auftragsverarbeitungsvertrag (AVV), mandatory under Art. 28 GDPR as soon as a provider processes personal data; in Switzerland the revised Data Protection Act (revDSG) demands the same clarity. The DPA is the contractual layer: it does not replace a technical control, but it makes one enforceable – including the sub-processor list and deletion periods.

Data residency defines in which region data is processed or stored – for example exclusively within the EU or in Switzerland.

It can be decisive for data protection, compliance and customer requirements. It does not automatically mean that no access from other jurisdictions is possible: support, operations or a parent company outside the EU may still have access. Place of processing and right of access are two separate questions – clarify both.

A technical allowlist is the explicit list of permitted models, APIs, features and tools – anything not on the list is blocked technically.

It stops a developer from accidentally using a non-ZDR model or an agent that stores data. Without an allowlist your assurance is only a policy: anyone quickly testing a new model bypasses every contract. With one, it is a control you can evidence in an audit.

Log hygiene is the deliberate handling of logs, monitoring and error data so that sensitive prompts, responses, files and personal information never land unfiltered in your own systems.

Otherwise ZDR at the LLM provider buys you little: the data simply sits for months in application logs, Sentry, Datadog or analytics. Log hygiene means redacting instead of collecting – masking prompt content, setting retention periods, restricting access. It is the building block teams forget most often, because it sits with them, not with the provider.

An issue is the smallest trackable unit of work in a tracker – a story, task or bug.

Issue is the umbrella term for a single assignable unit of work with a status, owner and history. In Jira it is officially called an “issue” with a configurable type.

A user story describes a requirement from the user's perspective: “As a … I want … so that …”.

A user story is the smallest functional requirement that delivers value on its own. It is sharpened with acceptance criteria and pulled into a sprint or cycle.

A task is a technical or organisational piece of work without a direct user-facing story.

Tasks capture work that needs doing but isn't a user story – migrations, spikes or setup work, for example.

A bug is a defect: the product behaves differently from what was specified.

Bugs document faulty behaviour with reproduction steps, expected and actual result. Bug clusters show where the product is structurally weak.

An epic groups several stories into a larger initiative with a shared goal.

Epics structure larger efforts across multiple sprints. In Jira an epic is a configurable container; in Linear the equivalent is a “Project” with a progress bar and target date.

A sub-task breaks an issue into smaller, individually trackable steps.

Sub-tasks split the delivery of an issue without being a separate backlog item. Linear calls them “sub-issues”.

A sprint is a fixed time-box (usually 1–2 weeks) in which a team delivers a planned amount of work.

The sprint is Scrum's iteration unit. In Jira sprints are planned, started and closed manually. Linear's “Cycle” is the equivalent but runs automatically.

A cycle is Linear's automatic iteration – focused on team momentum rather than rigid commitments.

Cycles start and end automatically; unfinished issues roll over to the next cycle. Functionally it maps to the Jira sprint without the manual ceremony.

The backlog is the prioritised list of all work not yet scheduled.

Teams pull work from the backlog into sprints or cycles. It is the central source for prioritisation and refinement.

Triage is the inbox for new, unvetted requests that still need to be assessed.

In triage, incoming bugs and ideas are reviewed, prioritised and routed to a team before they enter the backlog. In Linear, Triage is a dedicated built-in state.

Story points estimate the relative effort of an issue instead of absolute hours.

Relative estimation (often Fibonacci) captures complexity, risk and scope. A team's velocity is derived from it.

A roadmap shows planned initiatives over time – the “what” and “when” of product strategy.

The roadmap connects strategy to delivery and makes sequencing and dependencies visible. In Jira, “Advanced Roadmaps / Plans” provides this view.

An initiative groups several epics or projects under one higher-level strategic goal.

Initiatives are the top planning level, connecting vision to concrete efforts. Both tools use the term at the highest aggregation level.

In Linear a project is a time-bound effort with a lead, target date and progress – the counterpart to a Jira epic.

Linear's project has progress bars, target dates and owners built in by default, whereas a Jira epic must be configured to behave that way.

A milestone is a key timeline or outcome marker.

Milestones mark significant checkpoints. In Linear they structure projects; in Jira a “version / release” usually plays this role.

A release (version) bundles changes that ship together.

Releases group completed work into a shipping package and are the basis for release notes. In Jira a “version” is a dedicated object per project.

An Activity is a concrete step of product work in the AI Product Playbook, from the first source to human approval – with an owner, the required context, assigned agents, skills, an output and quality criteria.

Activities are the repeatable units of product work: analyse customer feedback, draft a PRD, prepare refinement, review the implementation against intent. Each Activity defines what triggers it, which context it needs from the Product Brain, who owns it, which agents and skills do the work, which steps follow, what good looks like, where a person approves and where the result goes (Jira, Confluence, the Product Brain). Activities belong to Product Brain, Discover, Define, Build or Operate but run whenever they are relevant; «usually next» is a suggestion, not a waterfall. Methods such as RICE or Kano are methods inside an Activity, not Activities of their own.

The AI Product Playbook describes how a product team works with people, agents and shared context: the Activities it runs and the approvals people keep.

The Playbook is not a static process diagram but a living operating model: people, assigned agents, shared context from the Product Brain, skills, artifacts, quality criteria and human decisions. The Teklens library provides Activities along Product Brain → Discover → Define → Build → Operate; during onboarding (Connect → Build the Product Brain → Build the AI Product Playbook) the fitting Activities are selected, adapted and configured with owners, agents and approvals. Retro findings and accepted agent suggestions change the Playbook in versioned steps.

A workflow is the sequence of statuses an issue moves through from “to do” to “done”.

Jira allows freely configurable workflows per issue type, with transitions and rules. Linear uses a few opinionated workflow states for speed.

A board visualises issues in columns by status – as a Kanban or Scrum board.

Boards make work and bottlenecks visible. A Kanban board shows continuous flow, a Scrum board the current sprint.

A label is a free-form tag used to categorise and filter issues.

In Linear labels are central: instead of many issue types, you distinguish bug, feature or chore via labels. In Jira labels complement the structural issue types.

Queries and filters find and group issues by arbitrary criteria.

Jira uses the powerful but learning-intensive query language JQL. Linear relies on simple filters and a command palette for fast search.

Acceptance criteria define when a story is considered done – the testable definition of “done” for that story.

Good acceptance criteria are concrete, testable and cover edge cases. They stop defects from surfacing only in QA or production.

The Definition of Done is the team-wide checklist every issue must meet to count as complete.

Unlike acceptance criteria (per story), the DoD applies to every issue – e.g. code reviewed, tests green, docs updated, deployed.

A PRD (Product Requirements Document) describes what is being built, for whom and why – the basis for epics and stories.

The PRD bundles the problem, goals, scope, non-goals and requirements. Code-anchored PRDs reference the components and data shapes actually affected.

Velocity is the amount of story points a team completes per sprint on average.

Velocity supports forecasting: how much realistically fits into the next sprint? It is team-specific and not meant for comparing teams.