When the problem isn't the product —
it's how decisions get made about it

Context & System Complexity

The subcontracting workflow spans three document stages — Purchase Order (PO), Order Confirmation (OC), and Advance Shipping Notification (ASN) — each a discrete handoff between buyer and supplier organizations. Four roles operate across these stages with divergent authority scopes and tolerance thresholds: Buyer, Supplier, Operations, and PM.

This is a distributed system with shared state. An action at PO propagates into OC. Errors at ASN frequently trace back upstream. In this context, delayed prioritization is itself an experience defect — users whose work stops when the system is ambiguous bear the cost of every unresolved decision.

Strategic Diagnosis

Before defining any solution direction, the work required understanding why issues had persisted — not simply cataloguing them. An organization that accumulates usability problems without resolving them has a structural failure upstream of the backlog.

Three root conditions

Issue accumulation without classification. Problems were logged across research, support escalations, and stakeholder submissions. No severity taxonomy existed. No business-impact linkage. No differentiation between issues that blocked task completion and those that created friction without causing failure.

Cross-functional accountability gaps. Each team could identify problems in their own domain but had no mandate — and no venue — to resolve issues requiring joint commitment. Design, Engineering, Ops, and PM each held partial ownership over different lifecycle stages. Decisions that needed more than one team simply didn't get made.

Prioritization by proximity, not impact. Without a shared framework, decisions defaulted to recency bias and whoever held the most immediate stakeholder pressure. High-impact, high-dependency items sat unresolved while lower-stakes work shipped first.

Decision Architecture Framework

The framework had one objective: convert a heterogeneous issue inventory into a structured set of decisions with defined inputs, clear criteria, and a locked output. Not backlog grooming — a governance intervention at the product strategy level.

Severity taxonomy

Every issue was classified on four levels before any prioritization discussion. Classification used system-behavior criteria, not user sentiment.

Impact × Effort Matrix — core strategic artifact

Dependency & Blocker Mapping

Several high-priority issues couldn't execute independently — they required upstream architectural decisions before design changes could be meaningful. I mapped each item explicitly as blocker (sequential prerequisite), dependency (requires coordination, not sequencing), or independent. This prevented the most common sequencing failure: a plan that looks rational on paper but breaks when a team hits an unresolved constraint mid-sprint.

Governance & Ownership Model

A prioritized issue list without assigned ownership is a document, not an agreement. The model enforced two rules: one primary owner per item, and explicit declaration of cross-team involvement. Every item required a named decision owner — not a team, a role.

The model also defined escalation behavior: if an item crossed ownership boundaries mid-execution — due to scope expansion, technical constraint, or new stakeholder input — the escalation path was documented, not left to informal resolution.

Agreement Lock & Direction Reset

The workshop's output was a cross-functionally ratified execution plan: what gets addressed, in what order, owned by whom, and what is explicitly deferred. "Locked" is the right word — the purpose was to end the re-litigation cycle that occurs when decisions are treated as provisional.

Workshop structure

• 1
  Issue Review & Severity Alignment

  Participants reviewed the classified inventory and challenged severity assignments. Disagreements were resolved against defined criteria — not consensus or seniority.

• 2
  Impact × Effort Placement

  Teams collaboratively positioned issues on the matrix. Engineering provided effort estimates; Design and PM framed impact. Placement was debated, not assigned.

• 3
  Dependency & Blocker Declaration

  Each high-priority item was tested for dependencies. Teams declared blockers explicitly. Items that couldn't proceed without unresolved prerequisites were flagged and sequenced accordingly.

• 4
  Ownership Commitment & Sequencing Lock

  Each item received a named owner and a sequencing position. Deferred items were acknowledged as deferred — not dropped. The plan was read back and ratified before the session closed.

Organizational Impact

The direct output was a resolved decision backlog with clear execution sequencing. The more durable output was the framework itself — the taxonomy, the matrix, and the workshop model are now reusable governance artifacts for this team.

Beyond the immediate plan, this engagement produced a documented account of how decisions get made on this product — who holds authority at each decision point, what criteria govern trade-offs, and how contested items resolve. That decision transparency is unusual in enterprise product teams and reduces onboarding cost for new stakeholders entering complex systems.

What Changed Systemically

The surface change was a resolved issue backlog. The systemic change was the introduction of a decision-making model where none previously existed. That distinction matters for how this work should be evaluated.

What this was not

This was not a redesign. No screens were produced. The work didn't improve an interface — it established the conditions under which interface improvements could be made reliably, in the right order, by the right teams.

What it demonstrates at scale

In enterprise platforms with long lifecycles and multi-team dependencies, decision quality is a product quality metric. Teams that can't resolve cross-functional trade-offs efficiently ship the wrong things in the wrong order — not for lack of good ideas, but for lack of structures that convert good ideas into committed action.

The framework here — severity taxonomy, impact × effort placement, dependency mapping, ownership assignment, sequencing lock — is not specific to subcontracting. It's a decision architecture that adapts to any multi-team context where the primary problem is not what to build but how to decide what to build first, and ensure the decision holds.

What I would do differently

An async pre-workshop phase would compress live decision time and surface genuine disagreements earlier — spending session time on contested items rather than cases with clear consensus. I'd also formalize the escalation protocol before the session rather than inside it, reducing ambiguity for teams executing independently post-workshop.