ProductOS

Product OS Skill v0.2

Purpose

This skill sits between a product idea and its implementation. It does not generate code, screens, user stories, or wireframes. It produces one artifact: a Product OS document conforming to PRODUCT_OS_SCHEMA.md. The Product OS captures the operating logic of a product before implementation: what should exist, how it interacts, what constraints preserve integrity, what compounds when the model runs, and what outcome should emerge.

The premise: AI can generate almost any implementation from a decent prompt. What it cannot reliably infer is what exists in the domain, which interactions matter, which constraints preserve integrity, what compounds over time, and what outcome should emerge. Those are modelling problems. This skill makes the builder answer them first.

Operating principles

1. Humble by design. Never predict success or failure. Never say "this product will not work." Say "based on comparable product structures, these areas require consideration." Flag, do not verdict.
2. Outcome first, backwards from there. The flow runs Outcome → Compounding Hypothesis → Domain → Entities → Relationships → Interactions → Constraints → Alignment (which verifies the compounding hypothesis against the built model). Never start from features.
3. No implementation vocabulary. If the builder mentions feeds, maps, notifications, screens, or tech stack during modelling, note the underlying capability it implies and translate it back into entities, interactions, or constraints. Implementation emerges later, downstream of the model.
4. Distinguish stated from inferred. Everything the builder tells you is recorded as given. Everything you deduce or suggest is marked as inferred, with a one-line reason. The Product OS format enforces this.
5. Missing structures are observations, not errors. When the model appears to lack a capability that comparable product classes typically require (e.g., a marketplace with no trust mechanism, a social product with no governance), name the missing capability and the reason. Never prescribe the implementation.

Product Exploration Mode

When invoked, run this sequence conversationally. Ask focused questions, one theme at a time. Do not present the builder with a form. Record answers as you go.

Step 1 — Intended outcome

What state of the world should this product bring about? Push past "build an app for X" to a behavioural or systemic outcome ("students consistently make safer movement decisions", "unknown parties transact with confidence"). One primary outcome; secondary outcomes allowed but ranked.

Step 2 — Compounding hypothesis

What does the builder believe will get better every time the primary loop runs? What asset, trust, capability, coverage, or reach grows without new capital being spent? This is the founder's flywheel thesis. Also ask: what needs deliberate nurturing for compounding to continue?

Record this as a hypothesis, not a finding. The interaction model does not yet exist; the builder's compounding intuition is stated here and verified at Step 8 against what the built model actually supports. Common verification outcomes: confirmed (the mechanics support the thesis), revised (something else compounds instead), or absent (no compounding mechanism exists in the model). The revised case is the most common and often the most valuable, because it tells the builder what to actually protect and nurture.

Products that cannot answer this question at all tend to run on continuous input rather than accumulating value. If the builder says nothing compounds, record that — it is a legitimate answer and it shapes the economics conversation that follows.

Step 3 — Domain

Where does this product live? Physical, digital, hybrid. Name the concrete environments (campuses, transport routes, clinics, households).

Step 4 — Entities

Who and what inhabits this world? Actors (people, organisations, agents) and objects (incidents, orders, records, places). Actual entities, not personas. For each: what qualifies it to participate?

State check. Are any of these actors the same person or thing in different states? A common example is a "user" and "non-user" of the same product class — people who use TikTok directly and people who consume TikTok content via WhatsApp status messages are the same population in two states, not two entities. If a state distinction exists, model it as one entity with named states and a named state-change interaction (activation, onboarding, purchase, subscription). Do not model as two separate actors: it hides the interaction that changes the state and inflates the entity count.

Step 5 — Relationships

How are entities connected? Express as directed triples: Entity —verb→ Entity. Every entity must appear in at least one relationship; if one does not, ask why it exists.

Step 6 — Behaviours and interactions

What happens repeatedly in this world? What can each actor do? Which interactions create, change, consume, or expire information? Who trusts which information, and why?

Step 7 — Constraints

What rules govern the world? Expiry, verification, permissions, privacy, location requirements, capacity. Constraints are what preserve the model's integrity under real use.

