AI products that survive contact with the real world.

Role

Senior Product Manager, Integrations & AI

Org

Compass Digital · Toronto

Team

5 cross-functional squads — ~25–30 engineers incl. QA, 4 designers, 1 associate PM

Partners

Global Payments, Agilysys, Volante, Grubhub, Transact, Amazon, Google

Product

CentricOS integration layer — live at 10,000+ locations

Context

CentricOS is the integration layer behind Compass's POS and kiosk estate. Its job is to publish menu and configuration changes out of the backend and into partner systems. It runs live at 10,000+ locations, inside a 30,000-site, 292,000-user North American estate.

The problem

Tickets kept arriving about synchronization delays. Publishes were sometimes late; sometimes the end-to-end integration broke outright. The mechanism underneath was polling — and the failure mode was more interesting than a wrong value.

The partner system would drop a process and send no acknowledgment at all. Nothing reported an error. From our side the publish looked sent. From the site's side, the menu was simply stale. The data quality problem was an absent signal, not a bad one — which is why it never showed up cleanly in a ticket queue.

Approach

The partner move came before the engineering move. I asked the partner to build a dashboard — on their side — exposing the KPIs that measured our SLAs, and we reviewed it weekly.

• An SLO breach stopped being a claim I was making about their system and became a fact on a screen we were both looking at.
• The weekly cadence moved the conversation from incidents to trends — from "this store is broken today" to "this is drifting."
• Only once we shared instrumentation did the joint engineering work have a scoreboard to land against.

What we built

We replaced polling with webhooks. State changes propagated with acknowledgment, instead of being inferred from a poll that might silently never have run — so a dropped process announces itself instead of hiding.

Role

Senior Product Manager, Integrations & AI

Org

Compass Digital · Toronto

Starting point

A goal, not a product idea — "accelerate site onboarding"

Adoption

150+ implementation team members running site deployments

Headline metric

69% fewer integration-configuration support tickets

Context

The brief was as open as briefs get: accelerate site onboarding. Velocity was slowing and nobody could say why. So the first work wasn't building — it was diagnosis.

What the diagnosis found

Implementation teams could not get the right information at the right time. Configuration knowledge was scattered across team wikis, support tickets and tribal memory — every team had its own.

It surfaced as open support tickets, but the tickets undercounted the real cost. The expensive part was the conversations: stop, ask, wait, get unblocked hours or days later — repeated on every single deployment. That reframed the goal: this was a knowledge-delivery problem, not a headcount problem.

Build one — the corpus

I shipped Orbit, which pulled the scattered configuration knowledge into one system. It solved where the knowledge lived. The corpus it created turned out to be the necessary foundation for everything that followed — but on its own, finding the right piece in time was still the bottleneck.

Build two — the distribution

The step that moved the number was changing how the knowledge reached people. I built an internal, IAM-gated MCP server exposing CentricOS operations data to LLM agents — putting answers inside the tools implementation teams were already working in, instead of asking them to go somewhere else to look.

Because people would trust it mid-deployment, it needed a quality layer, not just a retrieval layer:

• Tool-invocation accuracy moved from ~85% to 93%.
• A 100-question golden eval set on a biweekly refresh.
• Confidence-threshold abstention with gap logging — the system says "I don't know" and records what it didn't know, which becomes the next content backlog.
• Per-tool P95 latency budgets.
• Authorization treating role and data scope as orthogonal axes, resolved server-side from the authenticated principal, with on-behalf-of exchange so the gateway holds no standing credentials.

Impact

• 69% reduction in integration-configuration support tickets.
• Reversed a decline in monthly onboarding throughput — the metric that actually gated how fast new sites went live.
• 150+ implementation team members running site deployments adopted it — the people at the forefront of getting sites live.

Role

Senior Product Manager, Integrations & AI — vision, strategy and execution

Org

Compass Digital · Toronto

Stack

YOLO detection, DeepSORT tracking, Google Coral on-device inference

Stage

Pilot-scale in-house platform (0→1)

Context

Operators at high-traffic dining sites had no real-time visibility into wait times or foot traffic. Staffing and layout decisions were made on instinct and lagging reports.

The question

From a blank sheet: could the camera infrastructure already installed be turned into an operational-intelligence layer rather than a security artefact?

Approach

• Led vision, strategy and execution of an in-house edge Vision AI platform — YOLO for detection, DeepSORT for tracking, running on Google Coral hardware.
• Chose edge over cloud deliberately: privacy and latency both pointed the same way. Frames are processed on-device; only counts and timings leave the site.
• Owned model selection, accuracy monitoring and the retraining loop in production — plus the operator-facing analytics that made any of it usable.
• Separately piloted frictionless retail by integrating Amazon Just Walk Out stores with our in-house apps.

