I like Kanban.
Genuinely. A board with columns is a good invention. Planned, Started, In review, Blocked, Finished. When work starts multiplying, being able to see where everything sits is much better than keeping a foggy pile of obligations in your head.
The trouble starts when I treat the column as if it knows more than it does.
A card in Planned might be the thing that saves the week, or it might be something I added at midnight because planning felt easier than deciding. A card in Started might deserve another hour, or it might be a sunk cost wearing a little badge of legitimacy. A card in Blocked might need my attention, or it might be an expensive fantasy waiting for a polite excuse to stay alive.
Kanban tells me where the task is. It has very little to say about whether the task deserves to exist.
That gap is why I built Eisengrid around a priority/effort matrix first and Kanban second. I wrote the broader product intro in the previous post. Here I want to get at the part that kept bothering me: status feels objective, while priority is where the lying starts.
The project that made it click
Recently I used an LLM agent to turn a large, messy, real-life project into Eisengrid tasks.
The project was a resilience plan for a rural family house. Not a productivity hobby. Boring infrastructure work: water, heat, power, comms, food, medical supplies, sanitation, mobility, documents, offline knowledge, and the recurring checks that keep all of it from becoming a one-week burst of good intentions.
The agent produced a sensible plan: set up the site binder, audit the property, make water and heat less theoretical, measure power needs before buying power gear, build food, baby, medical, and vehicle fallbacks, then add rotation checks so batteries, pantry stock, fuel, documents, and go-bags do not silently decay.
Inside that plan were tasks like:
- store an immediate potable water reserve
- clean and inspect unused rainwater tanks
- measure roof catchment and tank capacity
- build a potable water treatment stack
- audit the hard wood boiler
- prove the boiler can run during grid failure
- build a survival power budget
- test cameras for local offline recording
- create a family calorie and pantry baseline
- build a baby and toddler resilience cache
- make vehicle go-bags real
- create document and cash caches
- build an offline knowledge library
- set up water, pantry, battery, boiler, and relocation checks
A Kanban board can hold every one of those cards. Most of them landed in Planned, which was accurate and almost useless.
The thing I needed to know was sharper: which task changes the family's risk profile soonest, and which task merely looks responsible because it has a serious noun in it?
A status column does not answer that.
Planned is too blunt
Take two water tasks:
- Store immediate potable water reserve.
- Investigate well or groundwater feasibility.
Both belong in the plan. Both can sit in Planned. They should not feel equal.
The first one is high priority and low effort. Buy the water. Label it. Store it somewhere sensible. Put it in the rotation. Nobody gets to feel like an engineer afterward, but the first ugly weekend gets less ugly.
The second one may matter someday. It also comes wrapped in uncertainty: local rules, drilling cost, yield, pump options, maintenance, power, testing, and the unpleasant possibility that the ground simply refuses to cooperate. Worth researching, yes. Worth treating like the same kind of work as "buy drinking water before you need drinking water", no.
A Kanban column can only show that difference if I add labels, colors, custom fields, or a private mental note.
The private mental note is exactly where my systems tend to fail. If memory were reliable enough, I would not be shopping for a task manager in the first place.
The matrix makes the lie visible
In Eisengrid, each task gets two coordinates:
- priority: how much it matters
- effort: how expensive, difficult, or annoying it will be
That creates four regions:
- high priority, low effort: do first
- high priority, high effort: schedule seriously
- low priority, low effort: batch, delegate, or use as filler
- low priority, high effort: probably eliminate
It sounds almost embarrassingly simple, which is part of the appeal. A list gives me a lot of obligations. A Kanban board sorts those obligations by workflow. A matrix points at the handful of cards I am probably using to avoid a decision.
The Eliminate quadrant is the one I did not know I needed.
Adding tasks is easy. Making a plan look more serious by making it larger is easy. Turning anxiety into inventory might be the easiest productivity trick in the world.
Looking at a card and admitting, "low priority, high effort, wrong week" takes a different muscle. Nothing moved from Planned to Started. No progress animation fires. There is just a small value judgment, made before the task has a chance to occupy the next three months rent-free.
Kanban will not force that moment. A matrix makes it harder to dodge.
Flow still matters
Eisengrid still has Kanban because judgment alone does not finish anything.
Once I know what matters, the work still has to move through reality. The water reserve can move from Planned to Started to Finished. The boiler audit can be Blocked while waiting for a technician. The pantry baseline can sit in Review while I check whether the numbers are real. Recurring inspections keep the system from turning into a heroic spreadsheet nobody maintains.
Kanban is good at flow. I just do not want flow in the wrong direction.
I do not want to become efficient at finishing low-value work because dragging cards feels nice. I do not want Started to become a polite graveyard for tasks that should have been killed earlier. Blocked should not give impossible ideas permanent residency just because they have a column.
The workflow I keep returning to is simple:
- Use the matrix to decide what deserves attention.
- Use Kanban to move that work through execution.
- Go back to the matrix when the list starts feeling too comfortable.
I want the matrix upstream, where choices are still cheap, and Kanban downstream, where the chosen work has to move.
Agents make the judgment problem louder
The agent angle made this obvious faster than I expected.
LLMs are extremely good at expanding work. Give an agent a project brief and it can produce milestones, dependencies, definitions of done, checklists, recurrence rules, and a structured import. In my case, Codex can add tasks into Eisengrid through the API, so the jump from "thinking about the plan" to "tracking 100 new tasks" is tiny.
Useful, yes. Also a little dangerous.
Before agents, creating 100 tasks by hand was annoying. That annoyance acted as a filter. You hesitated. You decided whether the thing was worth typing.
Now an agent can produce a beautiful backlog in seconds. The bottleneck moves from capture to judgment.
Which tasks should exist? Which belong this week? Which are real dependencies? Which are soothing abstractions? Which are important but too large to touch casually? Which ones keep attracting me because they are fun and technical and safely distant from the uncomfortable work?
A matrix gives the agent somewhere to put that judgment. I want AI to do more than add tasks. I want it to help place them.
"Install survival PV plus LiFePO4 battery plus critical-load subpanel" may be important. "Install energy monitoring plugs" may be small. The small task might still be the correct next move because it turns a future purchase from guessing into measurement.
Both can be Planned. They should not take up the same amount of space in my head.
The board I actually want
For the resilience project, I do not want a heroic list. I want a ruthless one.
I want the board to keep pulling me back toward tasks like:
- build the site binder
- inventory the assets
- store the immediate water reserve
- verify fire and CO safety
- measure power consumption before buying solar
- find out whether the wood boiler is safe during grid failure
- make sure the baby cache exists
- make vehicle go-bags real
- create recurring rotations so nothing silently expires
And when I drift toward elaborate low-priority projects because they are interesting, I want the picture to make that drift a little embarrassing.
A normal task manager helps me remember tasks. Eisengrid exists because I needed a way to distrust the list.
Software has the same failure mode
Houses and emergency planning just make the shape of the problem easier to see. Software teams do the same thing every day.
A GitHub issue can be open, in progress, blocked, or done. Helpful. Still, the status says nothing about whether the issue matters.
A feature can be Started because I got excited. A bug can sit in Planned while it quietly taxes users every day. A refactor can look responsible while mostly serving as procrastination. A marketing task can be small and terrifying, which is often a sign that I should stop circling it.
Status still is not strategy. The Kanban board is where movement shows up; the priority/effort matrix is where the tradeoff is harder to ignore. I want both, in that order.
The question I keep coming back to is: which tasks am I using to avoid the work that matters?
A list will not answer that. A Kanban board only answers part of it.
Kanban tells me status. The matrix shows me what I am pretending not to know.