Most product frameworks assume clean boundaries.
Carrier systems don’t have that luxury.
When you build for a shipping line, you’re not building features — you’re working inside a network of interdependent systems:
- Commercial flows (pricing, quotation)
- Operational flows (booking, container movement)
- Planning flows (vessel schedule, capacity)
- Compliance flows (documentation, customs)
- Financial flows (charges, invoicing)
- Integration layers (EDI, APIs, partners)
Booking, Vessel Schedule, and Documentation are just visible touchpoints — not the system itself.
And if you optimize one part without understanding the rest, the system pushes back.
Stage 1: Discovery — Understand the System, Not Just the Workflow
Discovery is not about “what users want.”
It’s about understanding:
- How data flows across systems
- Where decisions are made
- Where manual intervention still exists
Before building anything:
- Trace a shipment end-to-end
- Observe where ops teams step in
- Identify where the system relies on human correction
Most problems are not missing features.
They are:
- Misaligned system behavior
- Timing gaps
- Hidden manual processes
If you skip this, you don’t simplify operations — you shift the burden somewhere else.
Stage 2: Problem Definition — Don’t Define It Too Narrow
It’s easy to define problems around visible areas like:
- Booking
- Schedule
- Documentation
But those are just entry points.
A real problem usually spans multiple layers:
- Input → validation → downstream processing → exception handling
If you define it too narrowly, you optimize locally and break globally.
Stage 3: Scoping — Every Improvement Has a Cost Somewhere Else
This is where most mistakes happen.
You think you’re improving the system — but you’re only improving one part of it.
I’ve done this myself.
We improved the booking flow on the customer-facing side:
- Reduced friction
- Increased booking confirmation rate
- Made the experience faster and cleaner
On paper, it worked.
But downstream:
- More bookings entered a “standby” or edge state
- ERP couldn’t fully process them automatically
- Ops teams had to manually review and resolve them
So what happened?
- Customer metric → improved
- Internal workload → increased
- System efficiency → questionable
We didn’t remove complexity.
We redistributed it.
What this changed for me
Scoping is not about:
- “Does this improve the feature?”
It’s about:
- “Where does the cost go after this change?”
Before adding anything now, I ask:
- Does this create new exception cases?
- Can downstream systems handle the output?
- Who absorbs the edge cases?
Because if the answer is “ops will handle it” — you haven’t solved the problem.
Stage 4: Design — Don’t Hide the System
Carrier systems are not consumer apps.
Users operate within constraints, not convenience.
Good design here should:
- Expose system states clearly
- Support correction workflows
- Reflect real system behavior
Bad design:
- Hides inconsistency
- Assumes perfect data
- Ignores failure scenarios
That’s how you create more manual work.
Stage 5: Build & Delivery — You Are Aligning a System
You are not shipping a feature.
You are aligning:
- Data across systems
- State transitions
- Processing logic
- Exception handling
Most failures don’t come from bad code.
They come from:
- Systems interpreting data differently
- Missing edge-case handling
- No visibility into processing states
If you only validate at the UI level, you miss the real problems.
Stage 6: Launch — Adoption Depends on Trust
A feature being “live” doesn’t mean it’s used.
In carrier systems, adoption depends on:
- Whether ops trusts the output
- Whether customers rely on it
- Whether it reduces manual work
If your feature:
- Improves UX but increases correction workload
→ ops will resist it
And eventually: → customers feel that inconsistency too
Stage 7: Iteration — Follow the Friction, Not the Metrics
Metrics tell you what improved.
Friction tells you what broke.
After launch, look at:
- Manual intervention points
- Repeated corrections
- Workarounds inside the system
That’s where the real product gaps are.
Final Thought
Carrier system development is not about building features.
It’s about balancing a system where:
- Every improvement creates pressure somewhere else
- Every simplification risks hiding complexity
- Every decision has downstream impact
Booking, Vessel Schedule, Documentation — these are just entry points.
The real product is how the system behaves end-to-end.
If you:
- Optimize locally → the system breaks globally
- Ignore downstream impact → ops absorbs the cost
- Hide complexity → users work around you
This is not a clean lifecycle.
It’s continuous system negotiation.
And if you get that right —
you don’t just improve metrics.
You build something that actually works in the real world.