> 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/who-we-build-for.md). # Who we build for Who our users are, how a typical project runs through a manufacturing company, and how customers decide to buy. **Our** [**primary user**](#our-users) **is what we call the** [**power user**](/product/who-we-build-for/the-power-user.md)**.** Usually that is one person between IT and the shop floor who knows how the business works. We give them the tools to build what their plant needs. They are like our [Value Engineers](/culture/working-with-the-rest-of-umh.md#value-engineer). They prefer code and want to get a lot done. A power user can come from IT or from production. So we cannot assume a background in professional software development. With our tools, they build a fully working application in a couple of hours, often with help from LLMs. Without UMH, the company would have expected a project of months or even a couple of years. A plant manager explained to one of our Value Engineers what they wanted and showed them the site. During this shop floor tour, an LLM agent built a full demo on UMH. It had a simulated OPC UA server modelled on the plant's machines, umh-core storing its data in the database, and dashboards for that plant. The applications on top of UMH were what impressed the plant manager. ## Getting to business impact **Business impact makes a customer go for UMH.** Our [mission](/company/why-we-exist.md) is to build experiences that cut manufacturers' time to value. We do that by giving the power user in a customer's company the tools to create the biggest business impact there. As a [Product Engineer](/engineering/product-engineer.md) you decide what to build. So you need to know who you are empowering and how our users reach business impact fastest. We often have to guide them strongly towards it, because they have usually never done it before. We have done it many times. So we give them tips through our Value Engineers and build our products with [opinionated simplicity](/product/product-standards/opinionated-simplicity.md) where we know what scales. ## A typical project **The power user decides to build an alarm because they know that an empty tank stops production.** 1. [IT](/product/who-we-build-for/it-system-administration.md) installs UMH on one of its servers and allows one outgoing connection. Its [security team](/product/who-we-build-for/it-security.md) checks the setup first. 2. The [OT team](/product/who-we-build-for/production-ot-team.md) connects the tank's sensor and says what the signal means. 3. The power user builds the alarm in about 20 minutes. The alarm sends a message to [whoever refills the tank](/product/who-we-build-for/production-the-shop-floor.md). 4. [Production management](/product/who-we-build-for/production-production-management.md) sees fewer stops on the line. 5. The power user's manager [pays for UMH](#our-users). They see fewer production stops in the monthly numbers. ## How a manufacturing company works **A project only works when the two sides of a manufacturing company, IT and production, work together.** On LinkedIn this is usually called IT versus OT. The two sides have different budgets and org structures. Either side can bring UMH in. [How production works](/company/why-we-exist.md#how-production-works) explains the machines and the systems that control them. An outage costs money in IT and in production. In production it can also hurt people. So production puts safety and uptime first. Its control systems run for 10 to 15 years or longer. IT puts data security first and replaces its systems every few years. [NIST SP 800-82](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf) describes these differences in detail. **Production** is led by [production management](/product/who-we-build-for/production-production-management.md). The [operators and shift supervisors](/product/who-we-build-for/production-the-shop-floor.md) run the machines. The [OT team](/product/who-we-build-for/production-ot-team.md) keeps them running. **IT** is often split into [system administration](/product/who-we-build-for/it-system-administration.md) and the [security team](/product/who-we-build-for/it-security.md). Some companies also have [platform and data teams](/product/who-we-build-for/it-platform-and-data-teams.md) that build their own software. ## Our users **Every product is designed for one primary user.** This comes from Alan Cooper's persona method, described in [About Face](https://www.wiley.com/en-us/About+Face%3A+The+Essentials+of+Interaction+Design%2C+4th+Edition-p-9781118766576). A product can have a few secondary users. We meet their needs without making the product worse for the primary user. An app is anything the power user builds on the data UMH collects. It can be a dashboard on a screen next to the line, an alarm that sends a message when a tank runs empty, or a connection that writes the produced quantities into SAP. Most apps are small and solve one problem. Some are larger and control the production process, for example an [MES](/company/why-we-exist.md#how-production-works) (manufacturing execution system). * For the Management Console, UMH's web interface, the primary user is the [power user](/product/who-we-build-for/the-power-user.md). * The [OT team](/product/who-we-build-for/production-ot-team.md) and [IT](/product/who-we-build-for/it-system-administration.md) are the secondary users, unless the power user comes from one of them. Each of them can block a project. For example, system administration can refuse to install UMH because it needs too many resources. * Each app built on UMH has its own primary user. It is almost never the power user. An OEE dashboard is for the [shift supervisor](/product/who-we-build-for/production-the-shop-floor.md). A report on output per line is for [production management](/product/who-we-build-for/production-production-management.md) or the plant manager. A historian helps maintenance, including its PLC programmers. * The person who pays for UMH sits in IT or in production, depending on whose budget the project comes from. Often it is the power user's manager, or the management above them. They rarely use the Management Console or the apps built on UMH. They benefit from the insights and data the apps produce. In our vision, the people who use the apps also log in to UMH and open their apps there. In sales, the champion is the power user, or their manager who pushes UMH inside the company. The economic buyer is the person who pays. Who is the power user, who is the OT team and who is IT differs at every customer. People often hold several of these roles. At a small company, one person can be all three. This makes a product like UMH hard to copy and hard to explain. ## Deciding and buying **A customer decides quickly once they see business impact.** The purchase order comes weeks or months later. This slow buying is normal in the industry, because procurement, legal, security reviews and management boards or committees all take time. Once a customer has committed to UMH, has seen business impact and depends on the apps, they rarely switch vendors or undo the decision. What customers build on UMH can run for as long as their machines. A machine often outlives its control system and runs for 20 to 50 years from purchase until it is phased out. This is one reason companies hesitate to try new things. Whatever they choose stays for a long time and needs their staff to be trained on it. ## Removing friction **Your job is to remove the friction at whichever step your change touches.** At every step from installing UMH to a working app, the better the product, the less our Value Engineers and the power user have to explain and work around. An easy Management Console, a smooth install and quick machine connections get the power user to building apps sooner. The sooner they build apps, the sooner the customer sees business impact. Friction comes as many small problems. Our article calls this [death by a thousand cuts](https://www.umh.app/insight/what-we-do-at-umh). Without UMH, these small problems cost a customer months of integration work. [Why we exist](/company/why-we-exist.md#why-it-takes-months-today) describes them. **UMH itself has friction too.** For example, our UIs still show a lot of code. Most systems the [OT team](/product/who-we-build-for/production-ot-team.md) works with have a UI. They avoid a new tool that looks like code, because it feels like one more thing to learn. The power user still needs the OT team to work in UMH, because the apps depend on what the OT team knows about the machines. That is why our [code and UI](/product/product-standards/code-and-ui.md) standard says that everything in UMH can be configured in YAML or in the UI. [Value Engineers and Account Executives](/culture/working-with-the-rest-of-umh.md) can help you understand the power user, the OT team and IT at a customer. --- # 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/who-we-build-for.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.