A team gets a new internal tool. Someone has to try it first, and in many companies that someone is whoever happens to be free, or whoever volunteered loudest. Two weeks later the rest of the team has heard a story about the tool, and the story is hard to change.
This article is for the head of operations or a department lead who is about to introduce a tool and wants the first contact to go well. It covers how to choose the first user, how to spend two weeks working with them, and what to take from it into the wider rollout. It is about ordinary business tools, not about any specific product.
Why the first user matters
The first user does three jobs, whether you plan for them or not. They find out whether the tool fits the real work. They show the rest of the team what using it looks like. And they tell their colleagues, in the kitchen and in chat, what they think of it.
If the first user struggles alone, the team hears that the tool is difficult. If the first user is a known enthusiast, the team hears that it is fine for people who like gadgets. Neither is a fair test. Our article on change management and technology adoption makes the wider point that adoption is mostly a people question; the first user is where that question starts.
How to choose
Look for a person who meets most of these criteria.
- Does the real work often. They should use the tool for tasks that happen several times a week, so that two weeks give enough examples. Someone who does the task once a month will learn little.
- Says what they think. You need honest remarks, including "this step makes no sense". A polite person who never complains gives you nothing to fix.
- Is respected by the team. Colleagues should believe them. This is about trust, not about job title.
- Has a bit of time. They need perhaps thirty minutes a day of slack at the start. If they are in the middle of a deadline, pick someone else or move the date.
- Is neither a fan nor an opponent. An enthusiast forgives faults, and a sceptic finds faults in everything. A person with a neutral or mildly curious attitude gives the most usable picture. If you want both views, add them as a second and third user later.
Ask the person, do not assign them. Explain that you want their honest view and that problems they report are the point, not a failing on their side. Tell their manager, so the time is accepted.
Before the first day
Spend an hour on preparation. Write down three or four real tasks the person will do with the tool in the first week. Make sure they have access, and that the data they need is in place. Decide who they can ask when stuck, and promise an answer the same day.
Also agree what is not being tested. If the tool is unfinished in some area, say so, so that known gaps do not look like new findings.
The two weeks
Keep the rhythm simple.
Day one. Sit with the user for thirty minutes while they do the first task. Do not explain unless they are stuck, and write down where they hesitate. Hesitation is data.
Days two to five. The user works normally. Ask them to keep one note, in any form, where they write a line each time something is slow, unclear or wrong: what they were trying to do, what happened, and the date. Meet for ten minutes on the third day to look at the note and remove any blockers.
Second week. Meet twice more, again for ten minutes. In the first meeting, sort the notes into three piles: things to fix in the tool, things to teach, and things to ignore. In the last meeting, ask three questions. What would you tell a colleague about the tool today? What would make you stop using it? What do you do now that you did not do before?
Throughout, keep your own role small. You are there to listen and to remove obstacles, not to defend the tool. If you answer every complaint with an explanation, the user will stop complaining and you will lose the information you came for.
What to record
A short table is enough. For each snag, write the date, the task, what happened, how serious it was (blocked the work, slowed it down, annoyed), and what you decided. Three or four snags that blocked work are a reason to pause the rollout. Many small annoyances are a reason to fix the most frequent ones first and teach around the rest.
Also record what went well, with an example. "Prepared the weekly summary in twenty minutes instead of an hour" is far more persuasive to the next group than any general statement. Do not invent or round the numbers; use the user's own estimate and say it is an estimate.
What to take into the wider rollout
At the end of the two weeks, make one decision with three parts.
- What to fix before others start. Only the blockers and the most frequent slowdowns. The rest goes on a list with an owner.
- What to teach. Turn the user's questions into a short guide, written in their words. People trust a guide that sounds like a colleague. The guide then feeds directly into your plan for the first month after launch.
- Whether to go wider, wait or stop. Go wider if the tool helped with real tasks and the blockers are fixed. Wait if the blockers need more work. Stop if the user would not use it again and you cannot explain why that would change. Stopping after two weeks with one person is much cheaper than stopping after a rollout to fifty.
Then ask the first user to help with the next one or two people. They have become the best teacher you have, and they now have a stake in the tool working.
When the tool is small
For a small tool, such as one that replaces a shared spreadsheet, the same method works with less ceremony. One user, one week, two short meetings. The article on moving from a spreadsheet to a small internal tool describes how such a tool is built and switched over; the first user is the person who tells you whether the switch will hold.
What to do this week
On Monday, write down the three or four tasks the tool is meant to help with. On Tuesday, list two or three candidates and check them against the criteria. On Wednesday, talk to your first choice and their manager. On Thursday, make sure access and data are ready. On the following Monday, sit with the user for the first task and start the notes.
Sources
- Our related articles linked above.
- The method is a general approach and does not describe a particular company, tool or supplier.
