> 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.md). # Product Engineer **Every engineer at UMH is always a Product Engineer.** Some Product Engineers are also the [Code Owner](/engineering/product-engineer/code-owner.md) of a part of the codebase. Some are the [Product Owner](/engineering/product-engineer/product-owner.md) of a user journey. A user journey is one task a user does from start to finish, for example connecting a machine and seeing its data in the Management Console. Over time, every Product Engineer should become a Code Owner, a Product Owner, or both. Your level depends on these roles, as described in [Levels](/career/levels.md). ## 1. No product management by default **Engineers decide what to build, based on business impact.** > Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. > > — Gergely Orosz, [The Product-Minded Engineer](https://blog.pragmaticengineer.com/the-product-minded-engineer/) At UMH, this quote describes the job of every engineer. It only works if you [understand the business](/product/who-we-build-for.md). In other companies, product management does the customer meetings and aligns with all the stakeholders. Then it comes to you with a ticket list. That is a manager "protecting" you from business context. We don't do that because it creates unnecessary friction and limits smart people like you. Our product management supports you with coordination and communication when the work is complex, for example a bug involving several physical locations, or a migration with specific customer concerns. Your job is to turn [customer requests](/engineering/development-process/how-to-decide-what-to-build/signals/customer-requests.md) into actionable work. You look for patterns across the requests because one feature or bug fix sometimes solves tens of them at once. Then you propose that single feature or bug fix. At UMH, you work with high autonomy. You hear directly from customers, sales and business people. You can join any meeting you want and set up calls. A call with a customer goes through that customer's Value Engineer and Account Executive. They own the relationship with that customer and know what is going on there. People's reactions tell you that something matters. They get excited when they see how a bug fix or a feature solves a problem they have. A Value Engineer gets excited when the work solves a problem their customer has. You then pitch the work as a [rollout ticket](/engineering/development-process/how-to-decide-what-to-build.md#rollout-tickets). ## 2. Own features end-to-end **You own a feature from requirements to business impact.** That covers gathering requirements, getting everyone to agree on them, coding, merging, releasing to production and communication. You also collect the user feedback yourself. The goal is a business impact at one of our customers, ideally several. Because we care only about the business impact, each of these steps is mandatory. Communication is part of the job because a customer can only use a feature they know about. Our product management can support you with it. You work on every layer, from the database to the UI. The role has no specialization and no handovers for frontend or backend work. What matters in the end is that the feature gets [shipped](#id-4.-definition-of-shipped). You decide how your feature gets built, tested, designed, released and explained. Others support and coach you while you do it. A feature is not switched on by default until the [Product Owner](/engineering/product-engineer/product-owner.md) has signed it off. The Product Owner checks that the change fits the planned user journey. **Even when you work in a team, each rollout ticket has exactly one owner with the full responsibility.** When several people decide on the same work, one of them may make a decision that someone else later has to clean up. You are responsible for every requirement on your ticket, even one that someone senior added. If you disagree with one, write down the argument and discuss it with the people it affects. ## 3. Deliver business impact **Your role is to deliver business impact.** Merging pull requests alone does not count. Neither does vibe coding, meaning code an LLM wrote that you or the rest of the team don't understand, or a heavy refactor for its own sake. Business impact means you regularly fix bugs, add features or do refactors that are released to production, used, and make a difference for a customer. What you work on is your decision, as described in [No product management by default](#id-1.-no-product-management-by-default). See also [How to ship](/engineering/development-process/how-to-ship.md). The work can be a multi-month project, a small careful change, or a docs change that guides users to the right feature. Often a small careful change has as much business impact as a multi-month project. Your code needs to matter to someone, such as a customer, an Account Executive or another developer. If you can't name who benefits from what you shipped, you haven't finished the job yet. **Because business impact is hard to measure directly, you judge it by two signals.** Before you build, the [appetite](/engineering/development-process/how-to-decide-what-to-build.md#rollout-tickets) a [product meeting](/culture/our-week.md#product-meeting) gives your rollout ticket is a strong indication the work will matter. After you release, people using the feature is a strong indication that it did. Neither signal is proof. Sometimes everyone in the company was excited about a feature and it did not help. It is still your responsibility, even though it is not your fault. To learn from it, check whether a smaller change still gets the business impact you wanted. Sometimes the better answer is to stop the project instead of shipping a feature with unclear business impact. In the end you can go to a supermarket, take a product from one of our customers, and say to your friends: "Because of what I did last week, these people can now measure how much energy it takes to produce exactly this product." ## 4. Definition of "shipped" **A feature is shipped when the target audience is actively using it.** A team that wants to use it, will use it someday, or has only seen it released does not count. ## 5. Who it is and isn't for **Before you join, we check that you work like a Product Engineer.** We look for someone who has built something from their own idea, shipped it, and knows what happened next. Did users like it? Did it work? What would they change? The application asks you to write about something you built that nobody assigned to you. This probably isn't for you if you prefer well-defined tickets, structured processes, clear requirements, or a role where someone tells you what to build next. It is fine to prefer a more structured environment, as many good developers do. --- # 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.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.