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 manage other PMs / belong to a shared org? 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 manage PMs. 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
Do you manage other PMs? Yes → team_mode: lead. No, but you're in a team under a VP → 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.
Verve-PM
← All Resources