← → to navigate
1 / 11
Home
Product Owner walkthrough · Nayan Lal

SeaTrace: replacing a legacy ERP with a batch-traceability platform.

A feature-to-product story told in your template's order, ending with two minutes on your domain.

01Business goal & problem 02Team & collaboration 03Execution & Product Owner activities 04Outcomes 05Lessons learned
01 · Business goal & problem

Farm to fork, with the trace broken in the middle.

Avanti Frozen Foods, one of India's largest shrimp exporters, ran on a legacy ERP with no batch-level traceability. This is one real batch through the plant. Watch what happens to it.

Eight stops, the real weights, and the moment the trace breaks.
  • Recalls widen because the source batch cannot be isolated.
  • Global buyers demand compliance proof the system cannot produce.
  • Planning runs blind: which purchase orders are at risk, which buyers matter this week.
  • Who set the goal: PatternLab's founders, with the exporter as joint-venture partner, committed to a traceability-first platform. Strategy was set above me; I owned making it real.
  • How it reached me: as a vision and a partner commitment, not a backlog. My translation: founders' vision + SME and demo feedback + market and competitor analysis into a 5-epic MVP roadmap.
0 source tables 0 mass-balance target 0 epics in the MVP
02 · Team structure & collaboration

A 14-person pod. I ran the cadence.

Founders PM function · strategy + client Me + 3 PMs · Founder's Office backlog · cadence · all ceremonies 14-person pod 2 backend · 6 full-stack · data science · QA · design · client SMEs with PM roadmap down, evidence up with UX A/B loop + feasibility with AI/ML no black box, guardrails
  • What I ran: the backlog and every ceremony, planning through review. How I used the cadence to unblock delivery is the next section.
  • With the PM function: roadmap flowed down; evidence flowed back up. The scope call later in this story is that loop working.
  • With design: refinement loop. UI variants and completion CTAs were A/B-tested through our Customer Intelligence Dashboard; engineering feasibility fed back before design over-committed.
  • With data science and AI: two rules. Deterministic first: no black box, every insight reproducible with an evidence chain. And LLM insight-card prompt testing behind format guardrails.
03 · Execution & Product Owner (PO) Activities

A vision, a partner commitment, and no backlog.

What arrived was strategy, not a backlog. I turned it into five epics, then specified each so an engineer never had to guess intent.

EPIC 1
ImpactKPI Top Insights
the KPIs planners open first, served off the graph
EPIC 2
Base Forms
structured data entry into the knowledge graph
EPIC 3
KG Reports
batch cost, raw-material, traceability queries
EPIC 4
QC Integration
antibiotic, microbial, organoleptic at every section
EPIC 5
Exports + PO Module
auto-map purchase orders to identified batches
PRD structure problempersonasscope technicallogic & formulaeUX validationsuccess criteria
Acceptance criteria · PO prioritisation
  • Order pool filterable: plant, promise week, buyer tier, risk bucket
  • Default sort by priority score; every row shows its top-2 reasons
  • Freeze-plan snapshot with day-over-day deltas
Exit criteria (not "the model is accurate")
  • Ranking reproducible from the same inputs
  • Machine-readable explanation JSON per PO
  • Daily refresh end-to-end under 10 minutes at one plant
Acceptance criteria for an AI feature are not "the model is accurate." They are reproducible, explained, and fast enough for the 6 AM planning meeting.
Live · Purchase Order priority queue
score = Time × w + Buyer × (1 − w)
Buyer weight Time weight
Time 0.65 · Buyer 0.35
Drag the slider: the queue re-ranks live and the rank numbers move. Showing the top-2 reasons is a product requirement; the weighting is a product decision.
03 · Execution & Product Owner (PO) Activities

The forms stalled. Here is what I changed.

The data-entry forms were foundational, and they stopped moving: the data lived in the client's backend, too many stakeholders touched every decision, and the team was not yet using AI tooling well. I did not escalate and wait. I sequenced it.

1WIREFRAMEargue about a picture, not a paragraph
→
2SCHEMAdeliberated, owned by backend, one owner
→
3API + MOCKScontract with mock payloads
→
4BUILDswap mocks for real endpoints
→
5DESIGN + SMEfinal review and sign-off
Because the API contract shipped with mock payloads, frontend and backend built at the same time, not in sequence. Multiple forms ran this pipeline in parallel, status checked daily.
11-day sprints
Tuned to the release and review rhythm the team actually worked to, not a textbook two weeks.
Two stand-ups a day
10:00 AM and 9:00 PM. The 9 PM one existed so client and SME conversations could actually happen across the time-zone gap.
Capacity, not quality
When scope moved, I brought in part-time members rather than cutting the definition of done.
Unblock by access
My main lever: an engineer in front of the right SME immediately, rather than a domain question sitting for two days.
03 · Execution & Product Owner (PO) Activities

Where the uncertainty actually lives.

In an AI product, the honest question is not "is the model right" but "what do we do when we cannot be sure." In every case my answer was a product rule, not model magic.

Data uncertainty

Mark it, do not guess it

Purchase orders with no derivable promise date are marked Data Incomplete and visibly excluded from the ranking queue. "% of ranked POs using assumptions" is an instrumented KPI: the data mess is exposed and priced, never hidden inside a prediction.

Model uncertainty

No black box

Every insight had to be reproducible from the knowledge graph with its evidence chain. If it could not be traced back to the rows that produced it, it did not ship. Determinism first, generation second.

LLM evals · and the ones that failed

Guardrails that actually caught things

