The feedback channel dies in month three because nothing in it ever shipped

A write-up on dev.to of an internal AI video-generation project names the failure mode most enterprise rollouts share: a feedback channel opened in week one with real enthusiasm, a burst of suggestions in the first month, and silence by the third, not because people ran out of opinions but because nothing they said came back as a release ^[1]. The author's argument is that adoption is governed by release latency rather than by training, and that matters because the standard remedy for low usage is more enablement, which does nothing about latency ^[1][9].

The framing rests on a gap the author draws from Deloitte's latest survey: sanctioned AI access sits at close to 60% of workers, and fewer than 60% of those use it in daily work ^[2]. Taken together that puts daily use below roughly 36% of all workers, which is a usage problem, not an access problem ^[3].

The project itself was deliberately small: a tool generating training videos for one training team, simple functions, one job ^[4]. The build ran in stages of two to three weeks at most, and each stage had to end in a working increment in the team's hands rather than a demo or a prototype behind glass ^[5]. On the day the first increment shipped, the team opened a dedicated channel with everyone who used the tool, and feedback arrived daily: bugs, friction points, and feature ideas from the people doing the work ^[6].

The operating rule is the part worth copying. According to the author, the AI team had one standing instruction, respond the same day, and a short daily meeting with the lead of the using team in the room decided what got built that day or the next, with releases going out daily carrying fixes and users' own ideas ^[7]. They called it a zero-backlog policy: a suggestion either ships within a day or two, or you hear the same day why it will not ^[8]. The claimed mechanism is signalling. A suggestion implemented within a day is visible proof that the user shapes the tool; the same suggestion parked in a quarterly backlog is proof of the opposite, and both are received clearly ^[9].

The reported outcome is a change in pronoun. The team stopped talking about "the AI tool" and started talking about the features they had asked for, corrected each other's usage in the channel, and reported breakage the way people report problems in something that is theirs ^[10]. Company-wide presentations were given by the users rather than the AI team ^[11]. One metric was tracked from day one, finished videos per week, chosen because the business already cared about it before the project existed, rather than prompts sent, logins, or satisfaction scores ^[12].

Two constraints keep this from being a general prescription. The author is explicit that zero backlog is a launch regime, not a way of life: it is expensive, it consumes the AI team, and it is worth paying for only while the organisation is still deciding whether the tool is theirs or something being done to them ^[14]. Once that settled, the cadence relaxed to every other day, then weekly ^[13]. And traceability and audit were built into the first increment rather than added later, on the reasoning that any governed path slower than the ungoverned one gets bypassed ^[15].

What to watch is the six-month build. If nobody can touch the thing until month six, feedback cannot start until the window for winning people over has already closed ^[16].