What WorkThroughLine does today - the full list, and when each part earns its place

A few days ago I sat down and listed everything WorkThroughLine does. It was meant to be an internal note before a call with one team, and it came out long enough to honestly unsettle me a little. Not because there are many features - but because a feature list on its own helps nobody decide anything.

So this is not a catalogue. Every entry says why the thing exists, when it is worth turning on and, where it helps, the concrete situation in which it pays off. The snapshot is from 10 August 2026. In six months parts of it will be wrong, and that is fine - the date is there so we know which state we are talking about.

One note up front: turn everything on at once and you get a worse experience than turning nothing on. Most of what follows solves a problem your team may not have yet.

One rule everything else follows from

The goal is a first-class entity and delivery is the means.

In practice that means every task can answer “what does this serve?”, not only “who owns it and which column is it in”. The links between an annual goal, an OKR, an opportunity, a solution, an experiment and a ticket are not text in a description; they are typed edges in a graph you can walk in both directions. Open the goal and see everything it produced; open the ticket and see why it exists.

If that is the only thing you take from this text, it is enough. Everything below is infrastructure for it.

Strategy: goals, OKRs and planning time

The hierarchy is annual goal → product goal (optional) → OKR. The product goal is a middle layer you use only when one annual goal has several clearly separate product directions. Skip it and you lose nothing.

An OKR behaves differently depending on where it sits, and that is deliberate. An OKR directly under an annual goal carries classic key results - measurable numbers. An OKR under a product goal carries solutions instead, through an automatically created mirror in Discovery. The reason is simple: at the level of a product direction there is rarely one number that describes everything, and there is almost always a list of things you try.

Every OKR also carries a confidence level from 1 to 5. That is not a completion percentage but a judgement of whether we believe we will get there. When three OKRs sit at two, that is a conversation to have in September, not in January.

Time is measured in planning periods you choose yourself: tertials (three periods of four months), quarters or half-years, with a configurable start month. We work in tertials because four months leave enough room to actually finish something, while a quarter in practice turns into two months of work and one month of planning.

The roadmap lays OKRs across those periods in two shapes: a timeline, or Now / Next / Later columns. Grouping is by annual goal, planning period or product manager. Colour is status, fill is progress.

The roadmap can be shared through a public read-only link, with or without an expiry date, revocable at any time. The link shows no owner names and no delivery cards - only goals, OKRs and progress.

When to use it: when someone outside the team asks “to see the roadmap” and you want neither to create them an account nor to export slides every month. A client, an investor, a partner team. The link expires in 30 days and cleans itself up.

Discovery: from a conversation to evidence

The chain is interview or analysis → insight → opportunity → solution → experiment.

An interview is a conversation with a user, with a transcript and a summary. An analysis is research over data, with a question, a method and a result. Both produce insights, and insights “reinforce” opportunities - one opportunity can carry evidence from seven different conversations, and that is visible on it.

Opportunities are prioritised with a RICE score: reach times impact times confidence, divided by effort. Reach is users per planning period, effort is person-weeks, impact uses the Intercom scale. The score is not a verdict but a conversation tool - when someone argues for work “because it matters”, RICE forces them to say how many users and how many weeks.

Solutions are scored on impact, effort and confidence and have their own lifecycle: proposed → selected → experimenting → validated or rejected.

Experiments exist so a hypothesis gets tested before full build. An experiment is promoted into delivery as a TEST card, gets worked, then concluded as succeeded, failed or inconclusive. Links and the trace are inherited, so six months later you see not only what you shipped but what you tried and dropped.

The whole chain renders as an opportunity solution tree, with pan and zoom, because after a year of work the tree does not fit on a screen.

An interesting case: a failed experiment is the cheapest artefact in the system and the most expensive one to rediscover. “We checked and it did not work” never gets written down by hand, because there is nothing to show for it, so someone investigates the same question again next year. Here it stays recorded together with the method.

Delivery: one model instead of five tables

Delivery has a single work item table with a type and a parent, instead of separate epics, stories and tasks. It sounds like a technical detail, but it changes daily life: changing a type is a field edit, not a ticket migration.

The card holds what you would expect - a description with markdown, checklists, attachments with image and file preview, comments with threaded replies and @mentions, links of type blocks / blocked by / related / duplicate, subtasks, estimates and story points, labels, due dates. Edits autosave, and history is reconstructed from the audit log, so you see who changed what and when.

