AI Product Builder & Leader

How I Build

I turn ambiguous, high-consequence problems into products that can be tested, adopted, and improved.

I move from evidence to a focused bet, then through architecture, design, delivery, adoption, and operation. AI accelerates the work; people remain accountable for the decisions and what we learn next.

The product learning loop

Eight stages, one learning loop

Product work rarely moves in a straight line, but teams still need a shared way through it. This loop connects discovery to operation so evidence shapes the bet, each build teaches us something real, and what happens in use improves the next cycle.

How I build intelligent products, inspired teams, and accountable outcomes

Produces: AI products · value delivery systems · teams that execute and scale

StartAmbiguous problem
DiscoverThe evidence
FrameThe problem
PrioritizeThe gambit
ArchitectThe system
DesignThe interface
DeliverBuild · evaluate · deploy
AdoptInto use
OperateThe cadence
EndA system that runs

AI-native · Responsibly governed · Outcome-oriented

Return loop: operating evidence returns to discovery through continuous development of people, improvement of process, and delivery of technology.

Built on: 16+ years · Canadian Army · KPMG management consulting · early-stage venture product and technology leadership

Discover

what matters

How I shape the work: I bring the team close to the people, the problem, and the evidence before we reach for a feature.
How AI helps: AI helps us organize authorized research, compare signals, and notice patterns or contradictions we may want to explore.
What the team owns: The team decides which questions matter, whose experience is represented, what evidence is relevant, and when we know enough to move.
What good looks like: We can explain the problem signals, the gaps in our understanding, and what we know, infer, or still need to learn.
How we protect trust: We respect consent and source boundaries, and we keep sensitive material out of anything intended for reuse or public view.
What we learn next: What happens in delivery and use comes back as new discovery, especially when adoption is hard or an assumption proves wrong.

Frame

the right problem

How I shape the work: I help the team refine the problem before the solution and connect it to an outcome we can genuinely own.
How AI helps: AI gives us a fast way to compare interpretations, pressure-test assumptions, and make different points of view easier to discuss.
What the team owns: The team chooses the user, outcome, constraints, boundaries, and level of uncertainty we are prepared to carry.
What good looks like: We have a clear problem statement, explicit assumptions, meaningful constraints, and a point at which we will stop or reframe.
How we protect trust: Fluent output never gets to masquerade as evidence or quietly expand the problem beyond what the team agreed to solve.
What we learn next: If real use tells us we framed the wrong problem, we return here without treating that learning as failure.

Prioritize

the bet worth making

How I shape the work: I make the choices and trade-offs visible so the team can focus its energy on the bet with the strongest reason to exist.
How AI helps: AI helps us structure options and compare the evidence behind them; it does not choose the bet for us.
What the team owns: The team owns the investment, sequencing, resources, trade-offs, and the decision to stop.
What good looks like: We can name the chosen bet, the alternatives we left behind, why we made the trade, and what evidence we need next.
How we protect trust: Targets and hypotheses stay labelled as targets and hypotheses until real evidence changes their status.
What we learn next: New delivery or operating evidence can change the expected value of the bet and send us back to reprioritize.

Architect

the smallest system that can teach us

How I shape the work: I help the team make the idea feasible, understandable, and small enough to test through a real boundary.
How AI helps: AI helps us compare design options and surface questions that need stronger evidence or specialist judgment.
What the team owns: The team decides the boundaries, data, decision rights, failure posture, and operating cost it is willing to accept.
What good looks like: We have one testable slice, clear responsibilities, a reversible path, and a shared understanding of how it can fail.
How we protect trust: We can share the principles and trade-offs without exposing private or reusable system detail.
What we learn next: We change the architecture when testing or real operation shows that one of its premises no longer holds.

Design

the experience people can trust

