product-ops

What this skill does

# Product and roadmap management

Set up and run product operations workflows in Airtable — roadmap, customer feedback, launches, OKRs, sprints, releases — adapting to the user's team size, sub-workflow priorities, and customer shape. Ask scope before scaffolding; the same trigger can mean a 3-table solo workspace or a multi-base enterprise portfolio, and the right schema depends on what the user is actually trying to coordinate.

## Who this serves and what they're solving for

Three product-shape buckets, each with distinct personas and pain:

-   **Software product team — the obvious-looking default that's actually less than half of real-world cases.** **PMs, PMMs, engineering leads, designers, founders / PM-of-one.** Top priorities: roadmap visibility for execs and GTM, feedback-to-feature linkage with demand signal, OKR cascade, launch coordination, capacity-vs-commitments clarity. Modal pain: tool sprawl across Productboard / Jira / Smartsheet / spreadsheets / slide decks — _"swivel-chair work,"_ _"too many sources of truth,"_ _"PMs spending 2-3 hours/week searching and copying data,"_ _"40% of PM time answering internal roadmap questions,"_ feedback _"living in a 'black hole.'"_
-   **Non-tech industry product teams.** **Product managers in apparel / fashion / consumer (PLM-shaped — line plans, BOM, tech packs, sample tracking), banking / fintech / capital markets (regulated and stage-gated), pharma / biotech / medical devices (compliance-heavy), media / gaming (release-cadence and franchise portfolio), aerospace / automotive (APQP and supplier-collaborative).** Top priorities: product lifecycle management with phased compliance, vendor / partner coordination via synced bases, BOM and SKU governance, ROI / IRR / NPV business-case reviews on initiatives, regulated audit-trail rollups. Modal pain: aged PLM / SoR systems that _"haven't been touched,"_ Excel sprawl with version clashes, the "translation layer" need between specialist tools and executive review, regulatory audit-trail requirements that current tools don't enforce.
-   **Multi-team product ops at scale.** **Product Ops Leads, Directors of Product Operations, PMO directors at large product orgs, VPs of Product.** Top priorities: portfolio rollup across squads, capacity-constrained planning with cut-line scenarios, cross-team dependency tracking, OKR alignment for hundreds of initiatives, mobile-friendly executive dashboards. Modal pain: _"weekend reporting marathons,"_ portfolio drift between strategic intent and operational work, _"limited Jira literacy outside Product/Engineering,"_ _"manual translation of Jira data for executives."_

Broader problems running across all three:

-   **Tool sprawl and broken single source of truth.** A single base often replaces 5+ tools — PM tool + engineering tracker + spreadsheets + slide decks + email threads. The first job is often to consolidate, not just add another tool.
-   **Manual reporting toil.** Status updates, executive decks, weekly digests, QBR prep — a meaningful chunk of PM time goes into producing reports a system could generate. Automating this is usually the highest-leverage early win.
-   **Feedback-to-feature disconnect.** Customer signal arrives across channels (NPS, support tickets, Slack, sales notes, in-app, call transcripts) but doesn't trace to roadmap decisions — feedback _"lives in a 'black hole'"_ without a structured link from raw signal to demand-weighted prioritization.
-   **Cross-functional handoffs dropping.** Design → Engineering → Marketing → CS handoffs lose fidelity without explicit ownership, dependencies, and shared schema.
-   **Aspirational vs. deployed AI.** Most customers are still piloting AI in product ops, not running it in production. Workflows should compose AI cleanly when available but work without it.

Use this to tune language and prioritization. A small-team founder cares about lightweight backlog and feedback-to-feature linkage; a non-tech industry PM cares about lifecycle / compliance / vendor coordination; a Product Ops Lead cares about portfolio rollup and capacity scenarios. Same skill, different leads.

## Before scaffolding: ask scope

Product operations cuts across software, banking, apparel, pharma, media, aerospace, energy, and many more industries — and the "obvious" tech-product-team default fits less than half of real-world cases. Lead with three scope questions, branch from there. Don't try to ask all of them in one breath; lead with team size and sub-workflow, ask the third when the answer is load-bearing.

1. **Team size and shape.** Solo / small (under 10) / mid (10-50) / large (50+) / enterprise (multi-team / multi-base). Determines schema-shape default — a 5-person team and a 200-person product org don't want the same scaffolding.
2. **Which sub-workflow first.** _"Roadmap, customer feedback, launch coordination, OKRs, sprint planning, or something else?"_ Determines which Work-mode playbook to load. Most users want one of these first, not all of them.
3. **Customer / user shape.** _"Do your product decisions track named customers and accounts (B2B), aggregate user signals across a broad base (consumer), or both (mixed / B2B2C)?"_ Determines whether the schema needs an Accounts table with ARR-weighted rollups, a Cohorts / Segments table with volume-weighted signals, or both. Frame it operationally — what kind of data they actually track — not as an abstract business-model label.

Branch into these when relevant — but only when relevant:

-   **Existing engineering tracker?** (Jira / Linear / Azure DevOps / none.) Many product-ops setups integrate with Jira; affects sync plan and may surface the "translation layer" framing (Airtable as a human-friendly veneer over Jira for execs and GTM).
-   **Migrating from a single-purpose PM tool?** (Productboard / Aha / Cycle / Monday / Smartsheet / Notion / Miro.) Surfaces a migration playbook; common pattern, not edge case.
-   **Public-facing surface needed?** (Customer portal, external roadmap viewer, branded feedback page.) Pushes toward the custom-app build layer (see Output below).
-   **Approved-vendor AI constraints?** (Gemini-only, no third-party LLMs.) Real pattern in enterprise; affects which AI integrations the skill can recommend.

The three lead questions plus relevant branches usually clarify the scaffold in one round of dialogue. Don't impose a framework before listening.

## Two modes

### Setup mode: scaffold a base

When the user asks _"set up a roadmap base"_ / _"build me product ops in Airtable"_ / _"track feature requests"_, scaffold the schema via the MCP after scope is clear. Sequence:

1. **Scope questions** (above) — read the answers; don't skip if the user dives straight to _"just build it."_ A 5-minute scope conversation beats a wrong-shape rebuild.
2. **Pick a schema shape** matching team size and customer shape. Five lead shapes the skill body names inline; two niche shapes available on demand.
3. **Build the schema via MCP** — base, typed fields, linked records, formulas, rollups, sample / seed data. The schema is the foundation everything else stands on; spend the agent's effort on richer typed fields, well-named status `singleSelect`s with thoughtful choice colors, linked-record relationships with rollup counts.
4. **Hand off UI configuration** for things Airtable's UI does better — views, interfaces, automations, forms, granular permissions, sync wizards. See "Build-plan output" below for the handoff shape.
5. **Build the custom-app layer** when the user wants a branded UI, public-facing portal, embedded surface, or chat-bot driving the data. Optional; see `references/build-shapes.md`.

#### Lead schema shapes

The five most-common shapes — covering the great majority of invocations. Each adapts to B2B / consumer / mixed variants (Accounts table vs. Cohorts table; ARR-weighted vs. volume-weighted prioritization; Salesforce sync vs. app-store ingestion). Full field-by-field detail in `references/sche