Your Agent Needs
a Roadmap From You

With a roadmap, my focus goes to two things. The first is deciding what comes next, and sometimes defining it more clearly. The second is reviewing what the agent built before I release it to my customers.

Everything in between is the agent’s. That is the trade: I give it more responsibility for the execution, and my own part shrinks to something that fits into a few minutes. Here is one item, from the first message to my review.

Steps one and five are mine. The three in the middle happened without me. And my review was a real one: I had expected the page inside the settings, not standing alone. It was there too, under settings, with a switch between my own workspace and the general page. That is how I had imagined it.

Then the feature is finished, it gets released, the roadmap updates itself and we move on to the next item. I do this about twice a day: see where the roadmap stands, give feedback, say what is completed and what to work on next. I call it shepherding. I’m not doing the walking. I’m pointing the herd in the right direction.

Because each project has its own roadmap and its own roadmap session, this holds for all of them at once. And as step three shows, the sessions of different projects talk to each other: one states what it needs, the other builds it.

If the agent can do the middle, why not hand over the deciding too? Because that is exactly where the models are still weak. Two things I see again and again:

• They are not good at deciding what is next. I’ve rarely seen an agent get it right, even with the latest models like Anthropic’s Opus and OpenAI’s Astra.
• They build more than is reasonable. The solution is often far more complex than the problem, and that becomes really hard to maintain.

So if you just ask the agent what to build, or let it read the feedback from your users and your error logs and go, your product moves in a direction that neither you nor your users want.

The agent had read our whole project tracker and the recent work, and its list was a good start. It was right about number one. But the hackathon wasn’t on it, because nothing in the code says that an event in November needs its tracks defined and its communication started now. I know that. It’s my business.

That is the advantage we still have as humans: a very broad view, and a taste for what is relevant for our audience and our own product vision. The agent serves me a palette of ideas. I act as the curator and say what is most important right now, to me as the owner and to the people who use what I build.

I still do my best to give the agent the context to suggest better: what the product is, who it is for, and our philosophy of building things simply. Write that down once, in your project rules, and its proposals improve. They become a better palette. They don’t become the decision.

Product people argue about this. Some say the roadmap is dead, others say it is the last job we have. I’m in the second camp. Now that we can build anything, it is up to us which ideas to pursue at all, and, for each of them, what the next most important thing is. I wrote before that the future is not zero-human, but augmented-human. The roadmap is where the human sits.

A roadmap doesn’t need to be more than one page. Your agent probably already reads a few: what the product is about, the audience, the tech stack. The roadmap is one more, next to them. I always use the same four stages: my ideas, what is planned, what is in progress and what is completed. Here they are with real items from my new product Zawq:

Three things make it work:

• The agent ranks, you confirm. It writes the order and its reasons. Nothing counts until you agreed or changed it.
• Only “In Progress” has a fixed order. Planned and Ideas get re-ranked as you learn.
• It updates itself. When an item ships, its card moves to Completed. You never maintain the page by hand.

The layout is up to you. My Customer Magic roadmap has a short “build first” group with letters and a longer list below. The one for Pirate Skills looks like a board in our project tracker, with stars on what matters most. What I care about when I check in is the same everywhere: the top of the pile.

The bigger question is where you want to work with it. Pick the place that is most convenient for you. I see three options.

The first is the easiest. In Claude Code these pages are called artifacts, and as far as I know they come with every paid plan; I always assume at least the $20 one. I used to insist that everything lives in the codebase. My newer projects have shown me how convenient a page is that is simply online. If you don’t want a whole project tracker, it’s excellent.

The second is for you if you don’t want to depend on one tool. Ask for the roadmap as a styled page in your documentation folder. It gets a history, and whichever agent you open tomorrow can read it.

The third is what we use for Pirate Skills: Linear. A tracker holds the prioritized issues, and agents that run on a schedule can take the top one and update it when they are done. That is how our self-driving loops work. A tracker also fills up. When I set up the roadmap process this week, the first thing the agent did was tidy: the list of projects in progress went from 34 to 17.

You can mix them. For Pirate Skills, Linear is the source and a mirrored page is what I read. For Zawq and Customer Magic, the page is all there is. And none of this is only for software: the hackathon, the event slides and the compliance work sit on the same roadmap as the app. If you plan your marketing with a growth roadmap, it belongs on there too.

Setting this up took me one message and two corrections. Open a new session in your project, decide where the page should live, and hand your agent this. It starts by reading and by asking you questions:

The first version won’t look the way you want. Mine came back as a plain document, so I sent a screenshot of a board I like and asked it to look more like that. Then I asked it to mark its own opinion clearly, so I could disagree with it. That disagreement is the whole point.

From then on, this is the check-in:

If you’re not sure what belongs at the top, start from your numbers: what to improve is the question behind every good roadmap. And if the project doesn’t exist yet, the first item is your idea.