Skip to content

Retrospective / Lessons Learned: Personal Training OS

Artifact: 7.1 (Phase 7, Closure) · Owner: Delivery Manager (Primary User) · Date: 2026-07-09 Scope: the v1.0 delivery (G0 to G6) plus post-release Increments 2 to 4.

A retrospective is the PM's structured look back: what went well, what did not, what we learned, and what changes carry forward. Kept blameless and specific.

1. What was delivered

  • v1.0 (MVP) live 2026-07-05, 19 days ahead of the race-week forcing function. A 16-database Notion workspace with a relational backbone, hockey-attendance and shoe-mileage logic, populated training plans, and a dashboard. 20/20 test cases plus 7/7 UAT (G5), released and backed up (G6).
  • Post-release increments (gated change control, MoSCoW v1.3+): Increment 2 (Garmin activities, Garmin daily wellness metrics, and Withings weight, all live on a daily sync), Increment 3 (hockey auto-scheduling, closing defect D-04), Increment 4 (MyFitnessPal nutrition via an emailed-CSV Gmail relay, live and hands-off after a single export tap). These increments run on operational evidence (green daily sync logs and verified Notion rows) and are not yet covered by the formal V&V suite.

2. What went well

  • Design-first paid off. Requirements and design were baselined (101/101 coverage) before build, so an AI-implemented build against that baseline completed in days rather than the two-week estimate. The operator directed the delivery and governance; the AI did the implementation.
  • The increments exceeded the v1 objective. v1 only promised "automation-ready" (provenance fields designed in). Recovering capacity ahead of schedule let the team actually wire Garmin, Withings, hockey, and nutrition, live and idempotent, well beyond the original scope boundary. They carry operational evidence only and are not claimed as formally verified.
  • Feasibility spikes caught dead ends cheaply. Verifying options against primary sources (not blogs) killed the Garmin business-only API, the ToS-barred MyFitnessPal scraper, and the Withings-as-nutrition -proxy idea before any build cost. The "alternatives considered and parked" records stopped re-litigation.
  • Governance recovery worked. The project opened at requirements and backfilled initiation/planning out of order (a real situation PMs face), and still ran cleanly to a gated close.

3. What was hard / what did not go well

  • The delivery record drifted from the build. Twice. A MoSCoW amendment was not propagated to its consumer documents, and later three integrations shipped live while the docs still called them deferred and the internal PM tree still described the project as pre-Build. Discipline alone did not hold the record accurate.
  • Third-party data shapes were not what their names implied. The Withings API does not expose the nutrition its app displays; MyFitnessPal's "Meal Level" export is actually one row per food. Both were caught only by fetching and inspecting the real artifact, and one of them (the per-food key collision) not until the first live ingest wrote duplicate-keyed rows.
  • A late-caught data bug. The per-(date, meal) key collided because the export is per-food; the fix (aggregate to per-meal totals) plus a data cleanup came after the first load, not before it.

4. Lessons learned (carry these forward)

  1. Make documentation accuracy mechanical, not a discipline. The fix that held: a single as-built state ledger plus a CI drift-gate that fails the build when the code, the ledger, and the public docs disagree, plus a Definition-of-Done requiring ledger reconciliation on any automation change. Governance you have to remember to follow is governance that fails.
  2. Verify against reality, not the narrative. Code, logs, live rows, and the actual exported file are the source of truth; the docs are a projection. Establish ground truth from the source before you document or decide.
  3. Verify third-party API and data assumptions before building. An app showing data is not its API exposing it; an export's name is not its schema. Fetch the real thing and inspect it first.
  4. Idempotency needs a key that is actually unique in the real data. Upsert on a stable source id and validate that key's uniqueness against a real sample; collisions stay hidden until you check.
  5. Annotate baselines, rewrite living docs. Signed records and baselines (requirements, V&V runs, charter scope) get dated forward-pointers, never rewrites; only living docs are updated in place. This kept history honest and un-falsified.
  6. Report status honestly. "Live on operational evidence" is not "formally verified." The increments are flagged as not-yet-in-the-formal-V&V-suite everywhere they appear.

5. Actions carried forward

  • Formal V&V of Increments 2 to 4 (currently operational-evidence-only) is a tracked gap, owned as a post-closure warranty item (see the post-implementation review).
  • Adoption (SC1) is measured post-race-week; monitor >7-day staleness (RAID R1).
  • Deferred scope (Apple Health, live Strava, Calendar sync, RAG, more users) stays parked, each individually gated if pulled.