Feedback Nexus requirements
Product brief
User: A B2B SaaS product manager preparing a planning discussion.
Problem: Feedback systems often separate customer words from the prioritization decision, which makes it difficult to explain why one opportunity moves forward and another does not.
Product outcome: Help the PM compare feedback with its original account context, form a directional priority, and record a decision that a reviewer can challenge. This is a fictional sample workspace, not evidence of customer demand or observed business impact.
Scope and tradeoffs
The first release prioritizes traceability over automation. It preserves individual feedback when related items are grouped, exposes the inputs behind the score, and offers an explicit tag review and editable decision rationale. Those choices add steps, but prevent a tidy backlog from hiding the underlying evidence or a simulated suggestion from being mistaken for a decision.
The sample intentionally excludes CRM ingestion, live customer messaging, collaboration roles, delivery forecasting, model training, and automatic roadmap creation. Browser-only storage keeps the prototype inspectable and low-risk, while also meaning it is not a shared production workspace.
Account identity is normalized at the comparison boundary: leading and trailing whitespace is removed and case is folded for uniqueness. The first displayed spelling remains the source label. This keeps repeated account mentions from inflating scores, linked-group reach, or exported scope without rewriting the original evidence record.
What the prototype enforces
| Behavior | Enforced now | Recommended product practice |
|---|---|---|
| Evidence preservation | Grouping links records without deleting their quotes or source accounts. | Review the original words and segment before making a planning call. |
| Priority input | Impact is 1–5, confidence is 40/60/80/100%, and effort stays from 0.5–100. | Treat the resulting score as directional, not an automatic rank. |
| Tag review | A tag can be accepted or edited; a Planned state does not require review. | State in the rationale why an unreviewed suggestion did or did not matter. |
| Decision state | Inbox, Reviewing, Planned, and Declined are available and persist locally where storage works. | Use Planned as a planning record, not a delivery promise. |
| Recovery | Undo restores the previous saved change; reset asks before replacing fixtures. | Read the reset confirmation and inspect the current shortlist scope before export. |
Workflow requirements
- Find relevant signals by customer words, account name, segment, or current planning state.
- Compare related signals without deleting their original quotes or inflating the affected-account count.
- Inspect a simulated tag suggestion when it would help; accepting or correcting it is optional and does not block recording a planning decision.
- Adjust visible impact, confidence, and effort inputs; explain the choice; then record a planning state.
- Recover from an error with Undo, retain work after refresh where browser storage is available, or export the resulting shortlist.
Acceptance criteria
- Combined search matches title, customer words, account names, tags, and recorded rationale; segment and status filters combine.
- Manual feedback requires a nonblank title, quote, account, a visible Starter/Growth/Enterprise segment, and a unique local record ID.
- Grouping two or more signals preserves every quote and shows unique affected accounts.
- Tag text is drafted while typing and a nonblank edit saves on leaving the tag editor. Blank or whitespace drafts show feedback, cannot be accepted, and leave the last valid saved tag and the rest of the board intact. Moving directly from typing to Accept reviewed tag keeps the original record in place until activation saves and accepts that exact tag atomically, even when the new tag would remove the record from the active filter.
- Tags are simulated suggestions. A reviewer may accept or correct a tag explicitly, or record a Planned decision with the suggested tag still unreviewed and explain why in the rationale.
- Impact, confidence and effort update the score; effort cannot be zero or negative.
- Rationale and status persist. Planned signals appear in the shortlist and its CSV in the same descending directional-score order, with record-level accounts, source provenance, scoring inputs, and scoring units named explicitly.
- Repeated account names that differ only by whitespace or case count once in directional scores, linked-account context, and CSV account scope.
- Undo restores the last change; reset restores fixtures; refresh retains changes when storage works.
- Invalid saved data remains untouched and blocked from overwrite until the user explicitly confirms Reset sample data.
- Empty or rejected storage recovery uses an isolated copy of the fictional fixtures, so a session edit cannot mutate the source sample used by a later reset.
- Saved group references must be nonblank, trimmed labels; ambiguous whitespace is rejected with the rest of the payload rather than silently normalized.
- No interaction contacts customers or writes to an external system.
Proposed success measures — not observed outcomes
| Measure | Denominator and method | Target | Guardrail |
|---|---|---|---|
| Successful triage | Participants recording a justified decision / five task-study participants | 4/5 unassisted | Status changes alone do not count |
| Time to decision | Median time among successful participants | Under 8 minutes | Explanation quality must not decline |
| Tag clarity | Participants identifying simulated suggestions / all participants | 5/5 | No belief that real AI was evaluated |
| Evidence retention | Original signals retained / selected signals | 100% | No duplicate-account inflation |
Small samples and subjective confidence can mislead. Real customer data would need explicit access and retention decisions before integration.
Concrete Northstar acceptance examples
In the fictional weekly review, a PM searches “row”, selects F01 and F02, and groups them. The result links both records without deleting their quotes. When either linked record is active, its affected-account detail is the unique union of Alder Labs, Finch Studio, Cedar Systems, and Pineworks. The PM can edit the active individual record’s impact, confidence, and effort; F01, for example, permits confidence values of 40%, 60%, 80%, or 100%. At 40%, its individual score is 1.6 (3 accounts × 4 impact × 0.4 ÷ 3 effort); the four-account group context does not alter that score.
The PM may move F01 itself to Planned and optionally write a rationale such as “Validate import recovery before committing.” A rationale is visible editable context, not a gate, and F01 may become Planned while its simulated Onboarding tag remains unreviewed. The tag is supporting context, not a required condition. F04, the saved-report signal, can remain Inbox when the PM does not advance it; the available states are Inbox, Reviewing, Planned, and Declined.
A refresh retains the confirmed local sample state where browser storage is available. Undo immediately restores the most recent saved change. Reset opens a restore dialog and its reset action replaces browser changes with the fictional seed data, after which that replacement can be undone. Exported CSV includes individual Planned records ordered by directional score, labels accounts as belonging to the original record, reports the number exported in the interface, and never contacts Northstar customers. These examples define prototype behavior, not a release promise or observed user result.
Interaction contract: shortlist review
The shortlist is a proposal layer. A reviewer can move a signal to Planned, inspect the original quote and affected accounts, record rationale, and export the planned set for local review. Export scope must be explicit: inbox and declined records are excluded, and no message is sent.
Reset returns the browser to the fictional seed after confirmation. Undo applies only to the most recent saved edit. These controls are intentionally local and do not claim identity-backed recovery.