How I shape the work: I keep the team focused on whether the change is useful, usable, and honest about what the system can and cannot do.
How AI helps: AI helps us explore alternatives and make reasoning visible while the team tests the experience with people.
What the team owns: The team owns the understanding of the user, the interaction, accessibility, confirmation points, and consequential decisions.
What good looks like: People can use the experience as intended, understand its states and limits, and know when their judgment is required.
How we protect trust: Recommendations remain separate from decisions, with a deliberate pause before consequential work moves forward.
What we learn next: Confusion or hesitation is evidence about the product, not a reason to blame the person using it.

Deliver

a real slice into real use

How I shape the work: I help the team ship one bounded slice through the real delivery path, learn from it, and resist expanding the scope mid-flight.
How AI helps: AI accelerates drafting and building while we keep scope, review, evidence, and handoffs visible.
What the team owns: The team approves scope changes, evaluates the evidence, accepts trade-offs, and decides whether the work is ready to release.
What good looks like: Checks have run, defects have been repaired, the real environment has been observed, and someone accountable has made the release decision.
How we protect trust: Finishing the build does not quietly grant permission to release it, broaden it, or put it into action.
What we learn next: When something fails, we trace it back to the earliest assumption that no longer holds and improve from there.

Adopt

the change into the work

How I shape the work: I treat adoption as part of the product, helping the team fit the change into real work and make ownership clear.
How AI helps: AI reduces preparation and friction inside a human-owned workflow; it does not force people into an autonomous operating model they did not choose.
What the team owns: The team decides how the product enters the work, who owns each decision, what support is needed, and when adoption should stop.
What good looks like: We see real use, better workflow fit, sound decisions, understood support needs, and clear ownership after handoff.
How we protect trust: Availability is not adoption, and activity alone is not evidence of impact.
What we learn next: Adoption friction may change the interface, the product bet, the operating model, or even the original problem.

Operate

the rhythm of learning

How I shape the work: I create a visible rhythm around outcomes, standards, learning, and ownership so the team can improve without waiting for a crisis.
How AI helps: AI helps organize operating signals and prepare options while people remain accountable for every decision and change.
What the team owns: The team owns production decisions, exceptions, learning priorities, and whether the product should continue, change, or retire.
What good looks like: The team can see performance, user and team feedback, incidents, decisions, and evidence that the product is sustaining value.
How we protect trust: We only call a control real when we have seen it run, and we keep uncomfortable evidence in the conversation.
What we learn next: Everything we learn in operation returns to discovery and starts the next cycle with better questions.

Close-up on Deliver

Build, evaluate, deploy—inside a governed agent loop

Deliver is where a product bet becomes a candidate change. I begin with a tight build, evaluate, and deploy loop, then decompose it into an agent harness that keeps scope, evidence, checks, and human release authority visible.

My agentic operating system

Three systems that keep AI useful—and judgment visible

The product loop describes how the work moves. These systems make it usable in practice: they keep context and decision rights visible, separate reusable knowledge from inquiry-specific evidence, and protect the space where people build judgment. Each view combines the workflow with a public-safe system map so the technology, AI contribution, inputs, outputs, and human review are easy to see without exposing reusable private mechanics.

01 · Context and orchestration

Make the work clear before AI accelerates it

The problem: The faster AI makes the work, the easier it is to lose sight of the objective, the evidence, and who owns the call.
My judgment: Before execution starts, I make the objective, sources, checks, rationale, and decision rights visible to the team.
What I traded: This asks for more thought up front. It gives the team a clear view of what the system knows, why it chose a route, and where a person must decide.
Outcomes: A working local beta supports my product work today. The broader control plane remains in development.

Workflow + L0 system view Working local beta · exact tools and private controls omitted

Human gate Agentic or AI-assisted Application or service Data and evidence

Inputs Objective, sources, constraints Authorized context enters deliberately.
Front end Local review workspace Set intent, choose scope, inspect what is included. Application · working
Middleware Bounded workflow controller Packages context, runs checks, and routes allowed capabilities. Agentic within bounds
AI + data services Model serviceAssists analysis and preparation. Local SQL storePackages, evaluations, and receipts.
Human review Inspect and approve Review scope, checks, rationale, and the proposed handoff. Decision gate
Outputs Reviewable work package Evidence receipt included; handoff does not imply execution.

