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 (Qdrant) 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.

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.

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.

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.

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.