> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/product/product-manager.md). # Product Manager A different job from Product Engineer, in the same department. > At PostHog, product managers (PMs) exist to bring clarity and context to their teams. They do not own roadmaps or dictate what to build next. Instead, they ensure the team deeply understands its users and its product's performance, so that the right decisions happen naturally. > > — PostHog handbook, [Product Manager](https://posthog.com/handbook/product/product-manager-role) **You are the team's compass, not its captain.** The [Product Engineers](/engineering/product-engineer.md) decide what to build. You give them and others in the company all the context they need to make good decisions. You do that for example in the [product meeting](/culture/our-week.md#product-meeting) and on the roadmap. You support Product Engineers with data and feedback loops. The goal is that features get built right and get used. In practice, you communicate a lot with people inside product and engineering, with other [UMH teams](/culture/working-with-the-rest-of-umh.md), with community members on Discord and with customers. You take over some of the more complex communication tasks. For example, you make sure each Value Engineer tells their customers that they can try out a new feature if they want. That often means coordinating which customers are relevant, which are more open to trying it early, and which care most about the issue. You also decide whether something is best said to everyone at once or tailored to the one customer it concerns. You run the [customer validation tickets](/engineering/development-process/how-to-build.md#the-rollout-plan) for this and own the adoption data on shipped features. Whether you do the job well depends on whether the engineers find you helpful. ## What does that look like day to day? * You coordinate the product meeting and the [daily check-in](/culture/our-week.md#daily-check-in). You decide which customer requests are [blocking](/product/product-manager/blocking.md), prepare that list, and nudge everyone to keep it and their rollout tickets up to date. A typical nudge reads *"Friendly reminder: If a pitch is planned for Wednesday's Product Weekly: please prepare/announce it 2 days in advance."* * A [customer validation ticket](/engineering/development-process/how-to-build.md#the-rollout-plan) is assigned to you automatically when a Product Engineer opens one to get customers to try a feature. You pass it to the Value Engineers and Account Executives. Each update you send about it tells the customer what changed for them. The same update tells the Value Engineers and Account Executives what to expect and how to talk about it. * A customer request needs everything listed under [Customer requests](/engineering/development-process/how-to-decide-what-to-build/signals/customer-requests.md) before it moves forward. When something is missing, you are usually the one who nudges. * You make sure a shipped change reaches the Value Engineers and their customers as something they can use. When the engineer who built it is away, you present it at the [all hands](/culture/our-week.md#all-hands). * The Management Team decides the direction of the roadmap. You keep the roadmap current and published. * You prepare customer workshops with the Product Engineers. Each workshop gets a parent ticket with one sub-ticket per topic: the problem, what we ship, what we leave out, the demo and the feedback questions. You do a dry run together beforehand. The engineers present and ask for feedback themselves. You make sure their questions need more than a yes or no, and that feedback the customer gave before the workshop reaches the engineers while they prepare. * You join the weekly meetings we hold with some customers. Before each one, you send the engineers who attend any feedback the customer sent ahead of the meeting. In the meeting, you bring a concrete plan and show what happened to earlier feedback. * Every week you have a ten-minute check-in with each Product Engineer and each Value Engineer. You ask what they need and pass on what you heard elsewhere, for example in customer meetings. * You check how we present features in webinars, so customers understand what they get from them. When you demo, say what a step gives the viewer before you show it, and explain each product term the first time you use it, as [Readability](/engineering/development-process/how-to-build/coding-standards/code-quality/readability.md) asks for text. Keep the setup part short. Do a dry run, check production an hour before, and keep staging ready as a fallback. * You can send a customer a short update that links each of their requests to the feature that shipped for it, or to its roadmap item. It works best at a fixed time, for example once a month. ## What is it not? * You are not a traditional PM who owns the roadmap and tells engineers what to build. * You are not a project manager who runs sprints and grooms backlogs. The Product Engineer writes the [pitch](/engineering/development-process/how-to-decide-what-to-build.md#rollout-tickets). Engineers go to the raw business context themselves, such as PostHog, Sentry, customer calls and transcripts. An engineer who stops looking because you will cover it loses the ability to make good product decisions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://engineering.umh.app/product/product-manager.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.