Designing for the room, not the lab

Controlled-test accuracy did not predict performance under real lighting and real crowd density. So I made real-world data collection and a retraining loop a funded line item rather than a contingency, and held the platform to production monitoring rather than benchmark scores. That decision is what made the numbers usable to an operator.

Outcome

A pilot-scale platform producing wait-time and visitor-count analytics from live camera streams, in messy real environments rather than a lab.

Role

Product Manager — Sensors & Smart Thermostat

Org

ecobee · Toronto

Timeline

March 2020 – October 2021

Ownership

Pricing and P&L for the SmartSensor line

Stage

0→1, newly launched

The product

The SmartSensor line uses thermal sensing to detect occupancy — that isn't a feature bolted onto the product, it's the mechanism the product runs on. Getting the sensing right and getting the certification right were the same job.

What I owned

• Translating business requirements into technical requirements the embedded, software and hardware teams could each build against in parallel — the coordination problem that decides whether a hardware schedule holds.
• BOM optimization, where every component choice is simultaneously a cost decision, a supply decision and a performance decision.
• The full qualification path: EVT → DVT → PVT → field trials → FCC certification for the target markets.
• Pricing and P&L for the line — not just the spec, the economics.
• Defining the product success metrics, and partnering with marketing and engineering on go-to-market.

Why the gates matter

Software lets you ship and correct. Hardware doesn't. Each gate exists to make a specific class of failure expensive now rather than catastrophic after tooling — EVT proves the concept works at all, DVT proves the design is manufacturable, PVT proves the factory can actually repeat it, field trials prove the thing survives a real home. The temptation on every schedule is to compress one of them. The discipline is knowing which risk you're accepting when you do.

A note on metrics

The line was newly launched and genuinely 0→1, so there is no mature adoption data here and I won't manufacture any. What I can point to is the ownership: requirements, BOM, every gate, certification, pricing and P&L.

Role

Product Manager — Sensors & Smart Thermostat

Org

ecobee · Toronto

Product

Core thermostat line — a different product from the SmartSensor

Stake

~40% of company revenue · ~6 months of inventory left

Context

During COVID the EV surge consumed global microcontroller supply. Our preferred MCU became unobtainable for months.

It sat inside a core thermostat product line representing roughly 40% of company revenue, with about six months of inventory left. That is not a procurement problem with a product consequence — it is a product problem wearing a procurement costume, and it lands on the PM.

Approach

• A low-cost variant built on alternate components, so there was a shippable product that did not depend on the constrained part.
• A deliberate multi-microcontroller design — so that no single procurement failure could halt the line again. The mitigation went into the architecture, not the purchase order.
• Ran EVT, DVT and PVT at hyper speed against the inventory clock, without dropping the qualification gates.

Outcome

The core line kept shipping through the shortage, and came out of it structurally harder to stop.

Role

Product Manager — Connected Cameras, Baby Monitors

Org

CWD · Toronto

Timeline

January 2017 – March 2020

Ownership

$30M portfolio — pricing, budget and P&L as explicit KPIs

Rating

4.75 / 5

The product

Oma Sense is the first breathing baby monitor designed and manufactured in Canada. It's an accelerometer-based wearable that clips to an infant's diaper or clothing and detects breathing motion, for infants 0–6 months, aimed at reducing SIDS risk.

If breathing stops, the device does two things at once: it vibrates to rouse the infant, and it sounds a loud audible alarm to bring the caregiver. Built with medical-grade plastics in an ISO 13485 facility.

The decision that defined it

Newborns do not breathe like adults. They breathe irregularly — they pause for a few seconds and then resume, and that is normal. So the product question was never "can we detect breathing." It was: how long is a pause allowed to last before we wake a sleeping baby and alarm its parents?

• We baselined detection against real infant breathing in field trials, not synthetic signals.
• Then made explicit judgment calls on alarm-trigger thresholds, balancing missed events against false alarms.
• Both directions carry a real cost. A missed event is the reason the product exists. A false alarm at 3am is how the product ends up in a drawer — and a device in a drawer protects no one.

The portfolio around it

• Owned a $30M portfolio across Best Buy, Walmart and Amazon, with pricing, budget and P&L as explicit KPIs.
• Grew annual portfolio revenue by $7M — the mechanism was exiting low-margin, inventory-heavy SKUs and concentrating on high-margin lines, which won retail shelf space. (Revenue attribution is multi-variable; that was the lever I pulled.)
• 10% SoC cost savings through vendor negotiation, and supplier diversification after a partner bankruptcy cut off supply — multi-sourced CMs with lead-time and inventory controls.
• Owned the two-way audio path across the line, held to strict latency, intelligibility and noise specs enforced by incoming QC.