Strategy & operations / Product case study
A list of priorities
isn’t a plan yet.
Planning Cycle Workbench
A practical way to turn competing proposals into an explicit conversation about capacity, sequencing, and what leadership will actually commit to.
- Contribution
- Problem framing, planning rules, interaction design, and implementation with AI assistance.
- For
- A strategy or operations facilitator preparing a cross-functional leadership review.
- Delivery
- Next.js, React, TypeScript. A browser-based tool with local persistence and portable backups.
01 / The operating problem
Good proposals can still make an impossible portfolio.
Quarterly planning often starts with reasonable requests from every team. Each has a sponsor, a desired outcome, and a reason it matters now. The problem appears when those requests compete for the same engineering weeks or assume another team’s work will be finished first.
A slide deck can describe the ambition. A task tracker can hold the work. The gap is the decision meeting between them: what fits, what depends on what, what is still unknown, and which tradeoffs need a named decision-maker?
Design goal
Give a facilitator enough structure to challenge the plan before commitments harden, and enough context to explain the decision afterward.
The workflow follows that meeting: frame the mandate and constraints, capture proposals, inspect readiness issues, prepare the leadership packet, record dispositions and rationale, then retain a reviewed baseline for comparison.
02 / Decision logic
Make the rules inspectable.
The Workbench uses explicit checks. It does not rank investments or roll uncertainty into a single health score. A conflict should tell the facilitator what is wrong and where to act.
Capacity: count demand before it becomes a promise.
Active demand = proposed + revise + commit
Conflict when active demand > team allocation
Allocation means person-weeks reserved for initiatives across the entire cycle, after operating work. Deferred and declined initiatives release demand; committed demand is shown as a subset. Counting only commitments would hide competition during the review when scope can still change.
A blank estimate for a selected team means unknown. The numeric total sums known estimates, while readiness flags expose the gaps. Zero is an explicit estimate; unselected teams contribute no demand. A proposal can explicitly require no team capacity. An unknown allocation is a missing-information issue, not evidence that a plan fits.
Dependencies: confirmation doesn’t override a contradiction.
An initiative dependency is finish-to-start: its prerequisite must end on an earlier calendar day. Same-day handoffs are flagged. Team dependencies record a contribution, with facilitator-recorded confirmation and evidence.
- Missing targets and deferred or declined prerequisites produce conflicts.
- A graph traversal detects a path back to the dependent initiative, including self-dependencies and longer cycles.
- Dates and graph structure remain checked even after confirmation.
- At finalization, a committed initiative also needs committed prerequisites.
Readiness: distinguish a discussion from a decision.
Incomplete drafts receive advisory prompts. Review surfaces missing information on active proposals, but a fully framed leadership request can remain open for discussion. Finalization flags unresolved requests and dispositions. A recommendation in the executive brief never changes capacity by itself: the facilitator must record the actual initiative decisions.
03 / A concrete planning conversation
Northstar: protect the onboarding outcome.
The built-in fictional Q1 2027 sample contains nine initiatives, including one already deferred. Its mandate is to reduce time to first value while protecting renewal service. Guided onboarding targets a reduction in median activation time from 14 to 7 days. That is a planning target, not a measured result.
Scroll the table horizontally to compare all three plans.
| Team | Initial proposals | Defer foundation | Focused plan |
|---|---|---|---|
| Product & Engineering | 34 / 24Over allocation | 24 / 24 | 23 / 24 |
| Revenue | 18 / 16Over allocation | 16 / 16 | 7 / 16 |
| Customer Operations | 21 / 18Over allocation | 21 / 18Over allocation | 11 / 18 |
1. Surface the competing claims.
Engineering requests 34 weeks against 24 available. Revenue requests 18 against 16; Customer Operations requests 21 against 18. The partner pilot also lacks an owner and success definition. More precise arithmetic cannot resolve an undefined proposal.
2. Test the tempting shortcut.
Deferring Data foundation releases 10 engineering weeks, bringing demand to 24. But Guided onboarding depends on that foundation. The engineering capacity warning clears while an upstream dependency conflict appears. Revenue also falls to its allocation of 16; Operations remains overloaded at 21 against 18.
3. Make an outcome-led choice.
Commit Data foundation, Guided onboarding, Sales handoff standard, and Self-service knowledge base. Defer the other five with rationale, and record confirmation of the onboarding dependency. Foundation ends January 29; onboarding starts February 1. The resulting demand is 23 engineering, 7 Revenue, and 11 Operations person-weeks, within all three allocations.
What leadership gives up
Partner learning and renewal automation move later. Existing manual processes remain necessary. Review the plan if the foundation slips beyond January 29, activation fails to improve, or renewal service deteriorates. A feasible allocation still needs ownership and follow-through.
To reproduce it, open the workbench and choose “Load fictional sample.” The sample controls ask before replacing an existing plan. This case study does not read or change your saved work.
04 / Building with AI assistance
The product judgment lives in the rules.
I used AI assistance to translate the planning workflow into a working interface, TypeScript rules, and regression checks. The central product choices were what to count as demand, what qualifies as a dependency conflict, and what leaders need to decide. Those choices are explicit enough to inspect and test.
Product and operations judgment
Define the facilitator workflow, use cycle-level initiative capacity, preserve unknowns, distinguish framed requests from resolved decisions, and keep recommendations separate from commitments.
AI-assisted implementation
Turn those requirements into React editing flows, a separate calculation and validation model, sample data, and checks for failure cases. Evaluate the implementation against concrete planning examples.
Separating the model from the UI makes the important claims testable: deferral releases demand, confirmed dependencies can still conflict, and a circular graph cannot become valid by checking a box. This page uses the same model and sample to calculate its comparison.
The tool itself uses deterministic rules; there is no runtime AI making planning decisions. Plans stay in browser storage. Validated JSON backups, CSV exports, a printable leadership packet, and one retained baseline make the work portable without adding an account system.
Verification that follows the failure modes
Automated checks cover status-based capacity, unknown estimates, dependency cycles and dates, readiness stages, baseline changes, import validation, CSV escaping, and storage failures. The documented browser walkthrough covers sample edits, leadership packet content, persistence, imports, and desktop and mobile layouts. Native PDF pagination remains unverified.
05 / Outcome & limits
A decision record people can challenge.
The delivered tool connects the executive brief to the underlying proposals, capacity claims, dependencies, and recorded decisions. A facilitator can explain what changed against a reviewed baseline instead of reconstructing the conversation from a deck.
The evidence here is working behavior and a reproducible fictional scenario. No adoption, time-saved, or business-impact metrics are claimed. The sample demonstrates that a plan can fit the recorded constraints; it does not prove the outcome will be achieved.
The deliberate scope is one facilitator, one local cycle, and one retained baseline. It does not model weekly staffing peaks, automatically reschedule dependencies, or provide live collaboration. Confirmations and named decision-makers are facilitator records, not authenticated approvals.
The next useful validation would be a facilitated planning review: can participants identify the tradeoff, understand the decision request, and reconstruct the rationale afterward? That would test the workflow’s value beyond the sample.