PASSFormat conformancevalid JSON, required fields
PASSFaithful to the graphno claim without evidence
FAILNumeric accuracy on cost deltasjudge + rival model caught it, prompt fixed
FAILNo unprompted recommendationstone drift caught, constraint added
Data quality, before the cloud

Consolidate, then migrate

The source system was 79 tables. Rather than lift the mess into the cloud, we consolidated and closed data endpoints with no determined destination first, and surfaced mass-balance breaks so the graph inherited clean lineage, not hidden gaps.

The precision-recall trade-off was decided at planning, not left as post-implementation tuning. A false positive delays a shipment; a false negative causes a recall. Those costs are wildly different, so where you sit on that curve is a product decision, made before anyone trains anything.
03 · Execution: scope decisions & delivery surprise

Two scope calls and one surprise.

Call 1 · Prioritise the MVP

The call
Two pods competed for the same people. I prioritised the SeaTrace MVP over the factory-intelligence work.
Why
A joint-venture partner was on a committed plan; the MVP protected that commitment.
The result
Factory intelligence continued behind it and later became its own product line. The call held up.

Call 2 · Buy the graph, build the value

The call
We did not build the knowledge-graph engine ourselves. We partnered with a specialist and contracted their deliverables.
Why
Our differentiation was the forms, reports and planning logic on top, not re-implementing graph infrastructure.
Vendor deliverables, in the roadmap
Batch & route representation 95% mass balance Cycle times per section Cost per batch Pro-rata allocation on batch mixing

The surprise · AI-first velocity

When we gave developers vetted AI coding tools and LLM API access for the forms and schema work, shipping speed jumped visibly and capability compounded sprint over sprint. I now treat developer AI enablement as a delivery lever a Product Owner should pull, not an IT procurement question.

Illustrative team velocity with AI tooling
Qualitative; no fabricated multiplier claimed.
04 · Outcomes

What SeaTrace shipped, and the pod I ran alongside it.

0core modules shipped in ~3 months
0person cross-functional pod
0pods led in parallel
0source tables mapped for the graph
Delivered on scope: the four core MVP modules landed in roughly three months, with traceability core first, exactly as the contract with the partner required.

SeaTrace · shipped

  • Impact KPI dashboard (Epic 1)
  • Batch-traceability core on the knowledge graph
  • Data-entry forms + KG reports (Epics 2, 3)
  • QC integration + Exports / PO module (Epics 4, 5)

Product-health KPIs designed before launch, not retrofitted:

Booking accuracy Batch conformance % First-pass yields Grade-mix vs plan % days with a plan snapshot % ranked POs on assumptions

In parallel · the factory-intelligence pod I also led

0DAU / MAU growth
0 → 0 minavg session (~3.7x): users ran their day in it

The Customer Intelligence product I ran alongside SeaTrace. Being explicit: these engagement gains are its, not the traceability MVP's. Running both in parallel is the point.

Consciously deferred to Phase 2/3
Full 79-table graph constructionGolden-batch fingerprinting per SKULCA / ESG sustainability reporting
05 · Lessons learned

Two lessons and one honest do-over.

LESSON 1

Explainability buys adoption

Planners trusted the top-2-reasons column before they trusted the score. They would not act on a number they could not interrogate, so deterministic, evidence-chain insights became a product principle, not a nice-to-have.

LESSON 2

Data quality is a product surface

Make the mess visible and priced: Data Incomplete flags, mass-balance breaks, instrumented assumptions, and consolidating the source tables before they reached the cloud. Never let a model quietly paper over it.

WHAT I WOULD CHANGE

Standardise earlier, and plan for failure sooner

I built the schema-first workflow reactively, halfway through, after the forms had already stalled. The cost was a sprint I did not need to lose.

  • 1Pre-mortem in planning. Take failure feedback from the team in the sprint-planning call itself, or a short call right after, on what is likely to break, before committing the sprint.
  • 2Schema-first from sprint 0. Institute the PRD → TRD workflow at the start, not mid-stream when a blocker forces it.
  • 3SMEs from day one. Bring the client's subject-matter experts into refinement from the beginning, rather than meeting them at design review.
A planner will not act on a number they cannot question, and a model cannot be trusted to hide a mess it never priced.
Both lessons are the same argument: build in the open.
One more thing

Same method, your domain.

After my first conversation with ModMed, I tested how fast I could get into your domain. Over a weekend I did what I just described, alone and in miniature.

  • Discovery SQL first: a synthetic 6,000-claim warehouse showed roughly 80% of denials trace to causes knowable before submission.
  • A working co-pilot: denial risk score on every pre-submission claim, reasons in biller language, predicted denial code, one-click fix with undo.
  • Evaluated, not just built: temporal backtest, AUC 0.85, and the operating threshold exposed as a product decision: biller workload against denials caught.
Open the live demo →
Fictional platform · synthetic data · built to learn the domain
NewMed · Denial Prevention Co-Pilot
93%CLM-04687 · Medicaid · 66984 · $1,973
41%CLM-02909 · BlueShield · 96910 · $111
18%CLM-00641 · Medicare · 29881 · $2,870
Why flagged: prior auth missing · eligibility 77 days stale → predicted denial CO-197
Apply fix risk 93% → 55%, with undo
Thank you

Questions welcome.

Everything shown today is inspectable.

  • Live prototype: portfolio-projects-newmed.vercel.app/copilot/
  • Full product requirements pack (functional specs, TRD, design requirements, evals & QA): available on request.

Nayan Lal · nayanlal1909@gmail.com · linkedin.com/in/nayan-lal