Skip to content

Pain Point Entry (PPE)

Stage: Stage 1 - Problem Management

Artifact Code: PPE

1. Purpose

The Pain Point Entry (PPE) exists to capture a single observed business problem in plain language, without interpretation or solutions.

Its purpose is to make a reported issue explicit, shareable, and stable enough to validate - not to explain it or fix it.

2. Decision This Artifact Supports

Decision: Should this reported issue proceed to validation?

Possible outcomes:

  • Advance to PEV
  • Revise PPE
  • Stop (non-problem, duplicate, or out of scope)

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

3. Ownership and Roles

  • Owner: Problem Intake Owner (or equivalent role)
  • Contributors: Reporter, affected stakeholders
  • Reviewers / Approvers: Stage 1 facilitator

There is exactly one owner responsible for accuracy and clarity.

4. Blank Artifact Template

# Pain Point Entry (PPE)

## 1. Problem Summary
{Short description of what the user reported. Plain-English. No solutions.}

---

## 2. Who Is Affected?
* {Role/Team or "TBD"}
* {Role/Team or "TBD"}

---

## 3. Initial Evidence (If Any)
* {Evidence or "TBD"}
* {Evidence or "TBD"}

---

## 4. Reporter Information
* **Name:** {Reporter or "TBD"}
* **Team/Department:** {Department or "TBD"}
* **Date Logged:** {YYYY-MM-DD}

---

## 5. Additional Notes (Optional)
{Anything else the user included OR leave blank}

5. Required Inputs

  • A reported issue from a user, stakeholder, or system

No prior artifacts are required.

6. Input Acceptance Criteria

Before accepting inputs, verify:

  • The problem is stated as an observation, not a conclusion
  • No solutions or causes are implied
  • The scope is limited to one problem
  • Language is plain and non-technical

If these conditions are not met, revise before proceeding.

7. Assumptions to Surface

Common hidden assumptions at this stage include:

  • The problem is new
  • The problem is important
  • The problem has a single cause
  • The problem should be solved with software

None of these should be assumed or stated in the PPE.

8. What Must NOT Appear in This Artifact

The PPE must not include:

  • Proposed solutions
  • Root cause analysis
  • Requirements
  • Design ideas
  • Effort or priority statements

If any appear, the PPE should be rejected.

9. Example - Completed Artifact

# Pain Point Entry (PPE)

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

---

## 2. Who Is Affected?
* Customer Support Agents
* Support Team Leads

---

## 3. Initial Evidence (If Any)
* Agent feedback from weekly support meetings
* Average case handling time reports

---

## 4. Reporter Information
* **Name:** Jane Smith
* **Team/Department:** Customer Support
* **Date Logged:** 2025-01-12

---

## 5. Additional Notes (Optional)
Issue has been mentioned repeatedly during onboarding sessions.

10. Output Quality Checklist

  • [ ] Describes an observed problem only
  • [ ] Uses plain, business language
  • [ ] Identifies who is affected
  • [ ] Avoids causes and solutions
  • [ ] Is understandable without explanation

All items must pass to move forward.

11. Common Failure Modes

  • Framing the problem as a missing feature
  • Including guessed causes
  • Combining multiple problems into one entry
  • Using technical or internal jargon

These indicate stage bleed.

12. Review Questions

Reviewers should ask:

  • What exactly is happening?
  • Who experiences this problem directly?
  • What is unclear or assumed?
  • Could two people interpret this differently?

If answers vary, revise the PPE.

13. What to Do If the Artifact Is Rejected

If the PPE is rejected:

  • Ask the reporter clarifying questions
  • Narrow the scope to a single problem
  • Remove solutions or assumptions

Do not advance until clarity exists.

14. Readiness Signal - Moving Forward

The PPE is ready to advance when:

  • Reviewers agree on what problem is being described
  • No solutions or causes are implied
  • The decision to validate is explicit

Proceed to Problem Evidence Validation (PEV).

15. What Invalidates This Artifact

The PPE must be revisited if:

  • New information contradicts the description
  • The reported problem changes materially
  • The issue is discovered to be a duplicate

16. Downstream Dependencies

  • Next Artifact: Problem Evidence Validation (PEV)

Any ambiguity here propagates directly into evidence gathering and validation effort.

Reminder: The PPE exists to make a problem visible - not solvable.