System boundary. The agentic portion prepares and routes work inside an approved scope. A person owns the consequential decision and any later execution.

The principle. Make the work easier to understand before making it faster to execute. Why I made these calls

Show what is in and what is out. The operator sees the chosen context and the omissions before work is packaged.

Explain the route. The team can inspect why a capability fits instead of accepting an invisible system choice.

Keep action separate from preparation. A reviewed handoff means the work is ready for a decision; it does not make the decision itself.

02 · Knowledge and research

Keep reusable knowledge useful without losing the research thread

The problem: Reusable knowledge helps future work. Research evidence answers one specific question. Blending them weakens both.
My judgment: I give each one a clear home: a reusable local knowledge base and a research record that preserves every question, method, source, and claim.
What I traded: Two clearer systems, joined only when useful, instead of one convenient workspace where provenance becomes hard to see.
Outcomes: The reusable-knowledge slice works locally. The inquiry-specific system and the connection between them remain designed, not built.

Workflow + L0 system view Mixed maturity · reusable knowledge works locally; research remains designed

Human gate AI-assisted Application or service Data and evidence

Inputs Owned sources + research question The library and the inquiry begin with different authority.
Front ends Two local workspaces Knowledge viewer works locally; research workspace is designed. Application · mixed maturity
Application services Retrieval + research lifecycle One returns bounded context; one preserves method, evidence, and claims. Deterministic boundaries
AI + data services Model-assisted synthesisUseful context, never the evidence record. Documents + search indexWorking, versioned knowledge source. Local SQL research recordDesigned system of record.
Human review Source, method, and claim review A person decides what belongs, what counts, and what can be said. Authority retained
Outputs Reusable context + defensible research Connected when useful, but never merged into one source of truth.

Proposed seam. Reusable knowledge may provide read-only context to the research workflow. It does not own the question, methods, evidence, claims, or final writing.

The principle. Let past knowledge inform the inquiry without allowing it to quietly become the evidence for the inquiry. Why I made these calls

Give each system one truth to own. Reusable knowledge serves future work; the research record owns the current question and its evidence.

Keep the thread visible. Sources and reasoning remain inspectable, so retrieved context cannot quietly become an unsupported claim.

Be plain about maturity. One slice works locally; the second system and the connection remain design work.

03 · Learning and development

Protect the space where judgment grows

The problem: AI can help people build faster than they can explain what they are learning.
My judgment: I give people protected side-project space where rebuilding, reflection, and explanation are part of the work.
What I traded: It trades some immediate speed for deeper technical judgment. This is a learning practice, not a testing or evaluation framework.
Outcomes: No user outcome is claimed. The next proof is an end-to-end dogfood build with the learner confirming what changed in their understanding.

Workflow + L0 system view In development · AI-assisted learning, not automated assessment

Human gate AI-assisted Application or service Data and evidence

Inputs Problem, learning goal, existing code The learner names what they want to build and understand.
Front end Project + reflection workspace Intent, architecture choices, builds, and explanations stay together. Application · designed
Workflow service Build-and-reflect sequence Problem → intent → walking skeleton → architecture → build → ship. Deliberate · not agentic
AI + project data AI coding assistantQuestions, drafts, and explanations support the build. Project files + learning recordFile-backed; no shared product database at this maturity.
Human review Explain, rebuild, approve The learner and mentor confirm understanding before carrying it forward. Reflection gate
Outputs Shipped side project + confirmed learning What changed in the learner’s judgment shapes the next build.

System boundary. AI supports coding and explanation. It does not assess the learner, decide readiness, or release the work.

The principle. Use AI to expand what a person can attempt while protecting the practice that helps them understand what they built. Why I made these calls

Make growth developmental, not remedial. The space invites experimentation without turning learning into a deficit label.

Ask for explanation, not just completion. The learner shows what changed in their reasoning and carries it into the next build.

Keep maturity honest. The workflow is intentional, but the product remains in development and no user outcome is claimed.

Explore further

How I Build

See what I build, how I lead, and who I am.