AI-SHIPR - Modes & How They Relate

Start here

Four dials, set independently

The most common confusion is treating configuration as a single switch. It isn't. Team Mode and Product Mode are independent - one is about people, the other about products. Product Stage changes which tools surface. Voice changes how the system talks to you. Set each on its own merits.

Team Mode

team_mode

soloindividuallead

Do you maintain shared context, or read someone else's? People.

Product Mode

product_mode

singlemulti

Do you own one product or several? Products.

Product Stage

product_stage

discoverydefinitionbuildinglaunchediterating

Where is the product in its life? Surfaces the right tools.

Voice

voice · pm_voice

coachdirectgentle

How the system talks - and whether it writes in your style.

The core relationship

Team Mode × Product Mode

These two are the dials people mix up. They form a grid - every cell is valid. Find the cell that matches your reality.

	product_mode: single	product_mode: multi
team_mode: solo	Individual PM, one product The default. Everything lives at the root: `S-Strategy/`, `I-Initiatives/`…	Individual PM, several products One person, multiple related products. Per-product folders + a `shared/` layer.
team_mode: individual	PM in a team, one product Reads the org's `../vp/shared/` first, then your local strategy.	PM in a team, several products Org layer above; per-product strategy below.
team_mode: lead	Team lead, one product Portfolio + team agents on, across one product area.	Team lead, several products Full portfolio view across products and PMs.

Dial 1

Team Mode - about people

soloIndividual PM, no shared org layer

Standard AI-SHIPR. Nothing above you. Your strategy files are the source of truth.

individualYou're a PM inside a team

Your work runs on a shared cloud drive under a VP. The system reads org-level direction before your local files, so your product stays aligned - and any conflict with org OKRs or bets is flagged before you proceed.

Reads first: ../vp/shared/ - Vision, Strategy, OKRs, Strategic-Bets, Portfolio-Roadmap, Constraints.

leadVP / Team Lead

You maintain the shared/ layer other people read. Usually a VP over PMs, but equally a Director over engineering teams with a designer or researcher alongside - it is the reading relationship that decides this dial, not head count (that shape installs differently). Unlocks the portfolio + people layer: the Portfolio-Strategist and Team-Manager agents, plus lead-only skills (Resource-Allocation, Portfolio-Priority-Stack, Org-Design, Team-Health-Check, PM-Performance-Review, Hiring-Brief). /today aggregates across the team.

Reads first: shared/ (your org layer) + ../pm-*/S-Strategy/ (every PM's strategy) + R-Relationships/Team/ (roster, profiles, 1:1 logs).

Special case Player-coach - a VP who also owns a product

Common at smaller orgs: you manage the team and carry one product yourself. Don't try to do both from one instance. Run two - switch hats by which folder you open.

vp/  ·  team_mode: lead

Your VP hat. You write shared/, run the portfolio + team agents, aggregate /today across everyone.

pm-you/  ·  team_mode: individual

Your PM hat. Your product's S-Strategy/ and initiatives - just another pm-* folder.

Why two folders, not one: lead mode already reads ../pm-*/S-Strategy/, so your product appears in the portfolio view automatically - alongside everyone else's, in the same place. Cramming it into vp/ via multi-product mode would scatter products across two locations and confuse the portfolio agents.

The discipline that matters more for you, not less

The system flags when a product's bets drift from the org bets. Normally that check runs between two people. As a player-coach it collapses into one head - so keeping the folders separate is the check. In your PM hat the system reads the shared/ you wrote as VP and flags drift. Treat that flag as a real signal - you're the one most able to quietly bend org strategy toward your own product.

Dial 2

Product Mode - about products

singleOne product

All strategy, initiative, hypothesis, and proof files live at the root level. The default for most setups.

multiTwo or more products with separate strategies

Each product gets its own named folder with a full strategy layer, plus a shared/ layer for what crosses products. /today, /weekly, /sprint, and /review-initiative read each product separately and label the output by product.

Lives in shared/: Portfolio-Roadmap, cross-product Constraints, portfolio Strategic-Bets. Lives per product: that product's Vision, KPIs, and Strategic-Bets.

The decision that trips people up

Related products → product_mode: multi with a shared layer (they share stakeholders or engineering; a decision on one affects the other). Unrelated products → separate vaults entirely (different teams, budgets, no cross-effect). Don't force unrelated products into one structure.

Putting it together

How to pick your two dials

1

Does anyone else read context you maintain? Yes → team_mode: lead. No, but you read a layer someone above you maintains → individual. Neither → solo.

2

Do you own more than one product? No → product_mode: single. Yes and they're connected → multi. Yes but unrelated → separate vaults, not multi.

3

Set them separately. A solo PM can run multi. A team lead can run single. The grid above has no invalid cells.

team_mode: soloproduct_mode: multi

One PM, two connected products. Example: the same person owns a customer app and an editor app that feed each other. Per-product strategy + a shared layer for the engagement goal they share.

team_mode: individualproduct_mode: single

A PM on a larger team, one product. Your strategy ladders up to the VP's shared org layer; conflicts get flagged automatically.

team_mode: leadproduct_mode: multi

A VP over several PMs and products. Full portfolio: aggregate /today, bet-coverage across the org, resource allocation, team health.

Dial 3

Product Stage - surfaces the right tools

Stage is independent of the two above. It changes which agents and skills the system prioritizes and what /today surfaces. Move it as the product moves.

discovery→ definition→ building→ launched→ iterating

discoveryNew product, nothing live yet

No metrics, no validated personas, no sprint history. The system treats every bet and persona as a hypothesis, prioritizes discovery skills (JTBD-Mapper, Persona-Builder, Assumption-Extractor, Hypothesis-Builder, Experiment-Designer…), and suppresses tools that need a live product (Performance-Tracker, Build-Review, Fire-Responder). /today surfaces unvalidated hypotheses, not sprint metrics.

definition → building → launched → iterating

definition: PRD-Builder and Roadmap-Planner lead. building: Sprint-Planner, Build-Companion, Build-Review. launched: all workflows on; Performance-Tracker and Iteration-Planner lead. iterating: acting on data - Iteration-Planner and Experiment-Designer lead.

Why this matters

Set the wrong stage and the system surfaces the wrong tools - e.g. asking for sprint metrics on a product that hasn't shipped. If /today ever feels off, check Product Stage first.

Dial 4

Voice - how the system talks to you

voicecoach · direct · gentle

coach asks questions back and surfaces choices - good in discovery. direct states the recommendation first, short and numbered - good for daily briefs and quick decisions. gentle validates before redirecting and adds context - good for sensitive tradeoffs or stakeholder-facing output.

pm_voiceactive · off

When active, the system writes stakeholder updates, decision logs, and 1:1 agendas in your natural style, reading from R-Relationships/Me/PM-Voice.md. Generate that file once with the /voice skill. voice controls the system's tone; pm_voice controls whose voice the written outputs sound like - two different things.