Blueprint Before Backlog

TL;DR

Internal tools don’t usually fail because of one bad screen. They fail because the system grows faster than the organization’s ability to keep it coherent.

A major freight brokerage had a fragmented Transportation Management System that had grown through acquisition, leaving brokers to rely on workarounds, shadow systems, and tribal knowledge.

I led discovery, service blueprinting, and competitive analysis to make the workflow legible, align teams on a shared model of the problem, and translate that model into a roadmap that multiple squads could execute without thrashing.

Impact:

• Analyzed 15+ TMS competitors and adjacent exemplars.[tms]
• Produced a service blueprint that aligned role-based workflows and ownership boundaries.¹
• Delivered a roadmap with clear sequencing and prioritization logic.

---

Industry Primer

Freight brokerage is operations under time pressure. The software is the work environment:

• deals are negotiated fast
• handoffs between roles are constant
• notifications and exceptions drive most of the day

If the system is fragmented, the business still runs, but it runs on human glue.

---

Context

The organization had accumulated multiple systems and patterns through growth. Each team could make local improvements, but local optimization wasn’t translating into global workflow improvement.

Brokers compensated by building their own workarounds. That kept deals moving, but it made the system harder to evolve: knowledge lived in people, not in product design.

---

Problem

Fragmented workflows and inconsistent surfaces created rework

Users navigated inconsistent patterns across tools, which increased cognitive load and raised the cost of onboarding and change.

Notifications and handoffs were noisy and unreliable

When a system can’t reliably answer “what needs my attention next,” users invent their own task management, and operational complexity balloons.

---

Solution

Decision 1: Make the ecosystem legible

I mapped the end-to-end workflow across roles and created a service blueprint that showed:

• primary tasks, exceptions, and handoffs
• where information was lost or duplicated
• where teams were solving the same problem differently

Decision 2: Align teams on one model of success

We facilitated alignment workshops to converge on:

• shared problem statements
• success measures
• ownership boundaries that reduced “unclear responsibility” stalls

Decision 3: Use competitive patterns strategically

I analyzed 15+ TMS competitors and adjacent exemplars to identify:

• patterns worth standardizing
• where parity would be a trap
• where small usability improvements could compound (notifications, task focus, handoff clarity)

---

Results

The most durable outcome was a capability:

• teams shared a common workflow model
• backlogs could be sequenced without re-litigating fundamentals
• leadership had clearer trade-offs between “fix local pain” and “fix systemic dysfunction”

---

What I'd Do Differently

I would formalize instrumentation earlier around operational units of work: exceptions, handoff failures, and time-to-resolution. In these environments, workflow improvements can be measured, but only if the “unit of friction” is defined in a way everyone agrees on.

---

Collaborators

I partnered with product and engineering leads across multiple squads, plus frontline broker stakeholders, to translate workflow reality into a coherent roadmap and prioritization system.

Footnotes

1. A service blueprint maps the end-to-end service across roles and systems, including frontstage user actions and backstage handoffs and dependencies. ↩