Product · 2 min read
Overview
What product means at Flagon: not a department that decides what everyone else builds, but the people who keep us close to users and honest about how we're doing.
Product at Flagon is small, and it's meant to be. We don't have a product organization that sits above engineering handing down roadmaps. We have a handful of people whose job is to keep every team close to the users it serves and honest about how the product is actually performing, so that the right decisions get made by the people doing the work. If you're used to product as a command function, this will feel different. It's supposed to.
The one idea to take away
Product managers here bring clarity and context. They don't own roadmaps or dictate what to build next. Their job is to make sure the team deeply understands its users and its product's performance, so that good decisions happen naturally instead of being ordered from above.
A PM's success isn't measured in features shipped. It's measured in how well the team understands who it's building for and whether what it built worked.
Everything else in this section is a consequence of that idea.
Why it works this way
The alternative, a product manager who decides and an engineer who executes, quietly wastes the best thing about the people we hire. Our engineers can do product themselves: propose what to build, talk to users, own the outcome. If a PM inserts themselves as the person who decides, they become a bottleneck and they turn thinking engineers into ticket-takers. So the PM's role is deliberately not to decide. It's to make sure everyone has what they need to decide well.
This is the same instinct as the rest of the company: small teams, real ownership, as little process as we can get away with.
What's in this section
- What product managers do lays out the role in full: the three things a PM owns, and the things they deliberately don't.
- Product metrics is about always knowing how a product is performing, and what to do when the numbers move.
- Listening to users covers the systems that keep the whole team, not just the PM, in regular contact with the people we build for.
- Deciding what to build is how priorities actually get set, including for products that are already mature.
- Releasing products and features is how something new reaches users without a big-bang launch.
Who this is for
Product managers, obviously. But engineers should read it too, because so much of it is shared work. The discovery calls, the metrics reviews, the calls about what's worth building: those are things a PM makes easy and an engineer stays just as responsible for. Product isn't a wall you throw ideas over. It's a habit the whole team keeps.