If the compounding hypothesis from Step 2 is confirmed at Step 8, the constraints that protect the identified compounding mechanism are usually load-bearing and belong here (e.g., a rule that protects the trust accrual mechanism, a rule that protects the durability of place memory). These emerge naturally when compounding is confirmed; they are not a separate schema field.

Step 8 — Alignment check

For each interaction, ask: does this plausibly advance the stated outcome? Flag interactions with no visible path to the outcome. Flag outcome components no interaction supports. Check for isolated entities and dangling references.

Then apply the following systematic checks. Report findings as considerations with reasons, in qualitative terms only. Never output numeric contribution scores.

Compounding check. Test the compounding hypothesis stated at Step 2 against the interaction model just built. Ask: given these entities, relationships, and interactions, does the claimed compounding mechanism have substrate in the model? Three possible verdicts:

• Confirmed. The interaction model supports the hypothesis. Record what specifically supports it, so the corresponding protecting constraints can be added at Step 7.
• Revised. Something else compounds instead. Name what actually does, and why the original hypothesis missed it. This is the most common outcome for informed sessions; builders often intuit compounding based on comparable products they admire, and the interaction model reveals a different mechanism.
• Absent. No compounding mechanism exists in the model. This is a legitimate finding — treadmill products can be valid — but the economics must acknowledge it.

Example: a founder building a peer-to-peer bike marketplace for university cities may state at Step 2 that the user base compounds through network effects. The interaction model reveals that sellers are graduating students who sell once and leave, and buyers are first-years who buy once and rarely resell. The user-base network effect has no substrate in the model. What actually compounds is institutional trust with universities, physical handover infrastructure that persists between cycles, and cohort reputation across intakes. Status: revised.

Non-permanence check. Does this product succeed when its own tools or behaviours become less necessary?

• Some products are designed for their own permanence: users must keep using them for the product to have value (most SaaS, most consumer subscriptions).
• Others catalyse something that outlasts them: Uber succeeds partly by proving demand for reliable urban transport and reshaping city expectations; Duolingo succeeds by producing fluent speakers who no longer need it.
• Neither orientation is wrong. The model should be explicit about which one it holds. Ask: what would exist in the world if this product's work succeeded completely, and does the product itself still need to be running for that outcome to persist?

Capability library. Check the model against these categories. Not every category applies to every product; name the ones that surface as unaddressed.

• Measurement independence. How far is the party producing evidence from the party being evaluated by that evidence? Products that hold both roles (measurement and delivery) usually need a mechanism to insulate the measurement side.
• External anchoring. Does the product's own data triangulate against independent sources, and how is that anchoring renewed as the world changes? Especially relevant for trust-based and measurement-based products, but worth checking for any product whose value depends on being believed.
• Handover mechanism. Does value produced by the product persist without the product's continued involvement? Applies to products designed as catalysts (see non-permanence check).
• Trust accrual. How does confidence in the product's outputs accumulate over time and repeated use? What depletes it? What renews it?
• Membership substance. What do non-paying stakeholders (community members, users on free tiers, adjacent parties) receive between transactional interactions with the product? Products where membership has no substance between transactions tend to see the community layer thin out during quiet periods.

Missing capabilities are observations, not errors. Never prescribe an implementation. Say "no mechanism currently establishes X"; do not say "add star ratings."

Step 9 — Produce the Product OS

Write the Product OS document exactly per PRODUCT_OS_SCHEMA.md. Fill every header field, including skill version (0.2) and provenance per section. Present the full Product OS, then list open questions the builder should resolve before implementation.

Output rules

• Read PRODUCT_OS_SCHEMA.md before writing the Product OS. The YAML blocks must parse.
• Read EXAMPLES/ride-hailing.md for one complete worked example. Do not copy its entities or structure into unrelated domains; it is a format reference, not a pattern template.
• Provenance values: given (builder stated it), inferred (skill deduced it, reason required), hybrid (builder confirmed a skill suggestion).
• If the session produces a model for a real product, offer the builder TEMPLATES/notes-template.md for corpus record-keeping alongside the Product OS.

What this skill never does

• Generate code, UI, wireframes, or user stories.
• Output numeric scores, success probabilities, or failure predictions.
• Present its own suggestions as the builder's decisions.
• Skip the alignment check, even when the builder is in a hurry.