Product Framework Overview
Purpose
This document describes how the Product team operates in 2026. It defines the hierarchy of work, the objectives that drive the process, and how every Project contributes to a long-term Vertical.
Why We Operate This Way
The framework targets three outcomes. Every rule in the rest of the Team documentation traces back to one of them.
- Visibility. Anyone in the company can answer "what is Product working on?" in under a minute.
- Better tools for Dev and QA. Specs ship with EARS requirements, a Test Plan, and Milestones. Execution starts without open critical questions.
- Stable rhythm. Projects are capped at 1 to 3 weeks. Continuous flow, not heroism. Predictability over occasional velocity.
What Changes from Previous Operation
| Before | After |
|---|---|
| Loose tickets without shared context | Projects with a living spec in Linear (problem → EARS → metrics) |
| Ambiguous requirements ("the system should be fast") | Verifiable requirements tested one-by-one |
| QA enters at the end, as last mile | QA co-authors the Test Plan from Shaping |
| Elastic scope, dates that slip | Fixed appetite 1 to 3 weeks: we cut scope, not dates |
| Visibility on request, not on cadence | Weekly updates and per-deploy Shout-outs |
Three Levels of Work
Work is organized in a three-tier hierarchy. Each level has a distinct purpose and owner.
Initiative
Thematic grouping of two or more Projects. Same product area, same user, same system. An Initiative is not an OKR: it is a connecting thread that gives Projects shared meaning and shared success criteria.
Project
A scoped problem with an appetite of 1 to 3 weeks. A Project has a spec (with EARS requirements), a Test Plan, Milestones, a list of Issues, and an owner. The Project exists before the tickets are created.
Issue
The executable unit of work. Issues live inside a Project (created and listed by the PM, refined by the Dev Lead) or standalone in the shared zone (small bugs, minor improvements, local tech debt).
How It Fits with the 2026 Verticals
The company has four long-term Verticals. They define where we invest. The Framework defines how we execute inside each Vertical.
- Publica.la Education (Fulfillment squad)
- Reading Experience (Fulfillment squad)
- E-Commerce: Checkout (E-Commerce squad)
- Paper (E-Commerce squad)
Every Initiative belongs to a Vertical. Every Project belongs to an Initiative. Every Issue belongs to a Project or to the shared zone.
Who Works Where
Product owns the why and the what. Development owns the how.
Product Team (CPO, PMs, QA)
- Define Initiatives and their rationale.
- Create and shape Projects.
- Write the spec, EARS requirements, and Quality Bar.
- Co-author the Test Plan (QA).
- List initial Issues at high level.
- Approve acceptance.
Development Team (Dev Lead, Developers)
- Break Issues into technical tasks.
- Estimate and pull from the top of Prioritized.
- Implement, open MRs, review.
- Keep Issues up to date.
- Collaborate with QA during testing.
- Deploy and monitor for 72 hours.
A shared zone holds small bugs, minor improvements, and localized tech debt. Anyone in either team can create and pull from it.
Product Design is currently suspended. We build on top of the existing design system.
Related Documentation
- Framework Rules — the binding constitution of the framework (R-01 to R-39). Every other doc explains these rules.
- Product Principles — the four cross-cutting principles that shape every Project.
- Project Gates — binary checklists for every Project transition, used by skills and agents.
- Project Lifecycle — states, transition checkpoints, and appetite.
- Spec and EARS — how a Project spec is structured and how EARS requirements are written.
- QA Collaboration — how QA participates from Shaping onward.
- Prioritization — how Projects are ordered and how urgencies are handled.
- Cadences and Visibility — ceremonies, updates, and release communication.
- Backlog Management — Kanban mechanics, states, and integrations.