Listen to Your Signals

Rails only work if you’re paying attention to where you are on them. Rituals are no different.

You can’t run the same program forever. Not in the gym. Not in product. Not in life. Progress demands feedback. And feedback starts with listening.

Lifters learn this early. You might show up ready to deadlift heavy, but your grip feels off, your back’s tight, your CNS just isn’t firing. (CNS, Central Nervous System, the part of your body responsible for strength output, coordination, and neural drive. If it’s fatigued, you’ll feel it, even if your muscles are technically rested.)

That’s not failure. That’s information. A smart lifter doesn’t abandon the workout. They adjust. They keep the ritual, shift the intensity. Maybe you pause at 70%, maybe you pivot to accessories. Listening doesn’t make you weaker. It keeps you in the game longer.

In product teams, the same truth holds: rituals without awareness become liabilities.

You can run the ceremonies — sprint planning, retros, standups — but if you’re ignoring signals from your team or your users, you’re performing process theater. Burnout doesn’t show up in Jira. Disengagement doesn’t flash red in a dashboard. You feel it in the delay before someone unmutes. In the tension after a roadmap shift. In the quiet attrition of both teammates and customers.

Nowhere is this more visible than in the game industry’s long-standing reliance on crunch time. Late-stage death marches, where teams work 60, 70, 80-hour weeks to hit a ship date. Executives cite passion. Teams call it what it is: avoidable. The rituals of “just one more sprint,” of all-hands war rooms, of praise for pulling all-nighters — they’re treated as signs of commitment, when they’re actually signals of failure.

Failure to listen. To plan. To build sustainable systems. Failure to treat the team as human, not just headcount.

This is where product management has a second, often overlooked role.

Yes, product is the voice of the user inside the development team. But product is also the shield of the team against the wrong voices from above. A good PM doesn’t just absorb pressure from the top and pass it down. A good PM pushes back. Uses data to say no to date-driven development. Advocates for pacing, not panic. Protects the team’s ability to think, breathe, and build well, even when the deadline is loud.

Because our goal isn’t to meet an investor’s timeline or an executive’s forecast. It’s to build the best product to solve our user’s mission.

And the only way to do that — sustainably, meaningfully, and well — is to listen.

To your body. To your team. To your users. To the mission.