Section 1
Rank workflows, not technologies
Begin by listing the places where work waits for a person to collect, read, format, or route information. Every one of those is a candidate. Then rank them on three things you can actually estimate: how often the work happens, how much time it consumes each time, and what a wrong output would cost. That third factor does most of the sorting. High frequency and low blast radius is where a first automation belongs. High stakes and low frequency almost never belongs on a first roadmap, no matter how impressive the demo. Founders reliably get this backwards because the impressive workflow is the one that gets talked about. A useful account of what the early sequence looks like in practice is [Startup Success: How AI Automation Transformed Our Business](/blog/startup-success-how-ai-automation-transformed-our-business).
Section 2
The first three, and why they are small
A good first quarter contains roughly three workflows, all boring. Something that reads incoming information and structures it. Something that drafts a repetitive output for human review. Something that assembles a report somebody currently builds by hand. The reason to keep them small is not caution for its own sake. It is that the first three exist to teach the organisation how to run this work at all: how to baseline, how to review, how to decide something failed. That capability is the actual deliverable of the first quarter. The time saved is a bonus. Teams that skip this and start with an ambitious agent spend the same quarter learning the same lessons, just more expensively and in public.
Section 3
Every item needs a kill condition
Write the stopping rule at the same time as the item. If the correction rate is above this level after six weeks, we switch it off. If the baseline metric has not moved by this date, we retire it. Roadmaps without kill conditions accumulate abandoned automations that nobody turns off, and each one is a small liability still running.
Section 4
Sequencing the work itself
Take the top item and write the business sentence first: we lose time because this work waits for a person to collect, read, format, or route information. Then measure the baseline. How long it takes, how often it breaks, what the delay costs. If you cannot measure the baseline, that is the first task, not a reason to skip it. Build narrow. One data source, clear input rules, a human review step. When the output is reliable, connect it to the system the team already works in. Then, and only then, take the next item off the queue. Parallel builds look faster on a plan and are slower in reality, because a two-person startup cannot debug three workflows at once.
Section 5
Governance sized for a startup
A twelve-person company does not need a committee to apply the NIST language of trustworthiness, design, evaluation, and use. It needs a single page listing every automation, what data it can read, what it can change, who owns it, and what it must never decide alone. Maintain that page from the first automation. Retrofitting it at automation number twenty is genuinely painful, and by then nobody remembers what the second one was connected to. Keep sensitive data out of prompts that do not need it, log automated actions, and keep a human owner for anything affecting money, employment, legal exposure, safety, or customer trust. That is the whole governance requirement at this stage.
Section 6
Reviewing the roadmap on a cadence
Review monthly and expect the queue to reorder. Ask five questions: what moved faster, what quality improved, what risk appeared, what humans still had to fix, and what should be retired. The roadmap is working if items get killed. A queue where every item shipped and nothing was retired usually means nobody measured anything. Track cycle time, rework, adoption, and exception volume on shipped items rather than counting launches, since count of automations is the metric that flatters a roadmap while telling you nothing. On communicating progress internally without overstating it, see [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation).