Read time: ~6 minutes · Series: Product Manager advanced · Previous: Memory governance · Next: Elevator pitch
The five-step method at a glance
1. Pick a scenario → 2. Run one round end to end → 3. Set the rules → 4. Expand roles → 5. Decide what to distill into Memory / BI
The goal isn't "everyone live on Day 1," but to use one real small project to prove that Plan → Execute → Report is less stressful than delivering over chat.
Step 1: Pick the right pilot
Traits of a good pilot:
- A KPI whose definition was recently disputed or that someone kept probing
- Data in local CSV / Excel or with a lightweight connection already in place
- Something an analyst can deliver as a first Report within 1–2 weeks
- Something the PM can join for at least one Plan annotation
Avoid: starting with your most complex warehouse model, or a trivial demo table—a demo can only teach the buttons, not "why you need to Execute."
Step 2: Run one round end to end (acceptance criteria)
Have the analyst (with you observing) complete:
- Create the project and focus it
- Natural-language request → Plan
- You leave one Plan annotation and confirm the Agent only changes the referenced section
- The analyst Executes (you confirm the Agent didn't run ahead)
- Produce a Report: with numbers + limitations
- (Optional) Export to HTML and try attaching it to a mock weekly meeting
Cross-reference Product Manager introduction · Trial adoption and USER_GUIDE §2.
A sign the pilot succeeded: the weekly-meeting debate shifts from "the AI said so" to "the denominator definition in the Plan's third paragraph."
If the pilot includes an external Agent
Break the permission expansion into three acceptance-testable steps:
- First use, or a low-trust evaluation: Observe—just confirm it can see the correct workspace and artifacts, and doesn't affect the built-in Agent.
- Formal analysis: Single workspace + Execute—lock down the data boundary, then accept the work through the same Plan → Approve & Execute → Report flow.
- Only use Admin in a trusted environment-management context, and afterward review the artifacts, External MCP Activity, and audit.
The Create connection screen currently defaults to All workspaces + Admin; that's just a UI default, not a pilot recommendation. Leave platform configuration and revocation drills to the Platform Admin role—see External Agent Integration.
Step 3: Set three team rules
A recommended minimal set (you can trim it from The quality bar):
- External numbers must come from an Executed Report
- Someone must review the Plan before Execute (the role can be designated)
- Quick results are labeled "unofficial"
Write it into the wiki—don't just say it verbally.
Step 4: Expand roles
| Stage | Who joins | What they do | Reading to forward |
|---|---|---|---|
| Pilot | Analyst + PM | Run one project end to end | Analyst introduction · PM introduction |
| Second wave | Business / Operations | Annotate the Plan, read the Report | Business & Operations onboarding · Quick vs formal numbers |
| Once stable | Engineering | Data sources, external Agents, connections and backups (if needed) | Platform Admin introduction · External Agent Integration |
At this stage the PM mainly blocks two kinds of rush:
- Skipping the Plan and demanding the Report
- Everyone enabling Memory at once without reviewing Apply
Step 5: Distillation and boundaries
Decide after the pilot ends:
- Which definitions to Apply to Project Knowledge
- Which metrics to distill into BI (Lantide does adhoc, BI does monitoring)
- Which scenarios can still just use Quick
There's no mandatory "migrate everything" question—only which workflow was proven to cause fewer disputes.