Skip to main content
  • Send to AI

Framework Rules

Purpose​

Constitution of the 2026 Product Framework. Every rule is binary: it is either met or not met. Documentation and skills reference these rules by number (for example, R-09).

Version: April 2026. Source: Framework_Producto_2026_Presentacion.pptx.

Meta​

  • M-1 — Every rule is binary. If you cannot answer yes or no by looking at the artifact, the rule is badly written and must be fixed.
  • M-2 — When a rule is not met, the work does not advance state. The only exception is Expedite (R-35), which has its own lane.
  • M-3 — Rules apply equally to all four Verticals (Publica.la Education, Reading Experience, E-Commerce: Checkout, Paper). There is no "in this Vertical we do it differently."

Work Structure​

  • R-01 — All Product work is expressed as an Initiative, a Project, or an Issue. No other units exist.
  • R-02 — Every Project belongs to exactly one active Initiative.
  • R-03 — Every Initiative groups two or more Projects. An Initiative with a single Project degrades to a Project.
  • R-04 — Every Project is associated with one of the four Verticals of the 2026 Framework, with the resolution of necessary debt, or with the need of a specific customer.
  • R-05 — Every Project has a single named PM owner.
  • R-06 — Every Issue belongs to a Project, except for Issues in the shared zone (small bugs, minor improvements, localized tech debt).

Appetite​

  • R-07 — The maximum appetite of a Project is 3 weeks. If it exceeds, it is split before starting.
  • R-08 — When the Project runs off track, we cut scope, not extend the date. Moving the date requires an explicit decision and is recorded.

Spec (Project)​

  • R-09 — Every Project has a living spec in Linear with seven sections: Problem, Objective, EARS Requirements, No-Goals, Quality Bar, Risks, Test Plan. A missing section means there is no spec.
  • R-10 — The Objective is a single testable sentence.
  • R-11 — No-Goals are written explicitly. They are not inferred.
  • R-12 — The spec is the source of truth. If an Issue contradicts the spec, the spec wins.

EARS​

  • R-13 — All functional, tracking, and state-behavior requirements are written as EARS in one of the five patterns (Ubiquitous, Event-driven, State-driven, Unwanted behavior, Optional feature). This includes:
    • Functional behavior of the system.
    • Tracking events: each user-triggered event the system must emit, with payload, written as Event-driven EARS.
    • State behaviors: empty, error, loading, and offline states with their copy, written as State-driven or Unwanted-behavior EARS.
  • R-14 — Every EARS must be testable by a concrete case. If QA cannot write the case, the EARS returns to Shaping.
  • R-15 — Every EARS produces at least one case in the Test Plan.

Quality Bar​

  • R-16 — The Quality Bar is a list of open questions and suggestions that the Project must resolve during Refining, not in Shaping. Three items minimum:

    1. Metric — questions about baseline, target, and measurement window.
    2. Performance — questions about LCP and TTI on web, or response time on admin.
    3. Accessibility — questions about the WCAG AA scope on user-touched surfaces.

    Tracking events and state behaviors (empty, error, loading, offline) are not part of the Quality Bar: they are written as EARS Acceptance Criteria (R-13).

    The Quality Bar may stay open during Shaping. All three items must be answered before Spec Review (Gate 3). A missing answer at Spec Review blocks the transition to To Do.

  • R-17 — Metrics are answered before Spec Review and instrumented ideally before the deploy.

  • R-18 — Performance and accessibility answers are not deferred to v2. They may be open during Shaping but must close before Spec Review.

Principles as Hard Rules​

Simplification​

  • R-19 — No Project solves a problem by adding an "advanced mode", an "expert user" toggle, an explanatory tooltip, or an onboarding tutorial. If that is the proposed solution, the Project returns to Shaping.
  • R-20 — No new configuration is exposed to the end reader. Configurability lives at the tenant.
  • R-21 — Killing an existing option with usage below 5% counts as valid progress in Shaping, except in cases of customers highly relevant to Publica.la.

Remove Blockers​

  • R-22 — Every Project declares in its spec at least one of: (a) the friction it removes on a common path, or (b) the two or more future initiatives it enables. The initiatives claimed in (b) must be traceable to active Initiatives or to the Verticals framework. A Project that declares neither is not approved.

Self-Serve​

  • R-23 — No release closes by adding manual steps for CS or DevOps. Every release either lists which manual operation it eliminates or, at minimum, adds none.
  • R-24 — Ideally, tenant-gated features are activated from the tenant's panel. Never by CS ticket or DevOps script. They may also be managed from Nova.

QA​

  • R-25 — QA is the author of the Test Plan from Shaping. QA is co-author of the Project or Issue from Shaping.
  • R-26 — Without a complete Test Plan, the Spec Review cannot be held.
  • R-27 — Non-blocking bugs found during QA Testing are created as Issues inside the Project, not as standalone Issues.

Transition Checkpoints​

  • R-28 — The Spec Review is held with the CPO before the Project reaches Prioritized.
  • R-29 — The Test Plan is completed by QA before QA Testing begins within In Review.
  • R-30 — QA pass (zero Sev-1 and Sev-2 bugs) is required before the Project reaches Resolved.

Roles and Domain​

  • R-31 — Product defines the why and the what. Development defines the how. PMs do not write technical tasks; the Tech Lead does not modify requirements without returning to the spec.
  • R-32 — The PM delivers an initial list of high-level Issues. The Tech Lead splits them into technical tasks at the Kickoff.
  • R-33 — Product Design is suspended: we work with the existing design system. No custom design is opened.

Prioritization​

  • R-34 — Among candidates inside the same Initiative, the order is set by RICE. There is no prioritization by opinion or by stakeholder urgency outside Expedite.
  • R-35 — Expedite lane — maximum cap of 20% of the squad's weekly capacity. Authorized by the CPO or the PM. If it exceeds, the Project with the least progress is paused.
  • R-36 — Every Expedite use is recorded in the monthly log (who authorized it, why, what was paused).

Visibility​

  • R-37 — Every active Project publishes a weekly update on Fridays in #product-updates. Without an update, the Project is escalated at the Weekly Sync.
  • R-38 — Every Project that moves to Deployed publishes a Release Shout-out in #releases the same day.
  • R-39 — Post-deploy monitoring: 72 hours of active observation by Development plus a production smoke test by QA.

How These Rules Are Used​

  • Docs: these rules are the constitution of the framework. The rest of the documentation explains them; it does not debate them.
  • Skills: every Product skill references rules by number (for example, a Shaping skill does not close a Project if R-09, R-13, or R-16 are not at 100%).
  • Exceptions: exceptions may exist, but the reason must be specified and recorded in the Project.
X

Graph View