AI-SHIPR - When Your Reports Are Not PMs

01

Three tests, all of them yes

This is one of the most common product org shapes and the one the setup worksheet handles worst. If all three of these are true, this page is your install guide.

1

You are a Director of Product, Group PM, or Head of Product, and you own product work yourself rather than only overseeing it.

2

The teams under you are engineering teams, not product managers. You may have three squads and still be the only PM in the group.

3

At least one non-PM collaborator works across your surface and needs the same context you have. A designer, a researcher, a data analyst, a product marketer.

02

The worksheet will point you the wrong way

Question 2 of the Setup Worksheet defines Team lead as "VP or Head of Product managing other PMs". You manage none, so the honest answer is Solo PM. That answer is wrong, and it fails twice: it produces no shared layer for your collaborator to read, and solo paired with multiple products is not yet a supported path in the guided setup wizard. You land on a dead end.

The dial is misnamed, not miswired. What team_mode: lead actually controls is whether your instance writes a shared/ folder that other instances read at the start of every session. Head count has nothing to do with it.

The real test

Does anyone else need to read context that you maintain?

Yes, and you are the one who maintains it. Pick lead, whether you manage twelve PMs, three engineering teams, or nobody at all.

03

What each person sets

Person	Folder	team_mode	What it does
You, lead hat	`vp/`	lead	Writes the six org files in `shared/`. Runs the portfolio view across everyone's strategy.
You, IC hat	`pm-<you>/`	individual	Your actual product work. Personas, hypotheses, initiatives, proof.
Designer, researcher, analyst	`pm-<name>/`	individual	Reads your `shared/` before their own files, every session. Owns their own craft layer.

The rule that saves you a rebuild

You are a player-coach, so run two instances

Lead mode deliberately skips Part 6 of the worksheet, because in a normal VP setup personas belong to the PM who owns the product. In your setup you are also that PM. Run one folder and nobody ever writes a persona, which quietly starves every discovery skill in the system.

Switch hats by opening a different folder. It costs one extra install and it is the difference between a system that works and one that looks populated while returning generic answers.

vp/ · team_mode: lead

Your director hat. You write shared/, run the portfolio and team agents, and see /today aggregated across everyone.

pm-<you>/ · team_mode: individual

Your IC hat. Your personas, hypotheses and initiatives. Just another pm-* folder, so it shows up in your own portfolio view automatically.

The shape on disk

One shared drive, one folder per hat

AI-SHIPR-ORG/ ← the shared drive root ├── vp/ ← your director hat │ └── shared/ ← Vision · Strategy · OKRs · Bets · Roadmap · Constraints ├── pm-you/ ← your IC hat └── pm-collaborator/ ← designer, researcher, analyst

Every folder is a complete AI-SHIPR install. The only things that differ are Settings.md and who is allowed to write where.

The one rule

Only the lead writes shared/. Everyone else reads it and writes only inside their own folder. Set it read-only at the drive level so the rule is enforced rather than remembered. On Google Drive and SharePoint that is the whole conflict story. Sync-Context is a mirror-refresher for Confluence and Notion, which have no file path, and is not needed on a file-system drive.

01

Count products, not teams

The instinct is to map one engineering team to one product folder. Resist it. Engineering teams are capacity, not products. Three squads shipping one experience is one product with three delivery streams, and splitting it gives you three half-empty strategy layers and an argument about which folder every initiative belongs in.

The test

A surface earns its own product folder when it has its own north star metric and its own list of strategic bets. Both, not either. That is exactly what a product folder holds: a separate Vision, KPIs and Strategic-Bets layer.

The usual answer

Two platform teams building one experience, say a mobile team and a web team, share one north star and one bet list. One product.

A team with a genuinely different value proposition, its own adoption metric and its own bets, say an applied AI surface next to the core app, passes the test. That is where product_mode: multi earns its keep.

If they are unrelated

Different users, different budget, no decision on one affecting the other? Those are separate vaults, not multi mode. Do not force unrelated products into one structure.

01

Same install, different parts filled

A designer or researcher gets the identical framework. What changes is which parts of the worksheet they answer, because strategy comes down from the shared layer rather than being authored locally.

