Pega Express Methodology
What the exam tests
Pega Express Methodology questions check whether you can frame work around business outcomes rather than a requirements list. The exam expects you to know the four phases - Discover, Define, Build, Evolve - and the artifacts each produces: personas, microjourneys, case types, and a minimum lovable product (MLP) scope.
Core rules
- A microjourney is one focused path to a single outcome for one persona; it becomes the case type's primary stages.
- Discover captures objectives, personas, and candidate microjourneys through Direct Capture of Objectives (DCO).
- Define elaborates the selected microjourney: stages, data, channels, and integration needs.
- Build configures in App Studio in short increments; Evolve measures outcomes and extends scope.
- Pega Express favors an MLP over a bare MVP: the first release must be useful and lovable, not merely functional.
- Roles are explicit: the Business Architect owns the microjourney and business logic; the System Architect owns architecture and guardrails.
Worked example
A utility wants to reduce outage calls. In Discover, the team identifies the "Residential Customer" persona and the "Report an outage" microjourney. Define maps four stages: Report, Assess, Dispatch, Restore. Build configures the case type and a work queue for dispatchers. Evolve adds proactive SMS updates after measuring call volume. The reasoning: scoping to one microjourney keeps the first release small while the outcome - fewer calls - stays measurable.
Traps
Treating Pega Express as waterfall and demanding complete requirements in Discover; confusing MVP with MLP; folding several personas into one bloated case type; skipping DCO and documenting later; letting Build start before the microjourney's outcome is agreed.