Skip to content

Problem Evidence Validation (PEV)

Stage: Stage 1 - Problem Management

Artifact Code: PEV

1. Purpose

The Problem Evidence Validation (PEV) exists to establish whether the problem described in the PPE is real, observable, and supported by facts.

Its purpose is to replace opinion and assumption with concrete evidence - without explaining why the problem exists or how it should be solved.

2. Decision This Artifact Supports

Decision: Is there sufficient factual evidence to confirm this is a real problem worth assessing?

Possible outcomes:

  • Advance to PAB
  • Revise PEV (insufficient or unclear evidence)
  • Stop (problem not supported by evidence)

If this decision cannot be made confidently, the PEV is not complete.

3. Ownership and Roles

  • Owner: Problem Validation Owner (or equivalent role)
  • Contributors: Investigators, subject-matter participants, reporters
  • Reviewers / Approvers: Stage 1 facilitator

There must be one accountable owner responsible for evidence quality and neutrality.

4. Blank Artifact Template

# Problem Evidence Validation (PEV)

## 1. Problem Restatement
{Short restatement of the problem from user input or PPE. No solutions, no interpretation.}

---

## 2. Evidence Collected
- {Evidence item 1 or "TBD"}
- {Evidence item 2 or "TBD"}
- {Evidence item 3 or "TBD"}

---

## 3. Observations
What was learned while validating the problem.
- {Observation 1 or "TBD"}
- {Observation 2 or "TBD"}

---

## 4. Affected Roles / Departments
- {Role/Team 1 or "TBD"}
- {Role/Team 2 or "TBD"}

---

## 5. Validation Sources
Who confirmed the problem exists.
- {Source 1 or "TBD"}
- {Source 2 or "TBD"}

---

## 6. Confidence Level
{High / Medium / Low}

---

5. Required Inputs

  • A completed Pain Point Entry (PPE) describing the problem

If the PPE is unclear, speculative, or solution-oriented, it must be revised before PEV begins.

6. Input Acceptance Criteria

Before accepting the PPE as input, verify:

  • The problem statement is clear and singular
  • No causes or solutions are implied
  • Scope is well-bounded
  • Language is factual and business-oriented

If these criteria are not met, stop and revise the PPE.

7. Assumptions to Surface

Common assumptions that often sneak into PEV:

  • The problem happens frequently
  • The problem impacts many people
  • The problem is getting worse
  • The problem is already understood

None of these should be assumed without evidence.

8. What Must NOT Appear in This Artifact

The PEV must not include:

  • Root cause analysis
  • Explanations or interpretations
  • Recommendations or next steps
  • Opinions or speculative language

If interpretation appears, the PEV should be rejected.

9. Example - Completed Artifact

# Problem Evidence Validation (PEV)

## 1. Problem Restatement
Customer support agents re-enter the same customer details across multiple systems during a single support case.

---

## 2. Evidence Collected
- Screen recordings from three live support cases
- Average case handling time reports from Q4
- Agent notes submitted via internal feedback form

---

## 3. Observations
What was learned while validating the problem.
- Agents entered identical customer information in three separate systems per case
- The duplication occurred regardless of case type

---

## 4. Affected Roles / Departments
- Customer Support Agents
- Customer Support Operations

---

## 5. Validation Sources
Who confirmed the problem exists.
- Support Team Leads
- Operations Analyst

---

## 6. Confidence Level
High

---

10. Output Quality Checklist

  • [ ] Problem restatement matches the PPE
  • [ ] Evidence is concrete and observable
  • [ ] Observations describe what was seen, not why
  • [ ] Affected roles are clearly identified
  • [ ] Confidence level is justified by evidence

All items must pass to move forward.

11. Common Failure Modes

  • Repeating the PPE without adding evidence
  • Describing opinions as observations
  • Mixing interpretation into observations
  • Inflating confidence without support

These indicate loss of neutrality.

12. Review Questions

Reviewers should ask:

  • What evidence shows this problem actually occurs?
  • Could this evidence be interpreted differently?
  • Is anything being assumed rather than shown?
  • Does the confidence level match the evidence?

If answers are unclear, revise the PEV.

13. What to Do If the Artifact Is Rejected

If the PEV is rejected:

  • Gather additional evidence
  • Remove interpretive language
  • Clarify observations
  • Reduce confidence level if needed

Do not proceed until the evidence stands on its own.

14. Readiness Signal - Moving Forward

The PEV is ready to advance when:

  • Evidence clearly supports the problem’s existence
  • Observations are factual and uncontested
  • Confidence level is agreed upon

Proceed to Problem Assessment Brief (PAB).

15. What Invalidates This Artifact

The PEV must be revisited if:

  • New contradictory evidence appears
  • The problem description changes
  • Validation sources withdraw confirmation

16. Downstream Dependencies

  • Next Artifact: Problem Assessment Brief (PAB)

Weak or biased evidence here will directly distort problem assessment and prioritization.

Reminder: The PEV exists to prove the problem is real - not to explain it.