About
A backlog tells you the work. It stops telling you the product.
StoryMap does one thing: it shows a Linear workspace as a product map. This is why that view exists, why its surface stays this narrow, and who is behind it.
Why it exists
Linear is not the problem
Linear is very good at tracking work. An issue is easy to find, easy to update, easy to close, and the tool gets out of the way while you do it.
What gets harder as a workspace grows is the other question: what is the product, and what's missing from it. Individual issues stay perfectly legible while the shape they form does not. Teams answer it anyway — with six saved views, a diagram someone maintains by hand, or one person who happens to remember everything. Those work, and any of them can drift.
StoryMap exists to make that structure visible again without moving the work somewhere else.
Scope
One view, done properly
One board over Linear is the whole surface area, and that is a choice rather than a stage we are passing through on the way to a suite.
It means nearly everything we build makes the same view better: better first placement, better editing, better reading at a glance. We read every request, and the ones we take on are usually the ones that make the map sharper rather than the ones that add a second thing to keep in sync.
Depth over breadth, deliberately — and we would rather tell you that up front than in a release note.
Stewardship
Linear owns the issues. StoryMap owns the map.
Arranging a board doesn't move, edit or close anything in your workspace. Nothing is changed in Linear. And because we never become the canonical record of your product, deciding to stop is a matter of switching off a view — there's no parallel backlog to migrate back.
That boundary is the most important design decision in the product. It keeps the board honest, and it means adopting StoryMap is a reversible decision.
- We keep
- Journey columns
- Release slices
- Where each issue sits
- Linear keeps
- Titles and descriptions
- Status, assignee, estimate
- Cycles, projects, comments
The name
Why it's called StoryMap
The grid comes from user story mapping: what people do across the top, what ships when down the side. That is where the name comes from.
The practice it comes from is a good one, but StoryMap doesn't ask you to adopt it. There is no formal user-story syntax to learn and nothing to rewrite: the board works with the issues you already have, phrased however your team phrases them.
Who builds it
Built and run by Kriasoft
StoryMap is built and operated by Kriasoft. It is a small enough team that support isn't a queue: if something breaks or a placement looks wrong, you are writing to the people who build it.
See it on your own workspace
Everything above is easier to judge with your own issues on the board. Connect Linear and the first map builds itself.
Nothing is changed in Linear. No credit card, and free up to 150 mapped issues.