If you have been around tech long enough, you have heard the jokes. Product managers sit around writing Jira tickets, micromanaging developers, and slowing everyone down. I have laughed at those memes too. Sometimes it really does feel like that. The truth is the job is not one size. Not every product person works the same way, and not every product person wants to.
For me it has never been about policing tasks or keeping a stopwatch on the team. I am not a fan of micromanagement. I do not breathe down engineers' necks or ping designers every half hour about the progress bar. I look at it differently. The job, at least in my book, is leading by involvement.
Involvement does not mean pretending to be a designer or shipping production code myself. It means stepping into the shoes of the people I work with often enough to see the friction, and to know which decisions make their work easier or harder. Sometimes that is tweaking a layout to show an idea. Sometimes it is poking at the code so I understand what engineering is dealing with. Other days it is helping shape a campaign or writing copy that ties the product to the larger story.
Then there are stakeholders. A big part of the job is translating. Executives talk roadmaps, revenue, market share. Users talk pain, friction, small wishes. Engineers and designers talk feasibility and scale. Someone has to swallow all of that and turn it into something coherent. That someone is usually the product person.
The misunderstood role
From the outside it can look like we just talk all day. Sometimes we do. Those conversations are what keep a project from splitting into three products. Designers build one thing, engineers build another, marketing sells a third, and leadership wonders why none of it fits. Filling those gaps is the unglamorous part. It is also the job.
Tools still matter. Jira, Trello, Monday, Notion, even a spreadsheet. I have used giant corporate setups and sticky notes on a wall. The tool is not what makes or breaks the role. It is whether you remember the tool is supposed to support people, not the other way around.
How I actually work
I keep it light. Short check-ins over long meetings. A sync in the morning, maybe another at the end of the day if a deadline is tight. Enough that everyone is in the loop. Not so much that we waste half the day talking. If the team knows what to do, they do not need me calling every two hours. They need to know I am there if they hit a wall.
And yes, I jump in. If I am with designers I open the Figma file and play with components. Not to redo the whole thing, just to understand it. With engineering I read the code, ask questions, sometimes make a small tweak. With marketing I join the brainstorm and keep the message honest about what we are actually building. Credibility comes from getting your hands dirty. It is not just words.
Staying centered
The role will burn you out if you let every fire drill eat you. I try to stay centered. Take the noise, sort it, hand it back in a way the team can actually move on. That is what keeps momentum alive.
The bridge
When people ask what a product manager does, this is my answer. We are the bridge. Between executives and engineers. Between designers and marketers. Between the vision and what a person actually feels using the thing. You do not need to control every move. You need to make sure no one is walking their part of the bridge alone.
Not as meme-worthy as "writes Jira tickets all day." In today's market, it is what keeps products alive. The role is not managing people. It is managing momentum. Set the pace, keep the flow, fill the gaps. If you do it right, the team does not just follow instructions. They own the project with you.