Team Rollout: Who Fills What

Populate-Strategy converts a worksheet into that person's files. One of them is literally R-Relationships/Me/PM-Profile.md - "Me". It holds their biggest challenge, where their time actually goes, and the two things they optimise for. Every agent in the system reads it before responding.

If one person's answers are installed on five machines, all five instances believe they are that person. The agents then optimise for one person's challenge, one person's time split and one person's operating preference - for five different PMs working on four different products. The output is confident and wrong, which is the worst failure mode a shared system has.

The Setup Worksheet is one document with 8 parts. Both roles use the same file. They answer different parts - and answer the shared parts at different altitudes.

A persona written by the person who does the customer calls is different from one written two levels up. If a PM fills nothing else properly, this part still has to be theirs.

"What is your biggest challenge right now" and "where do you want AI leverage" are the questions that tune the whole system to one person. Answered by someone else, they tune it to the wrong person.

The VP's worksheet produces two different things, and they go to two different places.

Their own instance - the same files any PM gets, scoped to their portfolio view, plus R-Relationships/Team/Roster.md from Part 8.

The org layer - the six files every PM's session reads before anything else.

The VP first, PMs second, reconcile upward third, then steady state. The third phase is the one teams skip, and it is the one that pays for the whole exercise.

• 1
  Get access approved Shared drive, wiki space, or connector - whichever the team is using. In a regulated org, security review of a new tool is the long pole and everything else waits behind it if it starts late.
• 2
  Create the runtime repo One repo holding the AI-SHIPR runtime plus the shared templates, so every machine installs the same thing and template changes get reviewed rather than appearing overnight.
• 3
  Pick the pilot Two or three PMs, not the whole department. A rollout that stalls at five machines is harder to restart than one that succeeded at three.

60–90 minutes. Nobody else installs anything until this is done.

• 1
  Fill the Setup WorksheetTheir own scope, per the table in section 1.02.
• 2
  Run Populate-StrategyIt writes all six org files. Then refine shared/OKRs.md with OKR-Partner, per section 1.03.
• 3
  Review every generated fileAnything marked [Missing - add manually] gets filled or explicitly deleted. A blank org file is better than a plausible invented one, because the invented one gets trusted.
• 4
  Publish the org layerInto the shared surface, read-only for the team.

About 60 minutes each. Individually - different rooms or different slots.

• 1
  InstallClone the repo, extract AI-SHIPR into their own folder, run bash setup.sh once.
• 2
  Connect to the org layerMount the shared drive, or run the sync if the shared surface is a wiki. Confirm team_mode: individual in Settings.md.
• 3
  Read the org layerTen minutes, actually reading it. This is the step that gets skipped, and it is the one that makes step 4 worth anything.
• 4
  Fill their own Setup WorksheetParts 1–6. Then run Populate-Strategy and review the output.
• 5
  AuditRun Structural-Integrity-Auditor on S-Strategy/ before doing any real work in the system.

An org layer written alone in one sitting is a hypothesis about what the team is doing. The PM files are the evidence. This phase is where the hypothesis gets corrected, and it is not optional.

Prerequisite: each PM publishes their Vision, Strategic Bets and Personas up to the shared surface. The VP has no access to anyone's machine, so this is how the evidence reaches them. A copy-paste, once per reconciliation, not a continuous sync.

The VP changes org context and says so. Everyone re-reads or re-syncs. Once the rhythm holds, that refresh moves to session start automatically.

Re-run Phase 3 quarterly, or whenever the bets change.

The obvious way to organise a shared workspace is one page per PM with their products underneath. It is how a team thinks about itself, and it is wrong, because it assumes the person outlasts the product. In practice it is the other way round.

Person-keyed pages give the middle row the wrong lifetime. When a PM leaves, years of product reasoning is sitting inside a page named after someone who no longer works there.

Reallocation breaks it before departure does. A PM owning two products is normal. The day one of them moves to a colleague, a page named after a person has to be surgically split and every inbound link rechecked. Keyed by product, that same reorg is one property change on one page. Reorgs are far more common than resignations, so this is the case that bites first.

• 1
  Move the Owner propertyFrom the departing PM to the new one, and add the old owner to Previous owners.
• 2
  Blank Last reviewedNot "today". The new owner has not reviewed it yet, and pretending otherwise is how stale context gets trusted.
• 3
  Move edit accessGrant the new PM, remove the old one. If permissions follow Owner, step 1 already did this.
• 4
  Archive the person-scoped pages1:1 notes and PM profile. Do not pass them to the successor.

• 5
  Fresh installClone, bash setup.sh, connect to the org layer.
• 6
  Copy in the product foldersPer the transfer table above.
• 7
  Delete R-Relationships/Me/ and rewrite itThe single most important step, and the one that gets skipped - because the folder looks populated and harmless while it quietly tunes every agent to somebody else.
• 8
  Fill Parts 4 and 5 onlyThen run Populate-Strategy scoped to those parts.

If a PM leaves and there is no replacement for two months, the Owner field sits empty and the context quietly rots. Two guards:

• 1
  Flag empty Owner, not only stale datesWhatever check you run for stale context should treat an unowned page as the louder of the two problems.
• 2
  The VP takes Owner in the interimCaretaker ownership beats no ownership, and it puts the gap on someone's list rather than nobody's.

• Access to the shared surface approved
• Setup Worksheet filled for their own scope - Parts 1–5, 7, 8
• Populate-Strategy run, output reviewed, [Missing] markers resolved
• All six shared/ files generated and reviewed, with OKRs.md refined through OKR-Partner
• Org layer published, read-only for the team
• Product pages created - one per product, with Owner set
• team_mode: lead set in Settings.md

• Installed, bash setup.sh run once
• Connected to the org layer, vp/shared/ populated
• Org layer actually read
• team_mode: individual confirmed in Settings.md
• Own Setup Worksheet filled - Parts 1–6
• Populate-Strategy run, output reviewed
• Structural-Integrity-Auditor run on S-Strategy/

• Each PM has published Vision, Strategic Bets and Personas to the product page they own
• Bets laddered: every PM bet maps to an org bet, or the gap is named
• Repeated constraints moved up to shared/Constraints.md
• Shared stakeholders moved up to shared/Stakeholders.md
• Personas de-duplicated into one definition each
• Conflicting terms collected into the shared glossary
• Org layer updated, everyone re-synced