> 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/development-process/how-to-decide-what-to-build.md). # 1. How to decide what to build ## Where we are headed **We balance a few strategic projects with improving the product for how customers actually use it.** A light roadmap holds the strategic projects. They come from decisions in the Management Team (Alex as CEO, Niklas as CCO and Jeremy as CTO), based on [why we exist](/company/why-we-exist.md). Because we communicate them to our investors, they are binding. Customer feedback shows how customers actually use the product. Because that often differs from how they planned to use it, a lot of our time goes into improving the product for how they really use it. **Not everything in our backlog is work.** Most of it is a [signal](/engineering/development-process/how-to-decide-what-to-build/signals.md): evidence that something is worth knowing, which becomes work when someone accepts it. Work comes in three sizes. 1. **The roadmap**, with a few large directions, for example shipping a UMH CLI in Q4. One roadmap item can consist of several rollout tickets. 2. **Rollout tickets**, for larger features and bug fixes that span multiple days. 3. **Smaller work** without a big change in behaviour, such as most bug fixes. It usually takes minutes or hours, review included. It needs no rollout ticket. If you are unsure whether a change is small, agree with the Code Owner. Besides these three, [visions](#visions) say how a part of UMH should work in the future. They keep our work going in the same direction. ## The quarterly roadmap **About 20% of our work goes into roadmap items and the rest into normal rollout tickets.** This split gives us a strategic direction and still leaves Product Engineers room to fix what the business needs right now. The [Product Manager](/product/product-manager.md) keeps the roadmap current and published. Roadmap items are pitched as rollout tickets like any other. For a roadmap item, the product meeting decides only how much time it gets. Whether we build it is already decided. The roadmap is binding. ## Visions **A vision says how a part of UMH should work in the future, and which rules it always follows.** Then two features built independently do not make different assumptions about how things will work later. Visions about the code are subpages of [Coding standards](/engineering/development-process/how-to-build/coding-standards.md), for example [FSMv2 workers](/engineering/development-process/how-to-build/coding-standards/architecture/fsmv2-workers.md). Visions about the product are subpages of [Product standards](/product/product-standards.md). A vision does not repeat how the product works today. The [documentation](https://docs.umh.app) already describes that. **Each vision page has two sentences on where that part is going, then its rules.** Each rule is something that always holds and that a test or a dashboard can check. The page starts with its owner and the Linear project where the discussion and the work happen. Both parent pages have a template for adding one. A vision is never finished. An epic, in contrast, closes when its child tickets close. If something has phases or can be finished, it is a rollout ticket. A vision is more like a written principle that we check work against. The [Product Owner](/engineering/product-engineer/product-owner.md) of that user journey writes the vision. Every rollout ticket needs the Product Owner's sign-off. Before giving it, they check the ticket against the vision. If you work out while building how something should work in the future, tell the Product Owner. ## Rollout tickets **A** [**rollout ticket**](/engineering/development-process/how-to-build/tickets/rollout.md) **is one piece of work with one owner.** You [pitch](/engineering/development-process/how-to-build/tickets/rollout.md#the-pitch) it, and the product meeting bets on it. ### The bet **We bet on the pitches with the highest impact for the effort.** In the [product meeting](/culture/our-week.md#product-meeting) on Wednesday, we decide how much time the work is worth. That amount of time is its [appetite](https://basecamp.com/shapeup/1.2-chapter-03). We bet once every part of the [rollout ticket](/engineering/development-process/how-to-build/tickets/rollout.md#template) fits the appetite. You can ask for an appetite before you write the spec, and come back with the spec to check that it still fits. Betting means we commit to building it. If the appetite does not cover it, the pitch goes back to Ideas. Then either its owner reshapes it into something that fits, often a smaller first step, or we work on items with higher impact first. **Before the meeting, align the pitch with the Code Owners, the Product Owners, the Value Engineers and anyone else it affects.** If everyone already agrees, the meeting is mostly a formality. Prepare well anyway. Questions in the meeting can still send the pitch back for another week. Tell the Product Manager about the pitch by Monday. In the Monday check-in we go through the pitches for Wednesday. Announce the pitch in #dev-2-product to get early feedback. When you take it to the product meeting, bring the [breadboard](/engineering/development-process/how-to-build/tickets/rollout.md#the-breadboard). [How to build](/engineering/development-process/how-to-build.md) and [How to ship](/engineering/development-process/how-to-ship.md) cover the rest, from the spec to closing the ticket. --- # 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/development-process/how-to-decide-what-to-build.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.