SPF, Sprint Protection Factor

Status

live

Tier

free

Demo

open

Hard part

hold two horizons

why

The first thing I do every Monday is open Jira and try to think about next sprint while the current one is still mid-flight. Jira shows me one board. Linear shows me one board. Every sprint tool I’ve used flattens both horizons into a single column, and the column always loses to whichever sprint is shouting louder: the active one, every time. The work that gets dropped is the work that hadn’t shouted yet.

SPF is built around the gap between this sprint and next sprint, which is where the dropped work lives. Jira’s burndown and Linear’s velocity dashboard are very good at telling someone else how the team is doing. This one is built for the product manager’s own week. Live at spf.hosette.net: the demo loads in a populated workspace with no signup.

what I built

Horizons

2

Modes

2

Demo

live

Auth

none

Tier

free

A two-sprint dashboard you can’t collapse into a single view, because the discipline is the layout. The whole tool loads with a live demo workspace that re-seeds nightly. Front door, not a feature.

Dashboard

Active sprint left, planning sprint right. The two horizons sit side by side because that's where the work that gets dropped tends to live.

Focus Mode

Single-task triage: one card, no list, no peripheral vision. Standalone version runs without auth, free for anyone.

Quick Catch

Slash-key shortcut from anywhere on the page, into the right sprint by default. Capture without context-switching.

Ceremony Gen

Planning agenda, retro doc, weekly status, all written from the sprint state. The recurring meetings stop being a recurring tax.

Recurring Tasks

Standing work that doesn't need re-creation each cycle. Set once, surfaces in the right sprint automatically.

Weekly Summary

AI stitches the closed-out work into a 1:1-ready paragraph for your manager.

the two-horizon problem

The two-sprint frame isn’t a UI choice. It’s the visible shape of a problem with names in three different research traditions:

• Behavioral economics calls it time-discounting. People weight near-term outcomes more heavily than distant ones, and not at a constant rate. Kahneman and Tversky’s prospect theory work showed the curve is asymmetric. For a PM, that means current sprint gets foregrounded and next sprint gets quietly deferred: not because anyone’s lazy, because the brain weights them unevenly. A single-board sprint tool flatters that bias by giving both horizons the same column. SPF’s two-column layout fights it by giving each the same physical real estate.
• Defense planning calls it operational vs strategic horizon. A squad leader is operational; a battalion commander is strategic. The rank structure exists in part to keep one from collapsing into the other. Product management has the same two-horizon problem and almost no rank structure to enforce the split: the same person plans and executes, often inside the same Jira board. The two-sprint dashboard is the rank structure made visual.
• Agile literature called it sprint planning vs backlog refinement. The Scrum Guide names them as separate activities for separate cognitive tasks. Most teams collapse them, planning becomes a quick triage, and refinement becomes the meeting that keeps getting cancelled. SPF refuses the collapse at the layout level: you literally cannot see the active sprint without seeing the planning sprint next to it.

The three frames diagnose the same problem and prescribe different things: fight the bias with structure, separate the roles, protect the second ceremony. SPF takes the first one because it’s the only one a single PM can actually deploy. You can’t promote yourself to battalion commander, and you can’t make your team protect a meeting they keep skipping. You can put two sprints side by side and refuse to let the layout collapse them.

decisions I’d defend

Cut the kanban. Most sprint tools default to a status-column board with drag-and-drop. SPF defaults to a list with one focused task and the next sprint visible at a glance. Product managers don’t drag; they decide what’s next, then defend the decision. The board flatters status updates. The list flatters decisions.

Memory before features. Before adding a third or fourth surface, I built a mem:// decision log. Every rejected idea, every guardrail, every “we already discussed this” lives in one file the AI tooling consults on every change: the same pattern in Omunikorudo’s style memory and Celine AI’s statute layer. Rejected features stay rejected. The mem file is more durable than any style guide PDF.

Demo over signup wall. Most SaaS tools ask for an email before showing you anything that proves they work. SPF flips it: the front door is a live, populated workspace that reseeds nightly. Same shape as Omunikorudo loading without a “Start Audio” button and Inventor Strudel saving by URL with no login. Conversion happens after the user feels the product working, which is the only conversion event predictive of retention.

the receipts

The actual mem://decision-log file isn’t published; the portable shape lives at /decisions-starter.md. Three real cuts the template ships with:

