The Trust Fall

If you did Chapter 7's exercise, you mapped how a piece of sales feedback becomes a product priority at your company. The map almost always runs through one of four channels, and all four fail.

The first is file-a-Jira. Product installs a form and tells sales to use it. You might as well hang one of those corny complaint-department signs where you take a number, except the number is the pin of a hand grenade. Nobody on the product side reads the queue, everybody on the sales side knows it, and each unread ticket confirms the divide.

The second is the automated collector. Someone I work with was shown, by a friend at another company, their product-feedback pipeline: a shared Slack channel where anyone could tag product, an agent that piped every request into a Google Sheet, hundreds of rows accumulated. Then the friend opened the sheet's view history. No one had ever looked at it. The requests were going into thin air, and the people filing them had figured that out long before product did.

The third is the public request forum, and it is the same failure with the customer watching. A forum where requests sit unanswered for years is a standing proof that you do not listen. You are better off having no channel than a channel that lets people yell into a void.

The fourth is the middle-ground meeting: monthly, two hours, sales presents its top asks to product leadership. It never goes well, because everyone arrives in a defensive posture and because the format asks sales to show up with a document that a product culture will grade. Some sales teams could pass that bar. TurboPuffer's could; a deeply technical product attracts sellers who could show up with everything deduped and metadata attached, in their sleep. At ninety-nine percent of companies the expectation is unfair, and the meeting mostly measures the unfairness.

One more property of all four channels: the feedback doesn't stop when you block it. Lock the engineering floor, route everyone to the form, cancel the meeting, and what you'll hear from sales doesn't go to zero. It reroutes upward, into executive-team politics, where it arrives stripped of detail and attached to a grievance. Keep the guards up long enough and the roadmap conversation stops being about the roadmap at all.

The unfairness was explained to me directly once, and I needed it to be. A senior sales leader had raised the same topic with me several times, and the vibe I gave back in the room was dismissive. When my boss called it out, I defended myself: they hadn't done the math, I'd asked for introductions to five customers and an ROI case, and their thinking had holes in it. My boss said: "That is not their job. That is your job."

Fair. The ROI case, the deduped request list, the revenue metadata, the pattern across accounts: that is product work, and product has the source material to do it. Expecting sales to produce it, then grading what they bring, is outsourcing your own job to the people you're grading.

So the middle ground is not worth pursuing. There is the best possible version of this, and there is nothing, and the options in between are worse than nothing because they generate evidence of not listening.

The good news is that the best possible version stopped being hard. In 2026 you can stand up a company-wide customer memory in minutes: the call recordings, the shared channels, the support tickets, and the issues that never became tickets because they only ever lived in a thread. Then you ask it one question: what could we do to help sales?

The effort involved is saying the question out loud. This is Chapter 1's claim in the flesh, the information half has collapsed in difficulty: a sentence into a microphone now does what used to take a quarter of scraping and a data engineer, and what it produces stays current by itself, which is the property none of the four dead channels ever had.

Then you get ambitious. Set a loop that tracks the biggest issues surfacing on sales calls each month, bucketed the way you think about the product. Have your agent draft a monthly email to sales, CS, and leadership, cross-referenced against your issue tracker: what shipped, what's in flight, what hasn't started. Keep a changelog. And include the warts: what we're behind on, what we should have done before the shiny item above it. Go-to-market has professional-grade instincts for a rosy story; tell one and they will conclude, instantly and durably, that you are full of it. Sunlight is the best disinfectant, and the disinfectant is the point. In this chapter's video, Will builds this loop both ways, once in Day.ai and once free-standing in Claude Code.

The universal objection is political: if we publish the details and the priorities, other departments will use them against us. In my experience this fear loses on both branches. Guard the details and no trust ever develops, so the pressure for commitments only grows. Publish them and almost nothing you feared happens, because the details you're nervous about are invisible to people without your context. They will not nitpick the items you dread; and anyone who knows enough to nitpick them is someone who should have had the data all along, because now they can help you.

Which brings me back to that morning. What I carried into the room was a polished forty-five-minute roadmap deck, glossy and airtight. What sat behind it was a spreadsheet: one hundred and forty-six product priorities, everything we were doing across roughly eight hundred engineers, at the granularity the directors and VPs of product actually worked at, loaded with metadata that felt risky to show outside the group.

I flipped through a few slides and then stopped and said: I can give this presentation, and we can do as much Q&A as you want. Or I can show you the real thing. If you want the real thing, you may want to cancel your meetings after this, just to be clear about what you're getting into.

The founder said, "Let's do the whole thing." In retrospect, of course. Nobody in that seat says no, show us the airbrushed version.

We sat there for four or five hours and went through every single item. I said plainly what I knew and what I didn't. A couple of my team members were in the room, and when we hit a gap, someone Slacked the person who knew and we filled it live. I call that moment the trust fall, and it became the new culture: from then on, the whole real thing was what executive leadership expected to see, and what we expected to show.

The payoff came later, in a real crisis: an outage spanning multiple customers' businesses, with data loss. I sat in a one-on-one with the founder CEO while he weighed, out loud, whether I would remain at the company. Which of those two presentations are you glad you gave?

Covering your ass is risky in product. It is also condescending: it assumes there is a level of detail your audience wouldn't understand or shouldn't care about. How do you know? You're guessing, and the guess conveniently protects you.

What we settled into was progressive disclosure, the same principle you apply in the product itself. A ninety-minute executive pass through the roadmap for the people who need the shape of it. Then a big room: eight hours, the top forty or fifty leaders across the company invited, the door open to anybody. As far down as anyone wants to go, the detail is available. People skip the sections they don't care about, and the people who keep asking questions get the whole answer. It does not backfire the way the fear says it will.

And when the company is small, there is an expert mode that runs the transparency in the other direction. At our size today, I sit with the salespeople and teach them the engineers: who each person is, what they own, what kind of problem lights them up, and what it costs to grab one of them mid-flow about a single deal. You are allowed to talk to them. The stakes are high, so when in doubt, run it by me. Also: I know everything that's happening on your calls, so a lot of the time we will come to you first. I don't know how far past a few dozen people this scales. At seed stage it is a cheat code, and I want to compete against the company that locks the engineering floor instead.

1. Name your glossy deck: the roadmap, status slide, or update you keep presentable. Everyone owns at least one.
2. From memory, list what you're behind on and anything you should have done before the item above it. These are the rows the deck leaves out.
3. Name the person most able to push you off the cliff, and the rows they would push on. Run the prompt with all three pasted in.
4. Pick a date, send the night-before text, and publish the real version inside the company. If you don't present roadmaps yet, do it for one team meeting: the real list in place of the status slide.

Paste this into whatever AI you work in, ideally one connected to your company's material: Claude Code in a company-brain folder, Cowork, Codex, or similar. Write your behind-on list first; the AI checks it.

Directors, VPs, and CPOs: anyone who owns a roadmap presentation. If you're earlier in the career, the trust fall scales down to a single team meeting, and the habit costs far less to build now than it will when the room is founders and CFOs.