Stop filing user feedback into a spreadsheet nobody reads. In Pathmode, Evidence is a discovery play you run to find problems worth solving, and a record of which of them anyone actually judged.
Pathmode used to show evidence as a board you grouped and clustered. It does not any more. Evidence is now an Inbox you work through and a Browse view you audit, and every claim in a spec states its own basis.
The "Evidence-First" Method
Most teams start with solutions. We start with evidence.
Step 1: Define the Product Area
On your workspace home, click New product and scope it to one specific domain. Not "the whole product" but "Onboarding" or "Data Export" or "Team Collaboration."
Bad scope: "All user feedback" Good scope: "Trial-to-paid conversion friction"
Step 2: Capture the Signals
Feed signals into the product area from wherever they live:
- Friction: Support tickets, bug reports, rage clicks
- Quotes: User interviews, NPS comments, sales call notes
- Observations: Session recordings, usability tests
- Metrics: Drop-off rates, time-to-action, error rates
- Requests: Feature requests, workaround reports
Paste them into the composer, import a CSV, TSV, XLSX, or PDF file, or let an agent post them through the API. Every route ends the same way: the signal lands in the Inbox marked Unreviewed, with its type, source, and origin preserved. Capture is not endorsement.
Step 3: State the Problem as a Claim
Before you can decide what a signal proves, you need something for it to prove. Start an intent from a one-field brief and click Draft with agent, or open the intent your coding agent proposed from the request and the codebase. Either way, you start by reviewing a draft: an objective, the outcomes you would have to see, the constraints you cannot break, the edge cases you have to handle. Drafted claims stay suggestions until you keep them. Correct what is wrong, keep what is right, then back the exact claims with reviewed evidence.
A claim is a sentence someone could later argue with. That is what makes it worth backing.
Step 4: Review the Inbox, One Signal at a Time
Each signal gets exactly one of three judgments:
- Use as backing reviews it and anchors it to one exact claim, stamped with your name and the time.
- Keep unreviewed leaves it visible and honest about not having been judged.
- Dismiss takes it out of the working set without deleting the record.
There is no bulk action, and that is deliberate. Backing a claim is a judgment, and a judgment has an author.
Step 5: Read the Spec Back
Open the spec's Evidence section. Every claim now reads Backed, Unreviewed, Assumption, or No evidence. Expand one and you see the exact items behind it with tier, origin, source, and reviewer.
Claims backed by several independent sources are where to build. Claims sitting on one unreviewed note are where to go look. Claims with no evidence are not a failure; they are a fact about the spec that a reader can see.
Stop collecting. Start deciding.
When to Run This Play
| Trigger | Signal |
|---|---|
| Onboarding drop-off | Users sign up but don't activate |
| Feature underuse | You shipped it, no one uses it |
| Support spike | Sudden ticket volume on a topic |
| Expansion stall | Users won't invite teammates |
Anti-Patterns to Avoid
❌ The Junk Drawer: Dumping all feedback into one product area with no domain focus.
❌ The Lone Data Point: Backing an outcome with a single signal and treating the claim as settled.
❌ The Stale Inbox: Capturing signals but never reviewing them. An Inbox nobody works is a spreadsheet with extra steps.
❌ The Assumption Laundry: Treating an AI-drafted assumption as if a person had confirmed it. Pathmode will not let you promote one to backing, and neither should you in conversation.
Next Steps
Ready to run this play?
- Start from scratch: Click New product in Pathmode and follow this method.
- Use a template: Try the SaaS Onboarding Friction Patterns for common friction to watch for.