Sprints and the board work as a Scrum-Kanban hybrid. You fill the backlog, pull into a sprint, and move cards through statuses on the board. Each team can have its own workflow - the names and order of seven steps - and the board automatically uses the workflow of the team the sprint belongs to. Closing a sprint asks what happens to unfinished items: carry them into the next sprint (with a carry counter) or send them back to the backlog. Items added mid-sprint are marked separately as ad-hoc.

Those two counters - how many times something was carried and how much arrived unplanned - usually say more about a team than any velocity metric.

Work classification is the thing we argued about most. There is development and there is maintenance. A bug and anything carrying a maintenance category is maintenance, even when it is linked to an OKR. Everything else is development, split into development toward a goal and development outside a goal. A framework upgrade and a refactor are development, not maintenance - proactive work is not upkeep.

Why that is good: you get an answer to the question leadership asks every quarter - “where does our time go” - without a single extra spreadsheet. And you get it in a form that cannot be dressed up, because the classification does not depend on what somebody named the ticket.

Alongside that come saved views: set filters on the backlog and save them as a private view or a shared one for the whole organisation. The URL carries the filters, so the same view travels as a link. There are bulk actions, labels, and custom fields you define when the standard ones run out.

My work is the personal view - everything you are assigned to, mentioned in or following, regardless of role.

Card followers are the newest thing in the product. You add colleagues or stakeholders who need to know what is happening, and they get notified about status changes and new comments without being assigned anything.

When to use it: a card that legal, marketing or someone in support is waiting on. Instead of pinging them three times, you add them as followers and the system tells them. It cuts down the “is that done yet” messages.

Intake: the channel for everything arriving from the side

The intake board has two lanes - bugs and tasks, improvement proposals - and four columns: submitted, in preparation, in progress, done. Each column shows at most five cards until you expand it, a small thing that keeps the board readable.

What this really does is separate two different processes. A bug that has been picked up automatically tracks its delivery status - when the ticket closes, the submission moves to done on its own. An improvement proposal is moved by hand, because a proposal does not travel through delivery, it travels through a decision.

A submission can be pushed to delivery (with or without an OKR, optionally into the active sprint) or turned into an opportunity in Discovery. It has comments, a lifecycle history, watchers who receive the same notifications as the reporter, and a shareable link.

An interesting case: turning a submission into an opportunity is the most useful path and the least used one. When the same thing arrives a third time from a third person, it is no longer a bug, it is a signal. Turning it into an opportunity means it stays in discovery with its evidence instead of being patched and forgotten.

Public portal and changelog

The portal is a public page where people without an account propose improvements, vote on other people’s proposals and read release notes. It turns on with one switch, and only what you explicitly approve becomes public.

Moderation comes with it: visitors can report content as spam, harassment, hateful content, published personal data or illegal content, and you decide whether the content is hidden or the report dismissed, with an internal note on the reasoning.

The changelog is the other half of the same space - posts about what shipped, linked to concrete work items, with control over what is published and what stays internal.

When to use it: when support spends hours on “are you going to add this”. A public voting portal does not solve prioritisation - and should not - but it takes most of that traffic off their desk and turns it into something you read once a week.

Documentation that joins the same graph

Documents live in one of two ways, and you choose which when you create them.

The first is anchored to an entity - an annual or product goal, an OKR, an opportunity, a solution, an experiment or a ticket. The tree builds itself from the model, so a document’s position says what it is about. A document at the discovery level automatically shows up on the linked delivery cards too. For PRDs, technical designs, ADRs and decision notes.

The second is a free wiki space with manual folders and no entity link. For the team handbook, onboarding, processes and glossary.

Wherever you write, @-mentioning an entity creates a real edge - the document enters the trace graph and appears in the chain.

Notifications: what arrives, and where

The types are: mention, assignment, added as a follower, status change, new comment, due soon, new submission and unblocked.

There are four channels. The in-app notification centre. Email. Slack and Microsoft Teams channels at the organisation level, for team events. And personal Slack messages - you connect your own account and the bot sends you private messages only for what is addressed to you, with no channel and no webhook. Comments, descriptions and email addresses are excluded from those messages.

Why they are split: a team channel and a personal message solve different problems. The channel is for “the team should know”, the personal message is for “this is waiting on you specifically”. Merge them and the channel becomes noise everyone mutes.

Integrations: Git, MCP, webhooks

GitHub and GitLab connect through signed webhooks. Put the item key in a branch, commit or pull request and the linked branches, commits and reviews appear on the card. No provider access token is stored.

The hosted MCP server connects Codex or Claude Code directly to your organisation’s data through a personal API key. No local server, no Node.js, no cloning a repository. The model runs in your AI client, while WorkThroughLine supplies structured context and executes only the tools your role allows - if a tool is not permitted, the API returns 403. A key sees only its own organisation’s data, with the same row-level isolation as a normal login, and can be revoked at any moment.