YYYY-MM-DD Pomodoro mode as a separate feature. Cut; the single-task focus shape did the work without a timer.

YYYY-MM-DD Per-task estimator. Cut. Estimates are a category error for this product.

YYYY-MM-DD Third sprint column. Cut. Two columns is the discipline; a third would let me defer indefinitely.

The pomodoro line is what eventually became Focus Mode: the cut wasn’t of the idea but of the feature shape. The third-sprint cut is the rule the two-horizon argument is built on. The estimator cut taught me category error is a useful thing to write down about a product.

what I learned

AI collapses spec into prototype, so the bottleneck moves to taste. With Lovable, the gap between “I want a Quick Catch shortcut” and “it works” is minutes. The slow part isn’t building. It’s deciding which of the next ten features should not be built. Most of my time on SPF goes to cuts.

Institutional memory is a tooling problem, not a discipline problem. Senior PMs don’t simply remember more decisions. They write them down somewhere that gets re-read every time, instead of trusting recall.

Solo shipping forces ruthless scope cuts. No team, no committee, no compromise version. If a feature can’t justify itself to a tired PM at 11pm, it doesn’t ship. The third sprint column and the per-task estimator both died there. The pomodoro idea survived — as Focus Mode.

Optimizing for the practitioner inverts almost every default. Sprint tools are written to surface progress upward. Build for the PM’s own week and you get fewer columns, no aggregate metrics, and a focus mode that hides the rest of the team. Feels wrong against Linear. Feels right to the person actually running the sprint.

what would prove it

Once SPF crosses the few-hundred-user mark, three things I’d want the data to settle:

• Two-sprint adoption in week one predicts week-four retention. The whole product bets that holding two horizons is the behavior worth installing. Users who populate both columns in week one should stick around at higher rates than ones who only fill the active side. If they don’t, the dashboard is a layout, not a habit.
• Carryover rate falls without sprint scope getting padded. A product manager actually prepping the next sprint should be carrying less unfinished work forward. The lazy version of the metric drops trivially (just plan less); the real version is carryover falls AND sprint scope stays honest. Both numbers, side by side, every retro.
• Weekly Summary replaces the 1:1 prep, not the 1:1. If the auto-stitched paragraph is doing its job, the 1:1 starts on what’s contested rather than on what happened. If managers are still asking what did you ship?, the feature is a toy.

Two risks I’d be watching:

• Opinionated defaults age into rigidity. Two sprints, two weeks, fixed cadence: that’s the discipline. For a team on a three-week rhythm, or biweekly-with-a-planning-week, the layout starts working against them. Either the defaults need an escape hatch or the product narrows to teams that already match the cadence.
• The PM-shaped niche has a ceiling. Designers and founders run the same two-horizon problem and the system adapts fine, but every default that reads for PMs raises the cost of generalizing later. Stay PM-pure or open the language: pick early, on purpose.

try it yourself

The portable shape is at /decisions-starter.md: same pattern as the receipts above. Drop it at the root of your repo, rename to decisions.md (or paste into your CLAUDE.md), and add the agent prompt at the bottom to your tool’s system instructions. Sections cover rejected ideas, design rules, naming conventions, scope guardrails. Reversals are noted in place rather than deleted, so the file ages legibly. The file does nothing without the agent prompt that says read this on every change, treat entries as binding — ship them together. The reason it eats style guides is that it’s consulted at the moment of decision, not pulled out at sprint planning.

method extracted: Product Memory OS

SPF is the project. Product Memory OS is the method extracted from existing work. Sprint tools remember tasks. Product memory remembers why. The decision log prevents the same decisions from being reopened, contradicted, or lost — especially when AI can modify code quickly. Institutional memory is a tooling problem, not a discipline problem.

Related methods: AI-era Product Development Life Cycle. Starter: decisions-starter.md.

what’s next

Three integration arcs:

• Google Calendar so ceremonies actually land on the schedule
• An agent inbox for coding tools
• Persona-aware Jira/Linear/Shortcut connectors moving from “recommend” to “import”

A paid tier is on the table once the integration story is real. The demo stays free either way. Then there’s generalizing the two-sprint frame beyond product managers: designers and founders both run on the same horizon problem. Live at spf.hosette.net: no signup, no email gate.