Testing a Project Tool on a 40-Person Launch: Where It Broke
Forty people used one project tool for eleven weeks to ship a product launch, and the tool held until 26 users, then began to cost more time than it saved. The breakpoint was not performance or licensing. It was the number of people who needed to see the same task differently.
The launch involved engineering, design, content, support and a regional sales team in three countries. The tool was chosen in a week, because that is how long the team had.
What the tool did well
Up to 26 users, the tool behaved as advertised. Tasks were created in seconds, the board was readable without training, and the mobile app was good enough to use on a train. Two engineers who had never used it required no explanation beyond a five-minute screen share.
The first month produced 340 tasks and no complaints, which is a better result than most software purchases achieve.
The 26-user breakpoint
The 26th user was the support team lead, who needed a view of upcoming work rather than a view of the board. She asked for a filter that showed tasks by release date rather than by status. The tool could not combine those two dimensions without duplicating every task into a second project.
Duplication was accepted for a fortnight and produced 190 duplicate tasks, which then drifted apart.
Where the duplication hurt
Two sources of truth are worse than a bad one, because each looks authoritative. Support began reporting from the release view, engineering from the board, and the weekly status meeting spent nine minutes reconciling the two.
By week five the reconciliation had a name and a habit, which is how a workaround becomes part of the process.
The custom field attempt
The team tried a custom date field and a saved filter, which technically worked. The cost was that every task creator now had to fill a field they did not care about, and 41 percent of new tasks arrived without it.
A field nobody fills is a filter that lies. The team removed it in week six.
What people actually needed
Interviews with nine users produced a simpler description than the filter request. Support needed to know what was coming next week. Engineering needed to know what was blocked. Sales needed to know what had shipped. Three questions, three audiences, one board.
The team stopped trying to solve all three inside the tool and published a short release note every Friday, which answered two of the three questions better than any filter.
The mobile gap
Task creation worked on mobile. Task editing did not: the description field lost formatting on save, which mattered for the six people who wrote specs inside the tool. They moved specs to a document and left a link, which is a reasonable pattern and a quiet admission that the tool was not a writing surface.
Two people continued writing specs in the description and simply accepted the lost formatting for eleven weeks.
The cost over eleven weeks
Licensing came to 340 euros for the period. The measurable time cost was the weekly reconciliation, about nine minutes across five people, plus the removal of the custom field and the migration of 190 duplicates. The team estimated 14 hours total, which is more than five times the licence cost.
Time is the honest unit for this kind of tool, because the licence is rarely the expensive part.
What the team kept
The board stayed. Forty users are now 40 users of a board and a Friday release note, with specs in documents and a single source of truth for status. The tool was not replaced, because replacing it would have cost more than the reconciliation.
Twenty-six users was the point where one board stopped answering three questions. The fix was not a bigger tool but a shorter note, and the launch shipped on the date it was given.