Through MCP an agent can read goals, OKRs, interviews, transcripts, analyses, insights, opportunities, solutions, experiments, the whole trace chain, delivery items with context, sprints and reports - and write whatever the role permits.

An interesting case: “read all twelve interviews from this tertial, compare them against the active OKRs and tell me which opportunities have no evidence behind them - do not create anything until I approve”. That is a day and a half of manual work, which is exactly why nobody does it. The answer you get still needs challenging, which I wrote about in the piece on AI as the work surface.

Outbound webhooks push events into your own systems, with a delivery log and redelivery when something fails. REST and OpenAPI documentation live on the developers page.

Jira import, and an export that really restores an organisation

The Jira Migration Assistant connects Jira Cloud directly or takes a CSV. It moves issues, sprints, comments, links, users and Jira Product Discovery context, with a preflight check and mapping of statuses, types, priorities and users before any write. The import only adds and updates - it never deletes - and the same file can be run repeatedly without duplicates. The CSV path also works for Productboard, Aha! and Linear.

Export comes in two shapes. A CSV of work items for a spreadsheet, and a JSON that is a full restore package: configuration, users, teams, all work, history and the attachment files themselves, with integrity checks. A restore runs into a new empty organisation.

Why that matters: it is the only thing that makes a conversation about switching honest. If the exit is not real, the entrance is a trap.

Settings, in one place

This is the part nobody asks for in a demo and the part that changes daily work the most:

• Organisation profile - identity, product, market, strategic direction and ways of working
• Users and invitations - an invitation with an expiry, sent by email and as a link
• Teams and per-team workflow - the names and order of seven delivery steps
• Planning - tertial, quarter or half-year, plus the start month
• Estimation practice - whether a card may leave To Do without an estimate and reach Done without story points
• Working week - which days count, which fixes estimates and end-of-sprint nudges
• Labels and custom fields you define yourself
• API keys - one active per maker, shown once, revocation takes effect immediately
• Import and export
• Audit log of key changes
• Outbound webhooks
• Slack and Teams channels, and separately personal Slack notifications
• GitHub / GitLab connections
• Public portal - the switch and the public address
• Account - two-factor authentication, password change, language, theme

On top of that the app has a command palette (Cmd/Ctrl+K) that searches everything and offers actions, keyboard shortcuts on the board, a dark and a light theme, and runs in four languages: Serbian, English, German and Hungarian.

Roles: who may do what

Five roles. ADMIN runs the organisation and its integrations. PRODUCT_MANAGER edits strategy, discovery and delivery. DEVELOPER edits delivery, documentation and contributes to discovery. STAKEHOLDER has a broad read-only view and participates through comments and submissions. GUEST has a focused view and can file a submission.

The first three are maker roles and count as paid seats. Stakeholder and guest are free, with no cap.

That is a deliberate pricing decision: you pay for what the team builds, not for how many people in the company need to see what is going on. A tool that charges for visibility works against itself.

What does not exist yet

So the list does not read as though everything is solved: there is no active billing or online checkout, no enterprise plan above 30 makers, no SAML/SSO, SCIM or IP allowlist, no contractual SLA or guaranteed 24/7 support, and no choice of data residency region.

If any of those is a hard requirement, we are not the right choice today, and it is better to know that now than after three weeks of evaluation.

Two scenarios, end to end

One: the mid-quarter question. A director asks why the team has spent five weeks on something that was not in the plan. Instead of reconstructing it across three tools, you open the development versus maintenance report for that planning period. It shows 60% of the work sat outside goals, and most of it traces to two support submissions pushed into delivery without an OKR. That is neither an excuse nor an accusation, it is a finding: either those submissions really were more important than the goal, in which case the goal should change, or they were not, in which case who may push submissions into a sprint should change.

Two: a proposal arriving from outside. A user on the public portal proposes something that collects thirty votes. The proposal becomes an opportunity in Discovery. The opportunity picks up evidence from two existing interviews, gets a RICE score and lands third in line - not first. Instead of being rejected through silence, it stays visible on the portal with a status. A quarter later it gets an experiment, the experiment is promoted into a TEST card, it fails, and that stays recorded along with the method. Total time spent on the idea: a few days instead of a whole quarter. Total time saved for the next person who has the same thought: a whole quarter.

Neither scenario requires everything listed above. They require a goal, an opportunity, a ticket and one link between them. The rest is for later, when it starts to hurt.