What Law & Order marathons taught me about requirements that Jira never did
How a crime drama obsession led to a better way of validating what we build
The Evidence Box, the hub of the Proof Sprint method didn’t come from agile ways of working. It came from crime procedurals.
I’ve watched way too much Law & Order: SVU. There’s a scene in almost every episode where detectives gather around a giant evidence board. Photos. Strings. News clips. Witness statements. Suspects. Everything visible. Everything connected.
It wasn’t the drama that got me. It was the system of sharing information.
No one was texting about crucial updates. No one wondering, “Didn’t you get my email?”
Every insight lived on the board. One place. One view. One shared truth.
Meanwhile, at work, I was drowning in stakeholder emails, Slack threads, and meeting notes in five different places. My requirements documents were already outdated by the time they were approved.
I wondered: What if business analysis worked more like detective work?
How I accidentally built this
For years, I kept a running “brain dump” document for my projects.
It wasn’t a methodology. It was survival. A way to keep my head above the water.
I threw everything into it. Requirements, yes, but also contradictions, offhand comments, things I wasn’t sure were important until they came up again.
At some point, I realized I was unconsciously sorting things into three piles:
What we think we know about the problem
What people actually do
What we’ve tried and learned
When I started sharing this method with my peers, they said it helped them think more clearly. Feel more grounded. Be more confident in pushing back.
That’s when I knew it wasn’t just a personal system.
It’s not just a document
The Evidence Box isn’t a form or a framework. It’s a shared surface. A Miro board, a Notion page, a Confluence page, or a paper taped to the wall. It doesn’t matter.
The magic comes from making your discoveries (and linked evidence) visible to everyone at once.
No more “did you read the doc?”
No more version control.
It’s three columns. Four sections in each.
Problem Evidence on the left
User Behavior in the middle
Solution Tests on the right
Each section forces you to separate fact from assumption, observation from opinion, results from intention.
Contradictions stop being confusing. They start becoming valuable.
When contradictions create insight
Let’s say the Sales leader says: “Sales reps are wasting too much time writing emails. They need AI help.”
You start filling the Evidence Box.
Problem Evidence: Stakeholder says writing is the issue, but your interviews show reps spend more time deciding and prioritizing than writing.
User Behavior: You observe reps skipping AI summaries. Ignoring Smart Compose. Forwarding emails to themselves as reminders.
Solution Tests: You pilot an AI writing assistant. It flops. Reps say one bad suggestion kills trust. But a prioritization feature? It sticks.
That’s when the real insight clicks. The root problem isn’t writing speed. It’s triage.
The reps aren’t struggling to write emails. They’re overwhelmed deciding what matters.
That clarity only emerges when you lay claims, behavior, and outcomes side by side. The tension between them reveals the truth.
Why three sections work
Each section checks the others.
Problem Evidence shows what people believe the problem is. But it forces the follow-up: “What do we know for sure?”
User Behavior often says otherwise. Stakeholders think writing is slow. Observations show reps are actually stuck in decision loops.
Solution Tests close the loop. AI writing support gets ignored. But triage tool pilots gain traction.
The contradiction becomes your compass. It helps you pivot early, before wasted effort becomes sunk cost.
Your professional insurance policy
Here’s what we often get wrong about senior stakeholders: They don’t actually want status update decks. They just need a single source of truth.
The Evidence Box becomes that source.
New stakeholder? Send them the Evidence Box.
Executive update? Show them the Evidence Box.
Six months later, someone questions a decision? The Box explains the “why.”
But the real value is in tough moments.
Let’s say a senior stakeholder has a strong opinion about what to build, but no solid evidence to prove the business need. In traditional requirements work, you have two bad options: Push back (and be labelled “the difficult one”), or build it (and hope it works).
With the Evidence Box, you can say: “Let’s add that to ‘what we suspect matters, but needs validation.’ We haven’t found supporting data yet, but it’s captured as an important consideration.”
You acknowledge them. You show your process. You hand them the choice with visibility into the risk.
Later, if you must build it and it fails? No finger-pointing. Everyone can see what was known, what was assumed, and what was decided anyway.
This isn’t about being right or wrong. It’s about showing your reasoning.
The hypothesis advantage
In the Evidence Box, I call business problems "hypotheses" until proven to be true.
Why hypothesis?
Problem statements are only statements when proven. Until then, they are just something we think might be true.
That shift does more than protect your credibility. It creates room for discovery.
If you’re wrong, it’s not a failure. It’s a win. You investigated and learned.
Picture this scenario
You’re three weeks into what seemed like a straightforward project. Your stakeholders are pulling you in different directions. Your users are complaining about issues no one mentioned earlier. Your dev team is asking for clarity you don’t have.
So you pause. You create the Evidence Box. You fill it with what you’ve got.
Stakeholder claims land in Problem Evidence.
User friction goes in User Behavior.
Solution ideas and quick tests slot into Solution Tests.
Within a few hours, patterns start emerging.
Maybe everyone’s been focused on one loud complaint when the root cause is elsewhere.
Maybe that half-baked fix from last week revealed the real issue.
The Box doesn’t give you answers, but it organizes the chaos so you can ask better questions and find clearer answers.
From chaos to institutional memory
Institutional knowledge doesn’t just get lost between sprints. It evaporates between people.
That’s why teams repeat mistakes. If the “lessons learned” doc is 10 pages, no one reads it, and even fewer understand it.
The Evidence Box changes that.
When you move on from a project, the Box shows what was built, why it was built, and what was learned along the way.
It turns experience into reusable insight.
You don’t start every project from zero. You start with a trail of proof.
Start before you're ready
You don’t need permission.
Pick your tool: Miro, Notion, Confluence, Google Docs.
Create three sections: Problem Evidence. User Behavior. Solution Tests.
Fill it in as you go. You don’t need perfect evidence. Just a place to capture and document what you’re learning.
The first time you show it to a stakeholder, they’ll nod.
The second time, they’ll start showing up with better inputs.
The third time, they’ll ask: “Can we use that format again?”
Until next time,
Pragati
The Evidence Box is the hub of the Proof Sprint method: a lean toolkit for validating assumptions before building solutions.
Curious how this plays out on real projects? Join a free Proof Lab.
For business analysts, product thinkers, and leaders who know: Shipping isn't the hard part. Knowing what's worth building is.
This adds solid proof that this actually works.