Lmapping

The roadmap
anyone reads.

Status is a colour. Phase is a position. Draw it on any canvas, and an AI reads and updates it.

APR
MAY
JUNE
JULY
AUG
SEPT
USA: new paiement systemrelease on 13th april
Brazil: business case
Brazil: go/no goend of june
Brazil : rolloutmid aug
France: Kickoffapril 12/14/16
France: Solutionlocalisation needs / RGPD DB
France: Specsvariation on RGPD
France: Devspecificities
France: QAFrench local team for UAT
France: RolloutGTM ready last week of Sept
USA - migration FIA DB
USA - migration FIA DBUAT env MISSED
USA -migration FIA DBreported to x??
  • Demand
  • Intend
  • Commit
  • Solution
  • Specifications
  • Development
  • QA
  • Done / Release
  • Blocked
  • Attention

Three roadmaps that disagree

You cannot present a Gantt to leadership.

The portfolio lives across tools that never quite match. Open it in Jira or any Gantt and nobody sees the shape: cryptic tickets, cramped bars, a legend you re-learn every time. You make mistakes, and you certainly cannot put it on screen in a steering committee.

Jira / Gantt tool

Same portfolio. Dense, cryptic, unreadable in a room, and impossible to present.

The same portfolio in Lmapping
JUL
AUG
SEP
OCT
NOV
DEC
USA kick start next release(Q4)
Spec release USA Q4
USA: Vblog + Media player V2
USA: FRS usability redesign
USA: SDK27 + security components
USA: Vcard contact update
Brazil : rolloutmid aug
France: Devspecificities
France: QAFrench local team for UAT
France: RolloutGTM ready last week of Sept
USA -migration FIA DBDue 17 sept
USA -migration FIA DBUpdate USA systems

Readable at a glance, ready for leadership, and an error you would have missed jumps out.

One Lmapping board holds every level of detail and doubles as the leadership view. A slip jumps out, you present it as-is, and you draw it in a tool you already know.

The notation

Learn the whole system in a minute.

Status is a colour. Phase is a position. Two independent axes, a closed set of statuses, a small grammar of modifiers and arrows. That is the entire language.

Status is the colour

A closed, deliberately-sequenced lifecycle. A colour means the same thing anywhere on the board, so nobody re-learns a legend.

  1. Demand1Raised, not yet adopted onto the roadmap.
  2. Intend2Adopted as an intention, being shaped, not committed.
  3. Commit3Committed to a target period. Committed is not started.
  4. Solution4Work begins here: the solution is defined. First active phase.
  5. Specifications5The first release is specified. Handover happens at the end.
  6. Development6In build. The delivery zone.
  7. QA7In verification.
  8. Done / Release8Delivered and released.

Modifiers sit on any card

  • AttentionAn orange fill, or a thick red border. The card keeps its status.
  • BlockedA solid red fill. The only fully-red status.

And on the board

  • Release cartoucheA grey box grouping cards that ship together as one release, tagged at the bottom.
  • Kick-start arrowOne arrow from where a project starts to its final card. The chain in between stays hidden.
  • Current monthThe live month is called out in bright pink, so the eye lands on now.

Read through the full notation system and its usage rules, the whole language on one page.

The full notation and rules

How it works

Read a card.

A card carries two signals on two independent axes. Change one, and the other holds. That is what keeps the board unambiguous.

Status is the colour.
May2026
Jun2026
Jul2026
Aug2026
Public APISolution

Phase is the name and the column.

Status (colour)

Solution

Target month (position)

Jul 2026

Solution. Work begins here: the solution is defined. First active phase.

Two signals. Two axes. They never collide.

The life of a card.

One card, from a demand to a shipped release. It commits, then expands: the chain is retro-planned back from the release month. Each phase goes active as now reaches the left edge of its month. The name never changes, only the status and its colour.

Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Public APIDemand
DemandMid-December: a demand is logged, placed on its target June. Status Demand, time is already moving.

Committed is not started. Work begins at Solution. Once detail lands, a slip cascades the chain downstream.

One model, every zoom

One roadmap. Every level of detail.

Collapse a project to a single card for the published board, or expand it into its full milestone chain for the team that runs it. Flip between them here. Same model, same colours, always in sync, never a second roadmap that drifts.

