One Concept, One Example, One Question

The concept

You can learn a lot the first time someone tries to use a system. I don't just mean whether the tool works, but whether someone new to the process can start work without guessing steps. Can they find the right place to start? Do they know what success looks like? If something fails, is the next move obvious? I refer to this as the first-day path.

A first-day path is the route a person new to a process follows when they start a piece of work without access to all the background that the original team carried in its head. Sometimes that means a new starter setting up their laptop. Sometimes it's a colleague taking over a monthly process, and sometimes it's a team trying to use an AI assistant that someone else has configured.

The path doesn't need to explain everything, in fact it probably shouldn't. A good first-day path gives someone just enough structure to make the first useful action safely. It shows the starting point, the expected result, and what to do if something goes wrong.

I see this most often with processes that already feel familiar to the team. The people who built them know which warning can be ignored and which failure means "stop". They also know who needs access, and the small timing details that never quite make it into the documentation. That knowledge can make the work feel simpler than it is. The first-day path tests whether the simplicity belongs to the process or to the memory of the people already inside it.

I think the same test becomes sharper when AI enters the work. Before asking an assistant to help with a repeatable task, someone still has to define the first safe action and the expected result. The review point matters too: where should the system stop rather than carry on with false confidence? If those boundaries are missing for a new colleague, they're probably missing for the assistant too.

The example

Imagine a team preparing to bring in a new analyst.

The work itself is familiar to the existing team. They know where the data comes from, how the main report is produced, and which checks matter before it's shared. From the inside, the process feels manageable.

On the analyst's first day, the test is different. They need to get access and run the report without turning every screen message into a question for someone else. They also need enough context to recognise a normal result and stop when the numbers look wrong. If someone has to sit next to them and translate every message, the process may still work, but the handover hasn't really happened.

A better first-day path might be modest. It could start with a setup script and a small test dataset, with a plain checklist beside them. The analyst runs the setup, produces a sample report, and compares it with an expected result. A missing permission means asking the data owner; a changed total means stopping before anything is shared. Any exception is recorded in a place the team actually reviews.

This shows that the analyst can enter the work without guessing. It also teaches something practical from the run: if the analyst reaches the comparison step but can't open the source file, the next improvement is access, not another explanation of the report.

The same idea applies beyond onboarding. If a monthly process or internal tool can't survive a first-day test, it isn't yet ready to spread. The same is true for an AI-assisted workflow. The next improvement is often a clearer route into the work.

The question

Ask yourself:

Could someone new to the work take the first real step without relying on the builder's memory?

If the answer is no, the next step may be to design the entry route before expanding the work. A good first-day path makes support more focused by giving the obvious unknowns somewhere to land.

Elsewhere this week…

• I published What capabilities and roles are needed as an organisation moves beyond operational reporting?, on the shift from reporting as output production to the capabilities needed for insight, ownership, and better decisions.

Support

Everything I publish here is free to read, and always will be.

I maintain this newsletter and my website in my own time. If something here has been useful to you, and you'd like to help cover the costs behind that work, you can support me through Ko-fi.

Generative AI is a powerful tool. I openly use it to conduct research, challenge my thinking, draft, and review my work. AI never owns what I think, or my personal judgement. Everything I publish reflects my own thoughts and opinions.