Systeric × Glide: Operating Framework
Two things: what Glide is — the product vision — and how to use it. Conceptual background — problem-framing, root cause thinking, first principles — is in the Curriculum. This doc is the product spec and the operational reference.
Part 1 — What Glide Is
The Vision
Glide makes the Systeric framework frictionless. Every stage gate, field requirement, and sign-off is enforced by the tool — not by memory. The PM never has to remember what’s required to advance; Glide surfaces it.
By Stage
Quarterly Roadmap
Before naming a single item, PM sets category allocations — Compliance, Security, Reliability, Expansion, Product — in Glide. The tool tracks remaining budget per category and blocks overruns. Items can only be proposed against a category that has budget.
Each proposed item carries: a Problem Area, a Metric Goal (the measurable outcome the team is committing to, independent of solution), a Narrative Bet (the hypothesis about cause — what the team believes is happening and why fixing it moves the metric), a Time Budget in person-sprints, and a Category. Glide surfaces likely duplicates when proposing and flags items without supporting data.
The output of the session is a prioritized set of bets — not a feature list — that fits within the category allocation.
Discover
The problem statement is structured, not free-text. Five fields: who specifically experiences this, what they’re trying to accomplish, what’s blocking them, what they do today, and what it costs the business if we don’t solve it. Glide optionally scans for solution language and flags it.
A Data Validation field links to the evidence — Metabase query, support ticket theme, usage data — that confirms the problem is real and significant.
Stage advancement is blocked until PM checks the Leadership Review gate: leadership has confirmed the problem framing is sharp, scoped correctly, and worth taking to Define.
Define
Person-sprints carry forward from the Roadmap stage and are locked. The solution must be written within the constraint — not the other way around.
The Definition is one unified document: PM layer (what, why, user flows, edge cases, explicit in-scope and out-of-scope decisions) and PE layer (how, data model, risks, API contracts, performance targets) in a single narrative. Not split into separate fields. Splitting them disconnects why from how.
A Success Metric field captures the one primary metric with specific target and timeframe. A Release Notes Draft — Before/After format — is written before Build begins. A Release Plan locks milestone dates.
Stage advancement is blocked until PE signs off on the Solution Review: the Definition is complete, implementable, and has no blocking gaps.
Build
Glide shows person-sprints consumed alongside the ceiling. PM gets an alert when the item is approaching its budget limit.
The active milestone is surfaced on the item view. PM logs demo check outcomes against the Definition at each milestone.
Launch
Three gates are required before the Launch signature can be requested: stakeholders notified, release notes finalized with screenshot or demo, leadership approved. Glide blocks the signature until all three are checked.
Release notes auto-populate from the draft written in Define.
Learn
Stage advancement is blocked until the team completes the retrospective: Metric Result (actual vs. the success metric set in Define), per-stage retrospective notes, process changes to carry forward, and new problems to queue. Glide pre-fills the success metric from Define as the comparison target.
Items do not close to Done without a Learn entry.
Part 2 — How to Use Glide
Stage: Quarterly Roadmap
Open: Roadmap → filter by quarter and year
PM pre-work (required before the session):
- 4–7 problem areas ranked by priority — each with: who’s affected, why it matters, supporting data, consequences of inaction
- Rough size signals from PE (days vs. weeks — order of magnitude only)
- Set category budget in Glide before proposing items
Propose each item. Required fields:
| Field | What to Enter |
|---|---|
| Problem Area | Short name |
| Metric Goal | Measurable outcome independent of solution (“Reduce checkout abandonment from 40% to 25%“) |
| Narrative Bet | Your hypothesis — what you believe is happening and why fixing it moves the metric |
| Time Budget | Person-sprints ceiling — not estimated effort |
| Category | Which allocation bucket this belongs to |
| Owner | PM who owns this item through the quarter |
Session structure (4 parts):
- PM presents problem areas — data and size signals, no advocacy
- Challenge each item: Is this the actual problem or a symptom? Right scope? Strategic fit?
- Agree on items: problem area, time budget, category, owner for each
- Validate all items fit within category allocations — cut to fit, don’t assume faster execution
Items start at status Discover.
Stage: Discover
Status: Discover
Owner: PM
Fill in Glide:
| Field | What to Enter |
|---|---|
| Who | Specific role, context, and situation — not “users” |
| Their goal | The underlying job they’re trying to accomplish |
| The friction | Specific blocker — not a category |
| Current workaround | What they do today — tells you what success looks like |
| Cost of inaction | Business impact, retention risk, or time cost — backed by data |
| Data Validation | Metabase link or support ticket theme that confirms the problem is real |
Advancement gate: PM checks the Leadership Review checkbox after leadership confirms the problem framing is sharp and correctly scoped. Status moves to Define.
If you can’t write the cost of inaction without including a solution, you haven’t finished discovery.
Stage: Define
Status: Define
Owner: PM (session facilitator), PE (sign-off)
Budget is locked from the Roadmap stage. The solution must fit the constraint — not the other way around.
Session: 45 minutes silent parallel writing, then discussion
| Role | Writes |
|---|---|
| PM | Proposed solution, user flows, edge cases, explicit in-scope / out-of-scope decisions, design rationale |
| PD | Design considerations, UX decisions, constraints and implications |
| PE | Build approach, risks, data model implications, API contracts, performance targets |
Fill in Glide (all required):
| Field | What to Enter |
|---|---|
| Definition | One unified document — PM layer and PE layer in a single narrative |
| Success Metric | One primary metric + specific target + timeframe (“Cart save rate above 40% within 2 weeks”) |
| Release Plan | Milestone dates — specific dates, not directional estimates |
| Release Notes Draft | Before: [current behavior]. After: [new behavior]. Written before Build begins. |
Advancement gate: PE requests the Solution Review signature, confirming the Definition is complete and implementable with no blocking gaps. Status moves to Build.
If the Before/After in the Release Notes Draft isn’t compelling, the problem may not be worth solving.
Stage: Build
Status: Build
Owner: PE (implementation), PM (velocity protection)
PE: Use the Definition as the primary context for implementation. Each open item has one named owner and one specific next action.
PM actions in Glide:
- Answer technical questions same-day minimum
- Update the Release Plan within 24 hours of any material scope change
- Complete a Demo Check at each milestone — record outcome against the Definition
Glide shows person-sprints consumed vs. the ceiling. If the item is approaching budget, surface it to leadership before it becomes a problem.
Advancement gate: PE marks complete. PM demos against the Definition. Status moves to Launch.
Stage: Launch
Status: Launch
Owner: PM
Three required gates before requesting the Launch signature:
- Stakeholders notified — before launch, not during or after
- Release notes finalized — clear language, Before/After, screenshot or demo video
- Leadership approved — within one hour of launch
Adoption check (required):
- Do users know this exists?
- Do they know how to use it?
- Do they have a compelling reason to try it now?
Advancement gate: All three gates checked → request Launch signature. Status moves to Learn.
Stage: Learn
Status: Learn → closes to Done
Owner: PM + PE + PD (synchronous — not async)
Fill in Glide (all required before closing):
| Field | What to Enter |
|---|---|
| Metric Result | Actual outcome vs. the success metric set in Define — specific numbers |
| Retrospective | Per stage: what worked, what cost time, what you’d do differently |
| Process Changes | Adjustments to how future items should run |
| Product Iterations | New problems discovered — proposed as new Roadmap items |
Advancement gate: Metric Result complete → item closes to Done.
A vague retrospective (“went well overall”) doesn’t compound. Specific, data-backed answers tied to the success metric do.
Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Solution language in the problem statement | Skipped Discover | Rewrite until the problem stands alone |
| Writing the Definition before locking person-sprints | Scope expands freely | Budget-first — solution must fit the ceiling |
| Separate PM and PE documents for Define | Disconnects why from how | One unified Definition field |
| PE sign-off skipped | Build starts against ambiguous spec | Solution signature is a hard gate |
| Launch notification sent after launch | Stakeholders surprised, trust eroded | Notify before, not after |
| Closing to Done without a Learn entry | Learning doesn’t compound across quarters | Metric Result required to close |
| Rock when pebbles were possible | High-risk large bet when sequencing existed | Default to pebbles; justify rocks explicitly |