Salesforce's AI Org Routes Field Feedback Through One Slack Channel. Kill the Channel as the Loop.

Aakash Gupta's interview with Jayesh Govindarajan is the most detailed public description of an AI-native product org at a company of Salesforce's size, and one of its six steps is an inbox pretending to be a loop. This is a Kill List entry for the paper-cut channel as the FDE to product loop.

The short version

Govindarajan runs the roughly 700-person org behind Agentforce, and the six steps he gave Gupta are: let teams choose their tools, make Slack the operating system, make the agent deterministic where it must be, become eval-first, wire feedback to the roadmap, and roll out one win before going wide. Step five is the one: forward-deployed engineers post field feedback into one Slack channel tagged paper cut or feature request, and PMs match posts to the roadmap and ask whether a customer-specific fix should become a general feature. The same day Salesforce published Slack's numbers: 50% of Slack messages now come from apps and agents, 127 million MCP tool calls a week and doubling each quarter. A channel is an inbox. It has no count, no date, and no decision back, so it cannot produce the number that says whether the loop works. The replacement is the handback packet I wrote down in September: the delta, the eval rows, the reversals, and the count, delivered two weeks in, at go-live, and at day 60, with product owing a written decision within two weeks from a named person plus the eval the general version has to pass. The metric is generalization rate: packets with a decision in two weeks, and three-customer patterns that shipped. Kill the channel as the loop. Keep it as the inbox.

What Govindarajan described

Gupta's piece, recorded live at Dreamforce, opens on the lifecycle. Govindarajan's argument is that plan, build, test, ship, review no longer fits AI features. New models ship every few months, his teams kept reworking agents they had built, often simplifying them because the models could do more, and agents drift: a refund agent grounded in a policy document starts issuing refunds that are too large after the document is rewritten unclearly and the code is unchanged. The ADLC that replaces it is a loop, observe, build, test, evaluate, deploy, and the line that comes out of it is the one I would put on the wall: budget for evals and observability before you budget for the build.

Then six steps. Give teams a choice of tools, because executives should not pick a winner; teams moved from Cursor to Claude Code without a mandate. Make Slack the operating system, with a company bot and Slack Connect for customer feedback. Make the agent deterministic where needed, because pipeline figures cannot differ between agents, with Agent Script specifying which parts. Become eval-first, with domain-specific evals and a grading decision made before the agent is trusted. Wire feedback to the roadmap. Roll out one win, then go wide.

Step five, in Gupta's words: forward-deployed engineers post field feedback to one Slack channel, tagged as paper cut or feature request. PMs match posts to the roadmap and ask whether a customer-specific fix should become a general feature.

The same day, Salesforce's newsroom published Slack by the numbers. 127 million MCP tool calls a week, doubling quarter over quarter. 1.9 million users interacting with third-party agents in Slack weekly. 694,000 active channels inside Salesforce. And the headline: 50% of Slack messages now come from apps and agents.

A channel is an inbox

Put those two pieces side by side. The feedback loop at the largest agent vendor in enterprise software is a Slack channel, and half of what arrives in Slack is now written by something that is not a person. The paper-cut channel will fill from agents as well as from FDEs, and Govindarajan's own proactive agents will be among the posters.

That is fine for an inbox. It is not a loop, and the difference is three things the channel does not carry.

A count. A post about one customer's paper cut does not say how many other customers have it. The Deployment-to-Product Loop: How FDE Work Becomes Roadmap runs on one rule: one is an anecdote, two is a coincidence, three is a pattern. The PM matching posts to the roadmap is doing that count in their head, across a channel, which means it is not being done.

A date. Nothing in a tagged post says when product owes an answer. The FDE who posted it goes back to the customer with "I raised it."

A decision back. Matching a post to the roadmap is not a decision. It is the editor's job done without the editor's artifact. Generalize, keep as configuration, or kill, from a named person, is a decision. A roadmap item somewhere near the post is not.

The packet

Absorb Pain, Excrete Product: The FDE Handback is what I wrote down in September, when Palantir made Fujitsu a Global FDE Partner and the handback stopped being something you could do in a hallway. It has four parts.

The delta. What the customer actually runs, against the shipped product, written in configuration terms. Not "we customized the intake flow." The settings, the prompts, the rules that differ.

The eval rows. The customer's cases that failed on arrival and pass now, as rows the product team can run. This is the part that survives the FDE leaving, and it is the part Govindarajan's eval-first step needs and his channel does not carry.

The reversals. What the customer turned off, overrode, or quietly stopped using, and the FDE's best guess why.

The count. How many other customers have the same problem, as far as the FDE knows. This is the line that makes the three-customer rule runnable.

It is delivered three times, not whenever someone remembers: two weeks in, at go-live, and at day 60. And it comes with an obligation in the other direction. Product owes a written decision within two weeks: generalize, keep as configuration, or kill. From a named person. With the eval the generalized version has to pass.

That last clause is where Govindarajan's best line belongs. Budget for evals before the build means the eval travels with the decision to generalize, not after the feature ships. The packet carries the customer's rows in, and the decision carries the general eval back out.

The number the channel cannot produce

The FDE Scorecard: Count What Stayed, Not Who Was Sent has four numbers for the function, and the one that measures the loop is generalization rate: the share of handback packets that got a written decision in two weeks, and the share of three-customer patterns that shipped. It goes on product's scorecard, not the engineer's.

Try to compute it from the channel. There is no packet to count, no two-week clock to miss, no decision to find. The channel can tell you how many posts carried each tag. It cannot tell you whether the loop closed, and that is the test: if the artifact cannot produce the metric, it is an inbox.

The Kill List entry is the channel as the loop. The inbox stays, in Slack, with its two tags, and the agents can post there too. The loop is the packet, the three dates, and the decision with a name on it.

Under Product Leadership the claim is that leadership work now is deciding which coordination roles stop being necessary and saying so out loud. A PM matching channel posts to a roadmap is a coordination role. A PM writing a decision on a packet with a count on it is the editor, which is the role that stays.

This week, if your FDEs post to a channel: take the last twenty posts and, for each, write down the count of customers with the same problem, the date product owes an answer, and the decision. The blanks are the loop you do not have.

Related answer: Is a Slack feedback channel an FDE to product loop?

Sources: Aakash Gupta with Jayesh Govindarajan, "What an AI-Native Product Team Actually Looks Like at Salesforce," Product Growth, November 3, 2026, article read in full; the 57-minute episode is linked from it and not claimed, and the article discloses that Dreamforce paid the author's travel with no content requirements. Salesforce, "Half of Slack Messages Are No Longer From People. Here's Slack by the Numbers.," Salesforce Newsroom, November 3, 2026, read in full; every Slack figure is as the newsroom reports it. Falk Gottlob, "Absorb Pain, Excrete Product: The FDE Handback" (September 24, 2026), "The FDE Scorecard: Count What Stayed, Not Who Was Sent," and the handbook chapter "The Deployment-to-Product Loop: How FDE Work Becomes Roadmap."