JUL
AUG
SEP
OCT
NOV
DEC
USA kick start next release(Q4)
Spec release USA Q4
USA: Vblog + Media player V2
USA: FRS usability redesign
USA: SDK27 + security components
USA: Vcard contact update
Brazil : rolloutmid aug
France: Devspecificities
France: QAFrench local team for UAT
France: RolloutGTM ready last week of Sept
USA -migration FIA DBDue 17 sept
USA -migration FIA DBUpdate USA systems

Published view. The Q4 release and the migration sit as single cards, the chain hidden. Readable across the whole portfolio.

Lmapping vs the usual way

The same roadmap, read two ways. Pick what you are trying to do.

Know a card's status instantly, anywhere on the board

The usual way

Colour means different things per column or tool, so you re-learn the legend

Lmapping

Status is one colour, same meaning everywhere (status is independent of phase)

The wedge

Built for an AI to read. And to run.

Because the notation is real (colour, position, arrows, a legend map), the board is data, not a screenshot. The agents you already use read it, and with the write-skill they update it, in valid notation.

Read by the agents you already use

AnthropicOpenAIMistralQwenGLM
The same board, as structured data
{
  "board": [
    { "card": "Passkey login", "month": "Jul 2026", "status": "QA" },
    { "card": "Public API",    "month": "Sep 2026", "status": "Solution" },
    { "card": "Search v2",     "month": "Aug 2026", "status": "Development" },
    { "card": "Home widgets",  "month": "Sep 2026", "status": "Commit" }
  ]
}
Read the boardFree

An AI reads it.

The read-skill turns a board into structured data: cards, status, phase, cartouche, arrows. Register for early access and it ships free, with the white paper and a full course (PDF and video) on the notation and how to run it yourself, plus best practices and use cases.

Live today on Miro, already in daily production use. More canvases follow.

Get the read-skill free
Run the boardMembers

An AI runs it.

The write-skill applies changes back to the board, in valid notation. A community capability: one lifetime licence, no subscription.

Founding price $19.99 for the first 100, then rising in steps of 100.

Join the community

Draw it where you already work

MiroExcalidrawFigJamtldrawany whiteboard
Voice captureDemand
Voice captureDone

A box, a colour, an arrow. That is the whole tool.

If you can draw a box and an arrow, you can draw a roadmap.

Lmapping is a notation you own, not software you rent. Like C4 or Wardley Maps, for roadmaps.

Any canvas

A whiteboard, a diagram tool, a sticky wall. The notation is the product, not an app.

Seconds, not hours

Move a card, change a colour. No re-planning ceremony, no export.

Zero lock-in

No dependency on Jira, Aha! or any paid platform. Open and free.

For product and program leaders running multi-team, multi-release portfolios.

Tired of roadmaps that mislead, drift apart across tools, take hours to update, and can't be read by their AI.

Lmapping is an open roadmap notation and delivery method that encodes status, phase, dependencies and governance into one board a human and a machine read the same way.

It is radically simple to draw. Any tool that can place a coloured box and an arrow does it (Miro, or any basic drawing canvas), with nothing complex to learn and changes made in seconds, not hours. And it carries zero lock-in to Jira, Aha! or any paid platform.

Unlike Gantt charts, Kanban tools and roadmap SaaS, which carry state but not a rigorous, machine-readable notation and tie you to their software, Lmapping is at its core a simple, modular drawing that expands as you grow and can be managed by you or by an AI.

The roadmap itself becomes the single, unambiguous, AI-ready source of truth.

  • Demand
  • Intend
  • Commit
  • Solution
  • Specifications
  • Development
  • QA
  • Done / Release

Do not ship a tool. Be the notation.

Get early access.

Leave your details for the spec, the reference tooling, and an invite when the community opens.

optional

The L is for Limare

Lmapping is Nicolas Limare's method.

The L in Lmapping is Limare. Nicolas Limare is a digital product and UX leader with 29 years of experience, in CPO and executive roles across global groups including IBM, LG, Technicolor and BioNTech. He builds and scales digital and phygital products, and the multidisciplinary teams behind them.

Lmapping is the roadmap method he designed and battle-tested over 15 years, across every digital and phygital product he has shipped. This site and its specification are its first public release.

Nicolas Limare on LinkedIn