---
title: Ops Training
route: /ops-training
lang: en
part_of: Onirion
version: "4.0"
date: 2026-09-22
author: Alexis Boyer
license: CC BY 4.0
one_line: The training helps the teams that enable Product Builders make their shared services usable.
layers:
  summary: /ops-training
  complete_text: /complete.md
  markdown: /ops-training.md
---

# Ops Training

The training helps the teams that enable Product Builders make their shared services usable.

## Format and price

From €4,500 excl. VAT per group

Two days (14 hours), in English or French, up to eight participants

Includes a 60–90 minute preparation call and a 90-minute follow-up two to three weeks later

Book a training: lcnlechevaliernoir@gmail.com

or write to lcnlechevaliernoir@gmail.com

**The central question**

Can a Product Builder start a real initiative using the organization's conventions, components, APIs, access, and review paths, without rebuilding the foundations or waiting for an unnamed owner?

**Who it is for**

Design Ops, Frontend Ops, Backend/API Ops, Data Ops, and the access, delivery, observability, and review owners whose services a Product Builder depends on.

**What it is not**

It is not a guided exercise in Claude Design or in coding one feature.

*Figure — image slot, 3:2: A workshop table with the first enablement pack laid out, printed one sheet per capability, being marked up. No image supplied.*

## What each capability puts in place

Same order as the horizontal row on The Principle, so the row you recognize there is the row you land on here.

| Capability | Working assets for Product Builders |
| --- | --- |
| Design Ops | Reviewed patterns and components, interaction and state guidance, a design-review route, and a clear way to preserve the accepted design for implementation. |
| Frontend Ops | An approved, maintained starter repository or equivalent setup with a known version, owner, and clone-and-start instructions, plus conventions for structure, components, state, routing, accessibility, localization, testing, and integration. |
| Backend and API Ops | Reference patterns for authentication, permissions, migrations, and tests; discoverable API contracts with their business meaning; versioning, error conventions, test environments, and a route to request or build a missing API. |
| Data Ops | Clear definitions and event contracts, appropriate test data, access and quality rules, and a way to answer a concrete learning question. |
| Access and delivery | A named owner and response target for appropriately scoped access; protected branches, required checks, named environments, and proof of which revision is running. |
| Observability and review | Read-only access to useful logs, errors, and integration health; a diagnostic and incident route; and a dependable technical review path with a named owner. |

## When something is missing

1. **The Product Builder sends a bounded request** — Context, constraints, a response target, and an acceptance check.
2. **The Ops owner decides** — Extend the shared service, or grant an exception.
3. **Both sides verify the result** — In the integrated product, not in the document.

## How the training runs

Two days, 14 hours, in English or French, for up to eight participants from the Ops teams, with at least one Product Builder and a sponsor who can resolve ownership questions.

1. **Preparation** — A 60–90 minute call to choose one real Product Builder journey, gather the existing guidance, and identify the Ops owners who can decide during the workshop.
2. **Day 1 — see the work from the Product Builder's side** — Follow how a Product Builder would start that initiative, test whether each service is operational rather than only documented, and define the minimum service each team must offer.
3. **Day 2 — build the first enablement pack** — Each team drafts its first usable contribution, agrees how missing capabilities are requested and verified, and has a Product Builder walk through the pack and mark what is usable, unclear, or blocked.
4. **Follow-up review** — A 90-minute review two to three weeks later, to check whether a Product Builder could use the first assets on a real initiative.

## What the group leaves with

A Product Builder enablement pack, version 0

1. A map of the chosen journey and its current blockers.
2. Named owners and a small catalog of the shared services that journey needs.
3. Draft frontend and backend/API conventions, with the approved starter repository or a named plan to build one.
4. An API and access map: what exists, who owns it, how to get scoped access, and what is missing.
5. Design and data guidance where that journey needs it.
6. A readiness check for required checks, deployable branches, environments, running-revision evidence, diagnostics, and technical review.
7. A request-and-response contract between Product Builders and Ops owners, with response times, acceptance evidence, and escalation.
8. A 30/60/90-day plan with accountable owners.

## The free kit stays complete.

Nothing a Product Builder needs for a first run is reserved for the training.

The workshop produces an initial pack and a prioritized plan. Writing a full production convention set, building new APIs, provisioning access, and platform changes are further work by the responsible teams.

Book a training: lcnlechevaliernoir@gmail.com