> 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/engineering/product-engineer/product-owner.md).

# Product Owner

Who signs off changes to a user journey, keeps track of its reports and writes its visions.

**A Product Owner owns a** [**user journey**](/engineering/product-engineer.md) **and signs off every** [**rollout ticket**](/engineering/development-process/how-to-build/tickets/rollout.md) **that touches it.** The Product Owner writes the [visions](/engineering/development-process/how-to-decide-what-to-build.md#visions). Before any code is written, they check each ticket against them. They make sure that changes fit the overall direction and the planned user journey and that features still belong together.

**There is exactly one way to do each task.** Because of [opinionated simplicity](/product/product-standards/opinionated-simplicity.md), the Product Owner makes sure there is no second workflow for the same task. Offering only one way standardizes how factories use UMH, reduces support needs and lowers the mental load for users.

**Reports about a user journey go to its Product Owner after** [**triage**](/engineering/development-process/how-to-decide-what-to-build/signals/triage.md)**.** That covers PostHog reports, Slack threads and customer remarks. The Product Owner keeps track of them and hands you the relevant part when you want to work on the journey.

**When a Product Owner refuses to sign off, that rarely stops the feature.** Usually another way to build it fits the user journey. You work it out together with the Product Owner. If you cannot agree, bring it to the CTO, the [engineering weekly](/culture/our-week.md#engineering-weekly) or the [product meeting](/culture/our-week.md#product-meeting).


---

# 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/engineering/product-engineer/product-owner.md?ask=<question>&goal=<user_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.