← Back to work

Enterprise platform · Strategy + UX/Product Design

From “build us a tracker” to a clearer operational system

A procurement team asked for a clearer tracker. The work underneath it was a much wider operational system.

  • Product Strategy
  • Discovery
  • Complex Workflows
  • Requirements
  • Enterprise UX
Procurement lifecycle map across planning, documentation, quotes, review, approval, award, and contract managementLifecycle · stages, roles, handoffs
The ask

“Build us a tracker so we can see where things are.”

What the work revealed

The tracker was a symptom. The system around it needed definition.

Financial overview screen showing planned, committed, obligated, and invoiced fundingProduct direction
Strategic summary of the case study: the original tracker request, the lifecycle system underneath it, the reframe, and the resulting product direction.
My role
Product strategy, discovery, requirements, workflow mapping, UX/product design
Scope
Planning, procurement, approvals, awards, and contract operations
Context
Enterprise platform · Strategy + UX/Product Design

01 — THE SITUATION

The ask started with visibility.

A client needed a clearer way to track procurement requests, funding, and status. On the surface, the request sounded relatively straightforward: create a better tracker for work that was already happening.

Coordination

Work was spread across multiple tools and manual processes.

Timeline

A compressed delivery window left little room for exploration.

Goal

Deliver something useful quickly without losing the bigger picture.

02 — Understanding the system

Understanding the system

Simplified procurement lifecycle diagram with stages and the primary role responsible at each stage
Simplified seven-stage model used to explain the lifecycle.

Seeing the system clearly

Mapping the lifecycle made the structure visible: who owned each stage, where decisions changed hands, and how far the work extended beyond the original request.

This was bigger than a tracker.

03 — THE REFRAME

The problem wasn’t the tracker. It was the system around it.

THE REQUEST

A clearer way to track procurement, funding, and status.

The ask focused on visibility into where requests stood.

WHAT BECAME CLEAR

The real problem was a fragmented operational process, not just a lack of visibility.

Ownership was unclear, approvals created handoff points, and the work continued well beyond the original tracker request.

04 — PRODUCT DIRECTION

What that meant for the product

Each insight translated into a clearer product decision.

Visibility was only part of the problem.

Make ownership, status, and next steps visible.

Some stages were real gates.

Model approvals and waiting states explicitly.

The lifecycle extended beyond procurement.

Create a foundation for award and contract operations.

A flat tracker would reproduce the old process.

Structure the product around stages and decisions instead of fields.

05 — DESIGNING THE EXPERIENCE

Designing the experience

These product decisions became the structure of the experience.

Moment 01

Starting and managing a request

A dashboard and request list organized by stage and ownership, so people can see where every request stands, what is active, and who holds the next action.

Decision behind itMake ownership, status, and next steps visible.
01 / 04

06 — DECISIONS & OUTCOME

Key decisions

The product direction came from a few clear commitments about how the system should work.

01

Organize around stages, not fields

Why it mattered

A flat tracker would reproduce the spreadsheet structure without helping users understand progress.

02

Treat approvals as real gates

Why it mattered

Some stages depended on another role making a decision before work could continue.

03

Design beyond the original tracker request

Why it mattered

The work did not end when procurement was complete.

The result

What changed

01

A clearer shared model of the lifecycle

Stakeholders had a clearer end-to-end picture of the process.

02

A tighter and more intentional MVP scope

The team had a more focused definition of what needed to be built first.

03

Development-ready product direction

Requirements moved from feature lists toward ownership, decisions, and workflow rules.

04

A stronger foundation for future award and contract operations

The experience could evolve beyond the original tracker request.

The biggest shift wasn’t the interface. It was understanding the system well enough to know what the product needed to become.

More work