What product managers do

This page explains what product managers actually do here: how the role works, what a PM is responsible for, and how they work with their team. If you want the philosophy behind it first, start with the overview.

The role at a glance

At Flagon, product managers exist to bring clarity and context to their teams. They do not own roadmaps or dictate what to build next. Instead they make sure the team deeply understands its users and its product's performance, so that the right decisions happen naturally, made by the people doing the work.

A PM owns three things for their product and team.

1. Systems for staying close to users

The PM makes sure the team is never guessing about the people it builds for.

• Keep a system running where the PM and the engineers hold discovery calls with users regularly. Not a one-off research project: an ongoing habit.
• Have somewhere feedback is stored so it's retrievable when a decision needs it, without dumping every comment straight into the backlog as if it were a committed task.
• Organize the interviews, lead the metrics reviews, set up the sessions where the team watches real people use the product.

The test of this system is simple: on any given week, can an engineer on the team easily talk to a user? If not, the PM's most important job is to fix that. There's more on the mechanics in listening to users.

2. Knowing how the product is performing

The PM always knows how their product is doing, in both usage and revenue, and makes sure the team does too.

• Always know how the product is performing, on the metrics that matter.
• Stay aware of the trends, the areas of concern, and the openings worth chasing.
• When a metric moves the wrong way, don't just report it: form a hypothesis for where to dig next.

The detail on which metrics, and how we review them consistently across products, is in product metrics.

3. Pricing that matches the value

The PM keeps an eye on whether what we charge still matches what users get.

• Regularly check that pricing lines up with the value people actually get from the product.
• Notice when pricing or packaging is creating friction for adoption, retention, or expansion.
• When a change is warranted, work it through with the people it touches rather than in isolation, in line with how we think about making money.

What a PM deliberately does not do

Just as important as the list above is what's not on it.

A PM who becomes the decider turns a team of thinking engineers into a delivery function, which throws away the autonomy that makes this a good place to build. The job is to raise the whole team's understanding, not to concentrate the decisions.

When to add a PM to a team

Not every team has one, and that's fine. A team of strong product engineers already does a lot of what a PM does. You add a PM when the work of staying close to users and on top of the metrics grows past what the team can carry alongside building, and the team would genuinely move faster with someone holding that context full-time. You don't add one because a team reached a certain size, or because it's what other companies do.

Working with the team

Because the PM doesn't hold authority over what gets built, the relationship with engineers is collaboration, not handoff. The PM surfaces what users need and how the product is doing; the engineers, who own their features end to end, decide with that context how best to respond. Disagreements get argued in the open, on the merits, the same way decisions get made everywhere else here. The PM's influence comes from being the person with the clearest picture of the user and the numbers, not from a title.