Use this when a product leader has become the bottleneck for clarity -- the person who manually assembles the picture of what's happening across tools, channels, and conversations. This skill designs the operating model that makes product visibility structural, not personal. It bridges the gap between diagnosing product ops problems and actually designing the solution.
Related skills: Run
/product-ops-assessmentfirst if you need to diagnose maturity. Uses/information-architecturepatterns for content organization. Feeds into/metrics-dashboardfor the data/metrics layer. Pairs with/observability-planfor product analytics visibility.
Process
Step 1: Map where product information lives today
Ask the user to describe:
- Tools in use -- where does product work happen? (e.g., Linear, Jira, Notion, Confluence, Slack, Google Docs, Figma, spreadsheets)
- Team size and shape -- how many PMs, engineers, designers? How many squads or streams?
- Current pain -- what specific visibility problems exist? (e.g., "leadership asks me for status every week," "decisions get lost in Slack," "nobody knows what research has been done")
- Audiences -- who needs visibility and what kind? (product team, engineering, leadership, wider stakeholders, customers)
Step 2: Audit information flows
Map each type of product information to where it currently lives and how it moves. Fill this in two passes: first capture where things live and how people get them now (the reality), then assess failure modes (the diagnosis).
| Information Type | Where It Lives Today | Who Creates It | Who Needs It | How They Get It Now |
|---|---|---|---|---|
| Active priorities / roadmap | ||||
| Delivery status (what's in progress) | ||||
| Decisions made | ||||
| Research and learnings | ||||
| Risks and blockers | ||||
| Metrics and outcomes | ||||
| Customer feedback |
For each row, note the failure mode:
- Scattered -- exists in multiple places, no single source of truth
- Tribal -- lives in someone's head or private notes
- Stale -- exists somewhere but isn't maintained
- Push-dependent -- only surfaces when someone manually shares it
- Missing -- not captured at all
Step 3: Define visibility needs by audience
For each audience, define what "good visibility" looks like:
Product team needs:
- What am I working on and why it matters
- What's blocked and who can unblock it
- What we've learned recently that changes our plan
Leadership needs:
- Are we on track against commitments?
- What are the top risks?
- What decisions need their input?
Wider stakeholders (sales, marketing, support, etc.) need:
- What's changing and when
- What's coming that affects their work
- Where to go for details without interrupting the product team
Clients or external partners (if applicable -- common in consulting, services, or agency contexts):
- What's been delivered and what's coming
- Where decisions stand and what needs their input
- A view they can check without scheduling a meeting
Step 4: Design the operating model
For each information type, recommend:
- Single source of truth -- where it should live (one place only)
- Update cadence -- how often it gets refreshed and by whom
- Push vs pull -- what gets pushed (announcements, alerts) vs what's available on demand
- Audience routing -- who sees what level of detail
Design principles:
- Visibility should be a byproduct of work, not extra work
- Default to transparent; restrict only when there's a reason
- Fewer tools, deeper integration beats more tools
- If it requires a human to manually assemble the picture, it will break
- Start with the most painful gap, not the most elegant solution
Step 5: Spec the command centre view
Design a single-page "command centre" -- the one place anyone can go to understand what's happening in product right now:
## Product Command Centre -- {{Team/Product Name}}
### Purpose
One place to answer: What are we doing? Are we on track? What needs attention?
### Layout
**Section 1: Current Priorities** (what and why)
- Source: {{tool}}
- Update cadence: {{frequency}}
- Owner: {{role}}
**Section 2: Active Work** (status of in-flight work)
- Source: {{tool}}
- Update cadence: {{frequency}}
- Owner: {{role}}
**Section 3: Decisions Log** (recent decisions with context)
- Source: {{tool}}
- Update cadence: {{frequency}}
- Owner: {{role}}
**Section 4: Latest Learnings** (research, experiments, customer feedback)
- Source: {{tool}}
- Update cadence: {{frequency}}
- Owner: {{role}}
**Section 5: Needs Attention** (blockers, risks, decisions pending)
- Source: {{tool}}
- Update cadence: {{frequency}}
- Owner: {{role}}
### Operating Rhythm
- **Daily:** {{what updates automatically vs manually}}
- **Weekly:** {{what gets reviewed, by whom}}
- **Monthly:** {{what gets refreshed or archived}}
### Implementation Path
1. {{First thing to set up -- usually the most painful gap}}
2. {{Second}}
3. {{Third}}
- Estimated setup effort: {{light/medium/heavy}}
- Maintenance cost: {{minutes per week once running}}
Step 6: Review and prioritize
Present the full design. Ask:
- Does this match how your team actually works?
- Which section would have the most impact if we built it first?
- What's the appetite for change -- big bang or incremental?
- Want me to run
/information-architectureon your Notion or tool setup to get more specific?
Example Output
Input
- Company & context: Harbourline Digital, a 45-person product consultancy running 6 concurrent client engagements; Head of Product (Sophie Chen) is manually compiling weekly status emails by pulling from Jira, Notion, Slack, and client-facing Confluence pages every Friday afternoon
- Tools in use: Jira (delivery tracking), Notion (internal docs, research, decision logs — inconsistently used), Confluence (client-facing pages), Slack (decisions, blockers, everything else), Google Slides (roadmap decks rebuilt per stakeholder), Figma (design specs)
- Team shape: 4 PMs (one per 1–2 client streams), 18 engineers, 5 designers, 3 delivery leads; Sophie is the only person with a full cross-portfolio view
- Pain points: Leadership asks Sophie for status mid-week; client decisions get buried in Slack DMs; research done for one client gets rediscovered (or re-done) six months later; engineers don't know why priorities shift between sprints; two clients have complained about not knowing where decisions stand without booking a meeting
Output (abbreviated)
Product Command Centre — Harbourline Digital
Step 2: Information Flow Audit
| Information Type | Where It Lives Today | Who Creates It | Who Needs It | Failure Mode |
|---|---|---|---|---|
| Active priorities / roadmap | Google Slides (rebuilt per client) | Sophie + PMs | Leadership, clients, delivery leads | Scattered + stale — 6 different decks, none current |
| Delivery status | Jira (inconsistent ticket hygiene) | Engineers, PMs | Sophie, delivery leads, clients | Push-dependent — Sophie manually extracts every Friday |
| Decisions made | Slack DMs and threads | PMs, Sophie | Clients, engineers, leadership | Tribal — no structured capture; buried within days |
| Research and learnings | Notion (varies by PM) | PMs, designers | All PMs, future engagements | Scattered + tribal — no cross-portfolio index |
| Risks and blockers | Slack, some in Jira | Delivery leads, PMs | Sophie, leadership, clients | Push-dependent — surfaces only when someone escalates |
| Metrics and outcomes | Spreadsheets (per engagement) | PMs | Leadership, clients | Stale — updated before QBRs only |
| Customer/client feedback | Email, Slack, Zoom notes | Account leads | PMs, designers | Missing — no structured capture at all |
Dominant failure pattern: Sophie is the human integration layer. Every information type either flows through her manually or doesn't flow at all.
Step 3: Visibility Needs by Audience
Product team (PMs, designers):
- What's the priority across all active streams right now and why
- What research exists before they commission new work
- What decisions have been made on adjacent engagements that might affect them
Engineering / delivery leads:
- Why priorities shifted sprint-to-sprint (decision context, not just the ticket)
- Which streams are at risk before they become escalations
Harbourline leadership:
- Cross-portfolio health: are we on track, what's at risk, any resource conflicts
- Must not require Sophie to assemble — needs to be self-serve by Monday morning
Clients (external — highest pain):
- What's been delivered this sprint and what's coming next
- Where outstanding decisions sit and what they need to action
- A view they can check at 11pm without emailing their PM
Step 4: Operating Model Design
| Information Type | Single Source of Truth | Update Cadence | Push vs Pull | Audience Routing |
|---|---|---|---|---|
| Roadmap / priorities | Notion (per-engagement page, standard template) | Fortnightly by PM | Pull (linked); Push to clients on change | Clients see summary; leadership sees cross-portfolio roll-up |
| Delivery status | Jira (enforce done/in-progress/blocked hygiene) | Continuous (Jira automation) | Pull via Notion embed; Push blockers to Slack #delivery-alerts | Engineers: full Jira; clients: Notion summary only |
| Decisions log | Notion (standardised Decision Record template) | Within 24hrs of decision, by PM | Pull; weekly digest pushed to client Confluence | Full context in Notion; client Confluence shows outcome + rationale only |
| Research & learnings | Notion (single Research Library, tagged by domain + client) | Per study/experiment completion | Pull; PM responsible for tagging on close | Internal only — searchable before any new research is commissioned |
| Risks & blockers | Notion "Needs Attention" board + Slack #delivery-alerts | Real-time (Slack) → weekly reviewed in Notion | Push for high severity; Pull for standing review | Delivery leads triage; Sophie reviews portfolio view weekly, not daily |
| Metrics & outcomes | Notion (per-engagement OKR/metrics section) | Monthly, with sprint-level notes | Pull; Sophie reviews in weekly portfolio scan | Leadership sees roll-up; clients see their engagement view |
| Client feedback | Notion (Feedback Log, per engagement) | Within 48hrs of call/email by account lead | Pull | PMs + designers; feeds into Research Library |
Design principles applied:
- Notion becomes the connective tissue — Jira stays for engineers, Confluence stays for client-facing delivery, but everything routes through Notion as the internal source of truth
- Sophie stops assembling; she starts reviewing
- Client Confluence pages are generated from Notion content, not maintained separately — eliminate the dual-maintenance trap
Step 5: Product Command Centre Spec
Product Command Centre — Harbourline Digital (Internal)
Purpose
One place to answer: Across all 6 engagements — what are we doing, are we on track, what needs Sophie's (or leadership's) attention this week?
Section 1: Portfolio Priorities
- Source: Notion — per-engagement "Current Sprint Goals" property, rolled up via Notion database view
- Update cadence: Fortnightly by each PM (before sprint planning)
- Owner: PM per engagement; Sophie reviews, doesn't compile
Section 2: Delivery Status — Live
- Source: Jira status board embedded into Notion per engagement; filtered view for "In Progress" and "Blocked" only
- Update cadence: Continuous (Jira automation pushes blocked items to Slack #delivery-alerts)
- Owner: Engineering lead keeps tickets current; PM owns the Notion embed
Section 3: Decisions Log
- Source: Notion Decision Record database (fields: date, engagement, decision, rationale, made by, client-visible Y/N)
- Update cadence: Within 24 hours of any significant decision; PM responsible
- Owner: PM per engagement; delivery lead spot-checks weekly
Section 4: Research Library
- Source: Notion Research Library — tagged by engagement, domain (e.g., checkout UX, onboarding, pricing), and status (active / complete / archived)
- Update cadence: On study completion; PM tags and links outputs
- Owner: PM + designer; Sophie owns the tagging taxonomy
Section 5: Needs Attention
- Source: Notion filtered view — surfaces any item tagged "blocked," "decision pending," or "at risk" across all engagements
- Update cadence: Real-time via Jira/Notion automation; reviewed in weekly 30-min portfolio sync
- Owner: Sophie reviews; delivery leads triage before it reaches her
Operating Rhythm
- Daily: Jira blocked items auto-push to #delivery-alerts. No manual action unless severity = high.
- Weekly (Friday, 30 min): Sophie opens Command Centre Notion page — reviews Needs Attention board, scans delivery status. Replaces Friday email assembly entirely.
- Fortnightly: PMs update priorities section before sprint planning. Notion auto-timestamps last updated.
- Monthly: Metrics section refreshed per engagement. Research Library archived/tagged by PM.
Implementation Path
-
Week 1–2 — Decisions Log (highest pain: client complaints and buried Slack decisions) Set up Notion Decision Record template. Brief all PMs on 24hr capture norm. Takes 2hrs to build, 5 min per decision to maintain.
-
Week 3–4 — Needs Attention board + Jira hygiene Enforce three-status discipline in Jira (in progress / blocked / done). Build Notion filtered view. Set up Slack alert automation for blocked items. Eliminates mid-week status pings to Sophie.
-
**Week 5–6 — Client