What is the Evidence Board?
The Evidence Board is Pathmode's input surface for collecting user friction. It's where raw signals — support tickets, user interview quotes, analytics anomalies, feature requests, behavioral observations — get captured, tagged, and organized before they feed into intent specs.
Think of it as the structured intake layer between "users are complaining about something" and "here's a precise spec for what to build."
Why evidence, not ideas
Most product tools start from ideas. A PM has a feature concept, writes it up, and the team builds it. The problem: ideas are opinions. They're disconnected from the user problems they claim to solve.
Evidence-backed development inverts this. You start from what users actually experience — the friction, the workarounds, the complaints — and compile that evidence into specifications. The evidence creates accountability: every intent spec links back to the user signals that justify its existence.
Evidence types
The Evidence Board supports several evidence types, each capturing a different kind of signal:
- Friction — a specific user pain point observed in behavior or reported in feedback ("users click the back button 3 times trying to find account settings")
- Quote — a direct statement from a user interview, support ticket, or review ("I gave up after 10 minutes and just emailed your team instead")
- Observation — a pattern noticed by the team through analytics, session recordings, or direct observation ("40% of users never complete onboarding step 3")
- Metric — a quantitative signal from analytics or monitoring ("checkout abandonment rate increased from 12% to 23% after the redesign")
- Request — a feature request or enhancement suggestion from users or stakeholders ("can we export reports as PDF?")
Each piece of evidence can be tagged with severity, linked to a space (product area), and connected to the intent specs it informs.
From evidence to intent
The Evidence Board isn't a place where evidence goes to die (like most research repositories). It's an active input surface. When you see a pattern — multiple evidence items pointing at the same friction — you can compile them into an intent spec directly.
This workflow ensures that specs are grounded in reality rather than assumption. The evidence stays linked, so anyone reviewing the spec can trace back to the original user signals and evaluate whether the proposed solution actually addresses the problem.