Skip to content

Step 1 - Capture the Problem (PPE)

Purpose

Convert a raw observation into a clearly stated problem without implying a solution.

This step exists to ensure the process starts with reality, not ideas.

When To Run This Step

This step is executed by a person when they identify a business problem that may require investigation, prioritisation, or structured decision-making.

A PPE is the entry point to the Feedback Loops process and should be created when:

  • Something is not working as expected from a business, operational, or user perspective
  • The issue cannot be resolved through routine operational processes
  • There is uncertainty about impact, cause, or next steps
  • The team needs to decide whether the problem is real and worth advancing

What This Step Is Not For

This step should not be used for:

  • Software defects or bugs These should be logged through the standard bug or incident process.
  • Pure implementation tasks with no underlying problem to assess

Feature Requests (Important)

A feature request is not a valid PPE in its original form.

However, a feature request may be converted into a PPE if it can be restated as:

  • a business problem,
  • an unmet need,
  • or an observed limitation in current behaviour,

without prescribing a solution.

If a feature request cannot be expressed as a problem statement, it does not enter the Feedback Loops process.

Key Principle

Feedback Loops always starts with a problem, never with a solution.

If that condition is not met, this step must not proceed.

Inputs (Required)

  • A first-hand observation or reported issue
  • A description of what is happening today
  • Identification of who is affected

No evidence is required at this stage.

Prompt to Run

  • Prompt Name: Pain Point Entry (PPE)
  • Prompt Version: v1.0
  • Prompt Location: PPE Generator

Instruction: Run the PPE prompt using the provided inputs. Do not edit, extend, or reinterpret the prompt.

Outputs (Produced)

The step produces a Pain Point Entry (PPE) containing:

  • Problem summary (plain English)
  • Who is affected
  • Initial evidence (if known)
  • Reporter information
  • Date captured

The output must be written as a standalone artifact.

Artifact Storage

Store the PPE in the predefined system of record selected during setup.

  • One primary location only
  • The artifact must be referenceable (link, ID, or path)
  • Ownership must be clear

Copies may exist, but the system of record is authoritative.

Validation Rules

The PPE is valid only if:

  • The problem is described without proposing solutions
  • The language reflects observation, not diagnosis
  • The scope is narrow enough to be understood by someone outside the team

The PPE is invalid if it:

  • Mentions tools, features, or fixes
  • Assigns blame
  • Assumes root cause without evidence

Invalid PPEs must be rewritten before proceeding.

Decision Gate

Question: Is the problem clearly stated, observable, and free of solution bias?

Outcomes:

  • Yes: Proceed to Step 2 - Validate the Problem (PEV)
  • No: Revise the PPE

No other outcomes are allowed.

Failure Modes & Anti-Patterns

  • Writing a feature request disguised as a problem
  • Using vague language (“users are unhappy”)
  • Collapsing multiple problems into one entry
  • Treating this step as a formality

If this step is rushed, the rest of the process degrades.

Traceability

  • Previous: None (entry point)
  • Next: Step 2 - Validate the Problem (PEV)
  • Produces: Pain Point Entry (PPE)
  • Enables: Problem Evidence Validation (PEV)

Status

  • Maturity: Stable
  • Enforced by Tooling: Planned