Shipping the AI × CO₂ MVP

Nordic Loop was developing an MVP that combined four components built in parallel: AI image classification (YOLO), CO₂ estimation engine (EN 15804-aligned), UI/dashboard, and backend orchestration. Each team was making real progress independently.

The problem was that parallel progress created the appearance of readiness without producing a usable product. Four modules building toward each other, with no shared workflow, no defined contracts, and no owner for the seams between them.

Without intervention, the risk wasn't that modules would fail. It was that they would all succeed individually and still not connect.

• No unified end-to-end workflow from photo capture to CO₂ output
• Input/output contracts between modules undefined. Teams were building against assumptions, not agreements.
• Unit conventions unspecified (COUNT vs m²), ambiguous across AI, CO₂, and UI
• Responsibility for quantity input unclear (AI inference vs user entry)
• MVP scope boundaries drifting. Features being added without a defined ceiling.
• Integration dependencies and sequencing unowned. No one was managing the critical path.

The consequence: no working end-to-end demo before pilot delivery. A pilot with a collection of partially-integrated modules is not a pilot.

I took product ownership of the integration layer. Not the modules themselves, but the contracts and sequencing between them.

Six decisions that unblocked the system

• Defined a canonical user workflow: Photo → Category → User Override → Quantity → CO₂ Estimate → Listing. Shared as a visual north-star artifact with all four teams. Made the end state concrete.
• Introduced category-based unit taxonomy. Flooring and Partitions require m²; Seating and Doors default to COUNT. Resolved the unit ambiguity without requiring each team to agree from scratch.
• Added a user override mechanism. The user confirms or corrects AI classification before proceeding. This decoupled CO₂ delivery from AI accuracy. The system no longer needed a perfect model, it needed a good enough model with human correction available.
• Defined a minimal integration contract: {category, quantity, unit}. Three fields. Every module could build against this without waiting for the others to finish.
• Adopted tiered CO₂ estimates. Tier 3 (indicative, ±range displayed) was sufficient for MVP. CO₂ no longer had to wait for AI precision improvements.
• Reframed the milestone from progress reporting to demo delivery. Teams shifted from "we're working on it" to "we commit to a working demo in two weeks." Engineers volunteered deadlines once the ambiguity was removed. Strong buy-in signal.

I also facilitated a cross-discipline integration meeting (AI, sustainability, UI, backend) to convert implicit assumptions into explicit decisions, define test scenarios for the demo, and surface sequencing dependencies before they became blockers.

MVP frozen around:

• AI classification to 7 categories only
• User override for category correction
• User-entered quantity for m² assets
• Tier 3 CO₂ estimates with variance displayed
• Synchronous demo path

Explicitly excluded: multi-object detection, surface area or weight inference by AI, accuracy targets for the model, higher-tier CO₂ precision. Every exclusion was a deliberate tradeoff, not a deferral. The scope boundary was the product decision.

Accepted lower automation and lower scientific precision in exchange for:

• Shorter integration time
• Clear contract boundaries every team could build against
• Reduced engineering uncertainty
• A demo path that could be committed to and delivered

The principle: demonstrate value early, defer sophistication.

• Internal demo delivered in 2 weeks. Full MVP completed in 4–5 weeks. Deadlines that had previously been tentative became commit-able once ambiguity was removed.
• CO₂ module unblocked from AI perfection. Tiered estimates and user override meant the sustainability engineer could integrate and ship without waiting for model accuracy improvements that weren't coming within the MVP window.
• Team shifted from local optimisation to system delivery. Before the integration meeting, each module was optimising independently. After, execution became system-first.
• Integration risk reduced before pilot phase. Dependencies surfaced pre-build rather than post-build. No late-stage integration failures during the Mod:group or Skanska pilots.
• Enabled the enterprise pilots that followed. The MVP demo was the artefact that made Mod:group and Skanska pilots possible.

In interdisciplinary products (AI, sustainability, UX, backend), complexity concentrates at the seams between teams, not inside the modules. Each team can be doing excellent work and still produce nothing usable. PM leverage is in owning the seams: defining contracts, sequencing dependencies, and making the minimal path to value explicit.

The MVP didn't need to be scientifically precise. It needed to be coherent enough that a construction manager could photograph a chair, see a CO₂ estimate, and believe the product was real. That's a different problem than accuracy. And a much faster one to solve.

When engineers volunteer deadlines, it means the ambiguity has been removed. That's the signal the PM work is done.