Worksheet part	Lead	Non-PM collaborator
1 · Products	Yes, portfolio altitude	Yes, the surface they work on
2 · Strategy	Yes, org bets and metrics	Skip, they read it from `shared/`
3 · Constraints	Yes, org level	Skip, unless their craft has its own
4 · Your role	Yes, as the lead	Yes, and it cannot be delegated
5 · Stakeholders	Yes, exec and cross-team	Yes, the people they align with
6 · Users	Skip	Yes, and go deepest here
7 · Portfolio	Yes if multi	Skip
8 · Team	Yes	Skip
9 · Tools	Yes, the org stack	Yes, where theirs differ

02

Part 6 is where a designer earns the instance

Keep PM-Profile.md, change what goes in it

The filename says PM, the questions do not. Biggest challenge right now, where your time actually goes, what you optimise for, where you want AI leverage. Those are role-agnostic, and every agent reads this file before responding. Do not delete it and do not let someone else answer it for you.

The craft layer lives in I-Information/

A design system, a component library, a research repository, a content style guide. Point Claude at Figma, or at the public site if no formal system exists yet, and have it write the library into I-Information/. From then on every prototype and mockup comes out already on-brand.

Personas are the highest-value answer they give

A persona written by the person who runs the sessions is a different artifact from one written two levels up. If the collaborator fills nothing else properly, Part 6 still has to be theirs.

Non-negotiable

One worksheet per person. Each person answers about their own scope, and nobody answers on behalf of anyone else. Install one person's answers on three machines and all three instances behave as though they are that person: confident, specific, and wrong about two of the three.

The order is not a preference. A collaborator who fills their worksheet before the shared layer exists produces strategy that has to be reconciled against it afterwards, and reconciliation after the fact is a rewrite rather than a review.

1

Lead · before anyone installs

Pick the shared surface and get access approved An organisation-owned Google Shared Drive or SharePoint Team Site, never personal storage, because the path has to be identical on every machine. If your team also runs Confluence, run the system on the drive and publish only finished artifacts, a signed-off PRD, into the wiki.

2

Lead · 30 minutes

Run the setup wizard as Team lead Answer Question 2 as Team lead, not Solo PM. Add one row for yourself and one row per collaborator. Each row becomes a ready-made pm-<name> folder in your download, already wired to read your org layer.

3

Lead · 30 minutes

Install, populate, review Move AI-SHIPR-ORG/ somewhere permanent, run bash setup.sh in vp/, then run Populate-Strategy on your worksheet. Review everything it wrote. Anything marked [Missing] gets filled or deleted, never left as-is. Then run Structural-Integrity-Auditor on the strategy layer.

4

Lead · 10 minutes

Publish the org layer and set permissions shared/ goes read-only for everyone but you. This is the step that makes the conflict question disappear.

5

Each collaborator · 45 minutes

Read the org layer first, then fill your own worksheet Ten minutes actually reading ../vp/shared/ before you answer anything. This is the step that gets skipped and it is the one that makes the rest worth doing. Then Populate-Strategy, then review.

6

Everyone · one to two weeks

Soak on real work before adding anyone else Use it on live decisions, not test prompts. Tune the agents and skills to how your team actually works. The next group should arrive at something already shaped, not at an empty framework.

7

Everyone · quarterly, or when the bets change

Reconcile upward Collaborators publish their personas and bets back to the shared surface. The lead looks for the same constraint appearing twice, the same stakeholder defined two ways, and the same word meaning two different things. That last one is the highest-value output of the whole install.

The framework was written for a VP over a team of PMs. In this shape a few labels read oddly. None of them break anything, and knowing them in advance stops you second-guessing a correct setup.

What you will see	What to do
Question 2 defines Team lead as "managing other PMs"	Pick it anyway. The dial controls whether you write a shared layer, not head count.
Part 8 asks "which PM needs the most support" and "what bet would the new PM own"	Read "PM" as "the person or team who owns that bet". Your answers are about squads and collaborators, and they are still the right answers.
The wizard's team step is headed "Your PMs" and wants a bet per row	Add your collaborators as rows regardless. For a designer, name the bet they support rather than one they own.
Solo PM plus multiple products has no guided flow yet	You will not need it. This shape resolves to `lead`, which is fully supported.
Files named `PM-Profile.md` and `PM-Voice.md` in a designer's folder	Keep both. The questions inside are role-agnostic and the agents read them before every response.

One more tier

If your own VP sets AI-SHIPR up later, you have three tiers and the framework models two. Your shared/ is a group layer, not a company layer. When that day comes, the cleanest move is to keep your group layer where it is and have it read theirs, rather than collapsing two levels into one folder.