Listen to Your Signals

Rails only work if you are paying attention to where you are on them, and rituals are no different. You can’t run the same program forever, not in the gym, not in product, and 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 is tight, and your CNS just isn’t firing. (CNS is your central nervous system, the part of your body responsible for strength output, coordination, and neural drive. If it is fatigued, you will feel it, even if your muscles are technically rested.) That is not failure, that is information. A smart lifter doesn’t abandon the workout, they adjust. They keep the ritual and shift the intensity, maybe pausing at 70%, maybe pivoting to accessories. Listening like that doesn’t make you weaker, it keeps you in the game longer.

Product teams learn the same lesson, usually the hard way: rituals without awareness become liabilities. You can run all the ceremonies, sprint planning, retros, standups, but if you are ignoring the signals from your team and your users, you are performing process theater. Burnout doesn’t show up in Jira, and disengagement doesn’t flash red on a dashboard. You feel it in the delay before someone unmutes, in the tension after a roadmap shift, and 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, the 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 get treated as signs of commitment when they are actually signals of failure: a failure to listen, to plan, to build sustainable systems, and to treat the team as human beings instead of 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 instead of panic, and protects the team’s ability to think, breathe, and build well, even when the deadline is loud.

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, and to the mission.