The map, without
the backlog bolted on.

Three reasons come up repeatedly, and none of them is that StoriesOnBoard is bad at its job. The first is that you do not use Jira or Azure DevOps, in which case its central feature is overhead you are paying for and not using. The second is that tracker sync turns the map into a second view of the backlog: when every card is an issue, the conversation drifts back to tickets and estimates, which is the exact drift story mapping was invented to prevent. The third, and the most common, is that the map cannot hold its own evidence. The research, the recordings, the analytics, and the designs live in other tools, so the map records what you decided without recording why, and a decision without its reasoning gets relitigated.

Integration, and it is worth being blunt about it. Storyflow does not sync with Jira, Azure DevOps, Trello, or any other tracker, so a card on the map is not the same object as a ticket in your backlog and moving one does not move the other. It also does not do backlog management: no estimation, no sprint assignment, no burndown, no workload views. If your team's daily operating surface is the backlog and you want the map to be a lens on it, StoriesOnBoard is the better tool and you should stay. Storyflow is the right choice when the map is a thinking and alignment artefact that needs to sit next to research and design, and hands off to whatever tracker you already run.

Draw the line horizontally, across the entire backbone, and resist every instinct to draw it vertically. A horizontal slice is a thin but working version of the whole journey: a user can get from the start to the end, badly, using only the cards above the line. A vertical slice is one step done beautifully and a product nobody can use. The argument that happens while drawing the line is the value of the whole exercise, because it forces the team to say which step could be crude in version one, and that is a conversation a prioritised list cannot produce. A useful test for the first slice is whether you could put it in front of a real user and learn something. If not, the line is in the wrong place.

Customer journey mapping is the practice of laying out every stage a customer moves through with your organisation, and recording what they are doing, thinking, and feeling at each one, along with the touchpoints they encounter and the friction they hit. It differs from a user story map, which covers the same sequence but hangs the functionality required beneath each step in order to decide what to build first. Journey maps are for finding problems worth solving; story maps are for deciding what to build. A journey map that has been useful usually contains at least one uncomfortable finding, most often a stage where the customer is anxious and the organisation thinks it is being helpful. If yours contains no such moment, it was probably drawn from internal assumptions rather than from talking to customers.

Not during early access. Storyflow is paid-only right now, with plans from $7.99 a month billed annually, and a Free plan launches before the end of 2026. Anyone a paid member invites to a board joins free today, so a client or a stakeholder can view and comment without paying. If you need a free option immediately, Miro's free tier includes story map templates and handles the basic technique perfectly well, and a wall of physical sticky notes is still an excellent way to run a mapping workshop when everyone is in one room. What you give up in both cases is the AI first draft of the backbone and having the research attached to the steps rather than summarised into them.

It can produce the backbone and a plausible set of tasks, which removes the slowest and least valuable part of a mapping session. Describe what a user is trying to accomplish and Storyflow's AI lays out the journey with candidate tasks beneath each step, so a workshop starts with something to argue about instead of an empty wall and a stack of cards. It is also genuinely useful for the two things maps almost always miss, which are error paths and returning users: asking what happens when this step fails reliably surfaces four cards nobody had. What it cannot do is rank by value, because that depends on what your users have told you and what your business needs, and the ranking is the part of the map that carries the decision.

They look similar and answer different questions. A customer journey map is about experience: the stages a person moves through, what they are thinking and feeling, the pain points, and the touchpoints across channels, often including things that happen nowhere near your product. A user story map is about scope: the same sequence, but with the functionality required to support each step hanging beneath it and a release line cutting across. Journey maps are mostly used to find problems worth solving; story maps are used to decide what to build first. Many teams need both, and keeping them on one canvas is useful because a pain point on the journey map should be visibly connected to the cards that address it on the story map.

Yes, and remote sessions have one structural advantage over a room: everyone places cards at the same time instead of queueing behind whoever is holding the pen. Invite the team onto the canvas and build the backbone together, then run a silent ranking round where each person orders the tasks under a step before anyone discusses, which prevents the most senior voice anchoring the ordering. Asynchronous mapping also works, since the board persists and people can add cards and evidence in their own hours. Comments attach to the card they concern, so a disagreement about where something sits stays on that card rather than becoming a message nobody can place a week later.

Enough to decide, and no more. The backbone should be the activities a user recognises, usually somewhere between five and twelve for a product-sized map, and if you have thirty you have started listing features rather than describing a journey. Under each step, the tasks should be small enough to rank meaningfully against one another and large enough that ranking them is a real decision, which in practice means a handful per step rather than dozens. Acceptance criteria, estimates, and technical notes do not belong on the map: they belong wherever the work is tracked, and putting them on the map is the most common way it degrades into a backlog. The map's job is to make the shape of the product and the cut argument visible.

Yes. Send a view-only link and anyone opens the full map in a browser with no account and no download, which matters because slice decisions usually need agreement from people who were not in the workshop. For a document that has to be filed or attached to a statement of work, export the board as a high-quality image or PDF. What does not exist is a structured export into a tracker, since Storyflow has no tracker integration by design, so the handoff to Jira or Linear is a manual step. Teams doing this usually create tickets from the slice above the line once, at the point the release is agreed, rather than keeping two systems continuously in step.