Journey-Based Product Teams: Why Org Charts Fail Customers
Why Your Product Organization Should Mirror the Customer's Journey, Not Your Org Chart
A coil left the rolling mill last month with every certificate in order. Grade correct, gauge within tolerance, surface finish signed off by quality. MES had logged a clean pass. ERP confirmed the sales order was billed on time. Every functional dashboard was green.
The customer still called to complain. The coil arrived nine days late, and nobody inside the plant could fully explain why. The order desk owned order entry. Production planning owned the schedule. The mill owned the rolling. Logistics owned the truck. Everyone had done their job, and the nine days belonged to no one.
I've sat through many such review meetings to know this isn't a rare story. It's closer to the default state of most integrated steel plants, and most manufacturing IT organizations generally, they just don't say it out loud in the review meeting.
The Silo We Built With Good Intentions
Functional organization made sense when we first built these systems. Level 2 automation needed control engineers. MES needed people fluent in tag mapping and interlocks. ERP needed finance and supply chain configuration expertise. Grouping people by system type was the fastest way to build deep expertise, and for a long time it genuinely worked.
The problem is that a customer's order doesn't travel through one system. It moves through all of them in sequence, and the handoffs are exactly where things quietly fall apart. A rescheduling decision the APS team makes for perfectly good local reasons can break a delivery promise logistics already made. A master data fix in ERP can desynchronize a genealogy record in MES three weeks downstream, and by the time anyone notices, the root cause is buried under two sprint cycles and a team boundary nobody wants to cross.
There's a line from the Gita that gets quoted often, usually stripped of its context: कर्मण्येवाधिकारस्ते मा फलेषु कदाचन, roughly, your right is to your duty alone, never to its fruits. Functional teams have taken this almost literally, in the worst possible way. Each team focuses hard on its own karma, its own scope, and nobody carries the phala, the outcome the customer actually experiences. That's not really what the verse meant. It was about freeing people from anxiety over results so they could act with full attention, not about outcomes stopping to matter.
What a Journey Actually Looks Like on the Shop Floor
A journey isn't a project milestone, and it isn't a system module either. It's the lived sequence a customer or employee goes through, start to finish.
A handful of these carry almost all the business value in an integrated steel plant:
- Order-to-delivery. From the moment a customer places an order to the moment they receive conforming material, invoiced correctly, on the date they were promised.
- Heat-to-certificate. From liquid steel to a shippable coil with a genealogy record and a quality certificate a customer can trust without calling to double check.
- Fault-to-uptime. From an operator flagging an anomaly to the asset running again, with the root cause actually captured, not just the symptom cleared.
- Hire-to-productive. From a new employee's first day to the point they're independently competent on the floor. Most plants track this one only informally, if at all.
None of these live inside one system. They cut across MES, ERP, APS, quality labs, and maintenance, departments that in most plants have never once shared a KPI. Organize teams strictly around MES, ERP, and APS as separate technology towers, and you optimize every piece while leaving the seams unowned. And the seams are exactly where the customer lives.
From Technology Deliverables to Business Outcomes
Ask a typical MES team what they shipped this quarter and you'll hear about interlocks configured, tags mapped, a module deployed. Ask what actually changed for the customer or the plant, and the answer gets vaguer fast, because that was never their scorecard to begin with.
A journey-owning team carries a different one entirely. For order-to-delivery: on-time-in-full percentage, order lead time, rework rate. For heat-to-certificate: first-pass yield, certificate turnaround, customer quality complaints per thousand tons. For fault-to-uptime: mean time to recovery, and how often the same fault comes back. These are outcomes, not deliverable counts, and they change the tone of every steering committee review. You can't hide behind "the release went out on schedule" when the metric that actually matters is still sitting in red.
This is uncomfortable, and it should be. A shipped release is easy to defend, you either hit the date or you didn't. An outcome is harder to own because it depends on things outside any one function's direct control. Which is precisely why the team needs the authority to work across those boundaries, rather than escalate every time it hits one.
Anatomy of a Journey-Owning Team
A team built to own order-to-delivery can't just be five MES developers with a new Jira board. It needs enough range to act on the whole journey without waiting for four other teams to find room on their roadmap.
What tends to work: a product owner accountable for the outcome metric, not for a technology roadmap, answering to the business rather than to a system owner. Process and domain people from the functions the journey actually touches, embedded rather than consulted once a sprint. Someone who owns data and integration end to end, because most of the breakage happens exactly at the handoffs between systems. A frontline voice, an operator or dispatcher who lives the journey daily and notices what no dashboard will show. And enough decision authority to change a workflow, not just a screen, when the real fix sits in a process rather than in code.
This ends up smaller than most plants expect, six to nine people usually, but it carries authority that used to be split across three or four separate reporting lines. That's the part organizations resist. It means someone in production planning now answers, partly, to a product owner who doesn't sit in their function at all. Which is exactly where governance has to change too, not just the team chart.
What Changes in Governance
A steering committee built around functional status reports genuinely doesn't know what to do with a journey-owning team. The old rhythm asks, is MES on track, is ERP on track. The new one has to ask, is order-to-delivery actually getting better, is heat-to-certificate faster and more reliable than last quarter.
That question is harder to dodge, and it changes what a programme review looks like. Instead of five function heads presenting five green statuses, one journey owner presents one outcome trend, and has the standing to say which upstream function is the current bottleneck. This isn't a minor governance tweak. It shifts accountability from status reporting to outcome ownership, and frankly, most PMO structures built for finite projects were never designed to handle it.
This is the same shift I keep circling back to in this series, IT programmes moving from finite projects toward continuous product journeys. Journey-based teams are simply the organizational shape that continuous ownership requires. You can't have one without the other.
A Practical Path to Get There
Nobody restructures an entire plant IT organization in one move, and trying to is usually how these efforts die. A more realistic sequence looks something like this.
Start by mapping two or three journeys that matter most, using real data on where customers or employees currently hit friction, not assumptions from a workshop. Assign a single accountable owner per journey even before the team fully forms, so the outcome has one name attached to it from day one. Pull a small cross-functional cell around that owner, borrowed part-time from existing functions at first, full-time once the model earns its keep. Replace the deliverable scorecard with an outcome scorecard for that journey, reported at the same cadence the old function status used to get. And let the functional towers stay exactly where they are underneath. MES, ERP, and APS still need deep technical ownership. The journey team just becomes the layer that pulls them toward what the customer actually experiences.
The functions don't disappear. They stop being the primary unit of organization and become the specialist bench the journey teams draw from.
The Risk of Getting This Wrong
The most common failure I've seen is naming a journey owner without giving them any real authority over the functions they're supposed to coordinate. That produces a title without power, someone who gets blamed for delays they can't actually influence, and within two quarters the whole model gets quietly shelved as "didn't work here."
The second failure is trying to flip every function into a journey team at once. Don't. Start with the one or two journeys where the pain is sharpest and most visible, prove the outcome shift there, and let the model earn its own expansion.
Closing
The rolling mill in that opening story wasn't broken. Every function had done exactly what it was measured to do. What was missing was someone whose actual job it was to care about the nine days, not the individual steps inside them.
संघे शक्तिः कलौ युगे, strength in this age lies in coming together. Steel plants have spent decades building real strength inside each function. The next gain probably won't come from making MES, ERP, or APS individually stronger. It'll come from finally owning the journeys that run through all of them, and being willing to measure ourselves by what the customer actually experienced, not by what each team quietly shipped.
#ProductManagement #ProjectPulseAI #OrganizationalDesign #DigitalTransformation #ManufacturingIT #ProductStrategy #CrossFunctionalTeams #BusinessOutcomes #SteelIndustry #EnterpriseIT
Disclaimer: The incidents, characters, projects, and organisations referenced in this article are fictionalised composites drawn from recurring patterns observed across complex transformation programmes. Their purpose is to illustrate leadership and governance lessons rather than describe any specific organisation, project, customer, or implementation. The lessons, however, are very real.