Make Feedback a Ritual

Feedback isn’t something you give once a quarter. 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. They keep the current flowing. The strongest teams and the strongest lifters don’t just react to feedback when it shows up. They build it in. They expect it. They practice it. They normalize it.

In lifting, you log your sets. You reflect on what moved well, what felt off, what needs attention tomorrow. Feedback isn’t an event. It’s a ritual. Same goes for product.

And if you’re a product manager, here’s the simple truth:

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

Not falling behind. Not missing a step. Failing.

User feedback isn’t a bonus. It’s the core ritual of the role. If you’re not making regular space to listen — directly, personally — you’re flying blind.

You’re not a scrum master. You’re not a backlog babysitter. You are the voice of the user.

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?

That’s your job as a PM: to hold that line. Metrics can drift, 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. It started as an internal tool. The team at Tiny Speck built it 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. It was a progression. 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 didn’t become Slack by guessing what users wanted. It became Slack 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. When something’s unclear, slow, or missing, they tell us, early and often. And 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. They’re not spontaneous bursts of goodwill. They’re planned rituals — structured partnerships built into how we deliver great products. Embedded loops that make the product stronger long before it ever reaches general availability.

Ritualized feedback isn’t about checking a box. It’s about building 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?

It’s the same in product. And in training.

You can run all the standups, retros, interviews, and training logs you want. But if you’re not listening with intent, you’re just gathering noise. You’re not growing.

Feedback is only useful if it lands.

And that means learning how to listen — not just politely, but purposefully.