Renewal Compass — requirements and product decisions
User, problem and observable outcome
The primary user is an account lead preparing a decision with a product manager before an enterprise renewal review. The problem is a request for multiple changes whose total cost could consume the broader roadmap. The outcome is a reviewed, conditional package decision whose conditions and exclusions remain inspectable. The prototype does not negotiate, communicate, bind an agreement, approve a budget or measure retention.
Mo owns Product / Program Management framing, prioritization and tradeoff direction. AI assists implementation and verification. All sample records are original and fictional; no human research has been conducted.
Product behavior and acceptance
| Requirement | Behavior | Reason / acceptance evidence |
|---|---|---|
| Distinguish obligations, needs and features | Account brief separates three categories | Requested dashboard must not silently become a contract obligation |
| Trace evidence and unknowns | Four labelled observation/assumption records, renewal timing and open questions | A1/A2 remain unsupported; review contains exact evidence version |
| Compare packages | Three work packages, capacity arithmetic, broader impact, exclusions and dependencies | Reviewer can independently compute baseline 8-day budget and custom deficit of 6 |
| Bound the recommendation | Shared package labelled provisional; custom blocked at baseline | A feasible option is not an approved commitment |
| Review conditions deliberately | Draft, preview, cancel, confirm; required owner, conditions, risk and date | Confirmation records a conditional review, never sends a message or promises delivery; late-date warnings persist in exact snapshot/export |
| Preserve decision provenance | Immutable detached package/evidence snapshots and ordered withdrawal events | Later drafts cannot change a prior reviewed scope |
| Recover responsibly | Restore earlier scope to a new draft, reviewed withdrawal, raw-bound reset and reload | Cancellation changes no saved state; new review required for revised scope; visible 98-event limit explains export/reset recovery |
| Explain persistence limits | Invalid bytes preserved; unreadable/write failure mode retains memory work | No overwrite of unseen bytes, no stale same-revision save |
| Share truthful evidence | Self-contained JSON download of an exact recorded snapshot | Export includes scope, evidence, conditions, exclusions and fictional non-promise label |
| Usable interaction | Native modal focus, Escape cancellation, labelled controls, narrow layout and status announcements | Production browser journeys verify keyboard and 320/390/1280 widths |
Alternative rationale
A feature-request list alone makes effort visible but lets the account define the solution. A weighted renewal-value score would create false precision because renewal influence is unknown. A static executive memo explains the tradeoff but cannot demonstrate revision and review safety. This bounded interactive brief makes the need and evidence visible alongside capacity and shared-customer impact. It has no revenue-based optimizer. Bridge-only remains a meaningful smaller option; custom remains selectable for exploration but cannot be recorded when over capacity.
Boundaries and dependency gates
No employer/customer details, real contract values, outreach, payments, legal/compliance claim, integrations, login, telemetry or live AI. Accessibility roadmap benefit and account reach are invented scenario numbers. A real decision would require account discovery, capacity approval and accountable agreement on the operating bridge. The November dates are fixture dates, not promises or current commercial deadlines.
Complete work-package traceability
| Package | Delivered scope | Reviewer evidence |
|---|---|---|
| S069 — User and decision | Enterprise account lead / product manager; bounded outcome and rejected custom-build alternative | Product_Brief and Case_Study |
| S070 — Sample and interaction | Finite account-1 records, state rules, arithmetic and provisional choice | Sample_Contract; domain/storage checks |
| S071 — Preview foundation | Independent static React/TypeScript app, real workspace navigation, project base path | README setup; production load / local documentation checks |
| S072 — Account needs and evidence | Obligations, need, requests, observations, assumptions, timing, unknowns | Account brief; exact walkthrough step 1 |
| S073 — Responsible commitment | Packages, wider roadmap impact, exclusions, dependencies, reviewed conditional brief | Comparison and decision workspace; snapshot and export tests |
| S074 — State recovery | Preview/cancel, restore draft, withdraw, compatible refresh, invalid/unavailable/raw-bound reset | Storage tests and production recovery journeys |
| S075 — Experience and story | Keyboard/focus, narrow forms/modals, clear status, coherent docs and proposed human measures | Validation and Sample_Walkthrough |
| S076 — Release review | Local release gates and reviewer route, with externally verified release evidence tracked separately | Validation release ledger |
Work-package mapping preserves the original scope. Software verification and proposed human evaluation have different evidence standards.