Takorin~6 min read
What if a factory tool told you what to do next?
Three plant directors told me they did not open the dashboard they already owned. That killed the product I had planned to build.
- Role: Product strategy and design
- Timeline: Side project
- Team: Solo
- Impact: Not piloted yet
- Platform: Web
The short version
Most factory software is good at telling you what already happened and poor at telling you what to do next. Takorin was my attempt to make that next move clear.
Research killed the obvious version before I built it. I interviewed three plant directors at top-four global food manufacturers expecting a feature wishlist. None of them opened the dashboard they already owned.
What replaced it was one ranked queue, with an owner and deadline on every item, plus a readiness score that says how much of its own ranking to trust.
What I owned
I owned
- Primary research with three plant directors at top-four global food manufacturers
- The product thesis, and throwing out the dashboard version after those interviews
- The scoring model that ranks findings: including getting the ranking wrong first
- Data-readiness tiers, so the product degrades on a thinly instrumented plant rather than failing
- The entire interface, 22 screens
Problem
Why build another dashboard nobody will open?
One director said it plainly: it tells me what happened, not what to do about it. These are people running plants with thousands of staff on thin margins, and the most expensive system on their desk was the one they trusted least.
The cost is real. Food manufacturing runs on overall equipment effectiveness (the share of scheduled production time that is actually productive), and a single point of it is often worth six figures a year on one line. A bad shift is a financial event, not a reporting one.
And bad shifts rarely come from one obvious failure. They compound: a checklist completed late, a sensor drifting warm, a qualification gap, a supplier document nobody updated. Most plants already have the data to catch it earlier, and it sits in separate systems, so somebody has to connect the dots by hand. By the time the pattern is visible the moment to prevent it has passed.
What the directors said
They already own the system
Every director had a manufacturing execution system (the software that runs the plant floor), and none of them described it as the thing they open first.
The fear is confident wrongness
“What if it’s confidently wrong, I act on it, and the shift fails anyway.” Every one of them had been burned before.
The decision moment is already gone
A supervisor walks into a shift, and by the time they have the full picture, the window to act has closed.
Give the queue the whole screen
What if the queue got the whole screen?
We made a standalone ranked queue the default landing view instead of a delay-tracking dashboard or a ranked panel on the existing home screen. Three directors said they did not open the dashboard they already had, so improving it would repeat a failure. A ranked queue can send a director to the second-most urgent issue while the first compounds, making a bad ranking worse than an unranked list that admits it does not know. The readiness score states how much of its ordering to believe. One ranked entry point replaced five unranked alert sources, with ownership and deadlines attached by construction rather than convention.
A panel would have competed with everything around it. A screen with nothing else on it makes the ranked list the only thing in the room.
Every finding carries three things: a precedent from the plant’s own past, because a director trusts a recommendation grounded in their own history; a countdown to the moment the window closes, because a finding without a deadline is trivia; and an owner, so a ranked signal cannot sit unclaimed.
Show what the ranking does not know
What if the product showed its uncertainty?
We exposed a readiness score with named gaps instead of hiding low-confidence findings or showing everything at equal weight. Directors feared confident wrongness, and hiding uncertainty is how trust fails with this audience. Opening with 64% reliability is hard to sell and gives competitors a number to quote, so every gap includes an honest effort estimate and what fixing it is worth; the score becomes a work queue rather than an apology. It lets the product degrade rather than fail on a thinly instrumented plant, which is most plants.
Score risk before it reaches the dock
What about the risk arriving at the loading dock?
We added a supplier module with a scorecard visible to suppliers instead of limiting risk to in-plant signals or using an unscored supplier feed. Incoming material is the risk category a plant cannot instrument itself, unlike the data read by other modules, and US traceability rules under FSMA 204 take effect in 2028. The module tracks certificate status against the schedule, delivery, and shelf life before the run needing a lot. A supplier-visible score enters a commercial relationship and a wrong score can damage it, so scores use certificate dates and delivery records rather than judgment and are contestable against documents. Whether a visible score changes supplier behavior still needs testing.
What shipped
We shipped twenty-two screens: the ranked queue as the landing view, the readiness score, the supplier module, and a Knowledge tab that captures the tacit expertise of operators approaching retirement and rates the risk of losing it.
A plant can lose the person who knows why the oven runs warm on the gluten-free line. Before this, there was nowhere to put that knowledge before it walked out the door.
What exists so far
There are no results yet, and I will not imply otherwise.
There is a design that survived review: two independent passes found four critical and four major issues, and every critical issue was fixed before sign-off. One ranked entry point replaced five unranked alert sources.
The product is intended to move overall equipment effectiveness: a 5-15% gain on pilot lines, and less time between a risk appearing and a response. Those are hypotheses for a pilot, not results.
The missing argument may be the important one
The uncomfortable truth is that one of the four major review issues shipped unfixed. An operator workflow takes three taps against a two-tap spec because the real fix needs a different input method than the screen supports, so I logged it as design debt rather than letting it disappear.
The larger gap is that this was solo work. Three interviews and a design review pressure-tested the decisions, but no stakeholder had to lose an argument, especially over whether a plant director will trust a machine-ordered queue regardless of its readiness score. The pilot has not happened, so the proposed 5-15% overall equipment effectiveness gain remains a hypothesis, not a result. The useful judgment is to treat a clean solo rationale as incomplete when the adoption risk needs a real operational counterargument.
