Kai John-Blunch

Product management proof

Workflow Mapping For Construction Operations

I narrowed a broad procurement idea into a bounded subcontractor-activation workflow with concrete states, supported claims, and human decision authority.

Read the narrative Inspect the summary
  • Workflow mapping
  • Requirements mapping
  • Human-in-the-loop design
  • Claim safety

Problem

A procurement and subcontractor-activation direction sounded promising, but broad language like AI for procurement would have hidden the real workflow and created unsupported claims.

What I owned

I mapped the work to pre-contract subcontractor activation: intake, missing documents, insurance and compliance checks, readiness tracking, follow-up, handoffs, and human sign-off.

Result

The team had a workflow-specific product claim it could test safely instead of an overbroad procurement story.

Certain buyer examples, target details, and internal artifacts have been summarized or generalized.

The situation

The vendor-procurement experiment started with a question that could have become too broad quickly: should Pier test a procurement or subcontractor activation direction instead of staying inside hiring-led positioning?

The useful product work was narrowing that question. Vendor procurement was the umbrella. The actual workflow we could reason about was pre-contract subcontractor activation: the gap between a subcontractor being selected and being ready to mobilize.

That gap had a specific shape. It was not an abstract market label. It was forms, missing documents, insurance and compliance checks, readiness items, follow-up, unclear ownership, and handoffs from procurement to field operations.

The approach

I helped make the workflow specific enough to test. The work involved intake forms, missing documents, insurance and compliance checks, readiness items, repeated follow-up, unclear ownership, and handoffs from procurement to field operations.

If we described that as AI for procurement, we would lose the real workflow. If we described it as autonomous approval, we would overclaim.

So the product decision was a claim-boundary decision: make the workflow specific enough to test, and keep the story inside what the evidence could support.

GitHub issue tracker showing the procurement validation work plan and review gates.
The tracker kept the workflow bounded: each stage had to preserve source evidence, claim boundaries, review gates, and a path back to the allocation decision.

What I owned

  • narrowing the use case from broad procurement language to subcontractor activation
  • separating supported claims from unsupported claims
  • keeping hiring and ATS language out of the experiment
  • making human decision authority explicit
  • translating buyer pain into workflow states, handoffs, readiness gaps, and safe product claims

Why it matters

This is workflow mapping in product-management terms. Before a product can automate or assist a workflow, the PM has to understand the job, the states, the handoffs, the claims the product can support, and where human judgment still belongs.

Result

The team had a bounded product claim it could test: reduce manual follow-through, improve readiness visibility, create cleaner handoffs, and make it easier to see what was still blocking mobilization.

What I learned

Agentic workflows become safer when the workflow is concrete first. Autonomy is not the starting point. The starting point is understanding the states, failure modes, evidence, and human decision boundary.