Make Feedback a Ritual

Feedback isn’t something you give once a quarter, and it’s not a Slack comment or a surprise at review time. It’s a rhythm, a rep. If cues are the spark, rituals are the circuit that keeps the current flowing. The strongest teams and the strongest lifters don’t just react to feedback when it shows up, they build it in, expect it, practice it, and make it normal.

In lifting, you log your sets and reflect on what moved well, what felt off, and what needs attention tomorrow. Feedback there is a ritual rather than an event, and the same is true of product. If you’re a product manager, I’ll say it as plainly as I can:

If you’re not talking to users, you are failing at your job.

I don’t mean falling behind or missing a step. I mean failing. User feedback isn’t a bonus, it’s the core ritual of the role, and if you’re not making regular space to listen, directly and personally, you’re flying blind. You’re not a scrum master and you’re not a backlog babysitter. You are the voice of the user, and the user, and their mission, is why you have a job.

The research, the roadmaps, the revenue, all of it is an outcome of solving the user’s problem, not the other way around. Too many teams fall into the trap of building for elegance, scale, or conversion, and forget to ask the most important question: Does this move the mission forward? Holding that line is your job as a PM. Metrics can drift and roadmaps can get noisy, but the mission stays clear if you keep listening.

Slack: Feedback as the Product

Slack didn’t start out as a product idea at all. The team at Tiny Speck built it as an internal tool for themselves while working on a multiplayer game called Glitch. The game didn’t succeed, but the internal chat tool did, because the team had built it by listening to their own pain.

They weren’t running customer interviews or user panels. They were simply using the tool every day and treating their own experience as data. The engineers, designers, writers, and founders were all giving and receiving feedback constantly: what was slow, what was confusing, what needed to work better. The users were them, the feedback was constant, and the ritual was built into the way they worked. They didn’t treat those observations as complaints. They treated them as cues, small signals that over time shaped something far more useful than they had originally intended.

So when Glitch shut down, the pivot to Slack wasn’t a Hail Mary so much as a progression, because the team had already spent years listening to what they needed most and building it. Ritualized feedback didn’t just improve the product, it revealed the product they should have been building all along. Slack became Slack not by guessing what users wanted but by listening to internal signals, consistently, honestly, and early.

Elastic: Customer Zero and Design Partner Rituals

We’ve seen the same thing at Elastic. Our internal information security team, “customer zero,” is often the first to use upcoming Elastic Security features. They’re not a test group. They’re real users with real problems, and when something’s unclear, slow, or missing, they tell us, early and often. Because they sit just a few channels away, we can respond quickly and refine before anything reaches broader release.

It’s not just internal, either. Some of our most pivotal feedback comes from design partners, external users who’ve volunteered to be on the front lines with us. They opt into early access knowing the feature might be raw, knowing it might break, because they care about shaping something real, something that works not just in a demo but in a live environment.

These aren’t one-offs or spontaneous bursts of goodwill. They’re planned rituals, structured partnerships built into how we deliver great products, loops that make the product stronger long before it ever reaches general availability. Ritualized feedback has nothing to do with checking a box, it’s how you build alongside the people who share the mission.

Relationship-Level Listening

Collecting feedback is the easy part. Getting someone to tell you what’s on their mind is just the start, what matters is what you do next. Do you listen, or do you nod, say “totally,” and go back to your plan? The question is the same whether you’re running a product team or a training log. You can run all the standups, retros, interviews, and logs you want, but if you’re not listening with intent, you’re just gathering noise, and you’re not growing. Feedback is only useful if it lands, and that means learning how to listen, not just politely but purposefully.