Discovering the real problem
Discovery examines the experience behind a stakeholder's opening description to understand the real problem, identify contributing conditions, break a complex challenge into manageable parts, and determine whether a platform solution is the right response.
Symptoms are the entry point
Every discovery conversation includes symptoms. These are the visible signals of a broader business challenge, but they may not be the problem that the design must address. Exploring what contributes to them can reveal where the design should focus. The following figure pairs three familiar symptoms with the structural root cause behind each, showing why fixing the symptom alone does not resolve the problem.
The Solution Designer should explore the symptom until stakeholders can describe both the experience it creates and the conditions that allow it to persist.
Working to the condition underneath
Surfacing an underlying cause is a facilitated conversation, not a private exercise. Practitioners can use different techniques, but effective root-cause conversations generally move through three passes.
| Pass |
What the Solution Designer does |
What this helps reveal |
|---|---|---|
| First | Capture the symptom in the stakeholder’s language Listen closely to how the stakeholder describes the experience before translating it into solution or platform terminology. Record that language and reflect it back to confirm your understanding using their terminology. |
Their words reveal what matters to them, how they experience the challenge, and how they may describe success later. |
| Second | Explore what makes the symptom persist Ask what has kept the issue from being addressed. |
The answer may surface process or organizational constraints, such as an unresolved decision or unclear ownership. It may also identify structural constraints, such as disconnected systems or workflows that cannot adapt. These distinctions help you explore what kind of response the challenge requires. |
| Third | Name the underlying root causes Work with business and technology stakeholders to describe the root causes contributing to the symptom in language on which they both agree. |
This becomes the working problem statement that guides the framing conversations that follow. |
Treat the working problem statement as provisional; outcome and scope discussions may reveal evidence that requires it to be refined.
Making a complex challenge more manageable
Business challenges often include several connected needs that are difficult to address all at once. Each may be relevant to the design, but they may not all require the same response or belong in the same release.
Separating the challenge into manageable parts allows the Solution Designer and stakeholders to evaluate each part on its own merits, identify the relationships among them, and determine where the design should focus. The questions below help the team examine a complex challenge part by part, and what each answer may indicate about where to begin and how to sequence the work:
| Question to explore | What the answer may indicate |
|---|---|
| Which part of the challenge is the business experiencing most acutely today? |
The most immediate need can provide a useful starting point. It often has strong stakeholder support and a baseline that helps make the impact visible. |
| Which parts are connected, and which can be considered independently? |
Relationships between the parts reveal where solving one need may also improve another and where separate responses are required. |
| What kind of response does each part require? |
Some needs can be addressed through solution design. Others may require changes in governance, staffing, ownership, policy, or business process. |
| Which parts can be sequenced? |
Sequencing identifies what should be addressed first, what depends on earlier work, and what can be deferred. |
The Solution Designer makes the parts, relationships, and uncertainties visible so stakeholders can evaluate them together. This analysis creates a clearer basis for recommending where the design should focus
Turning the conversation toward outcomes
To clarify the change stakeholders want to achieve, ask:
If this challenge were resolved, what would be different about how the business operates, how customers experience it, and how success is measured?
The intended change may be a focused operational improvement or a broader transformation. Making that distinction explicit establishes the appropriate direction for the engagement.
Outcome-focused thinking does not replace the work of understanding the problem. It gives that work direction.
Assessing fit honestly
Not every business problem is Pega-shaped. During discovery, the Solution Designer works with stakeholders to determine whether a Pega solution can meaningfully contribute to the intended outcome. The following questions help the team judge whether a challenge is worth pursuing and why each consideration matters before the work moves forward:
|
Question to consider |
Why it matters |
|---|---|
|
Is the change strategically important, durable, and valuable enough to justify the investment? |
Short-lived problems rarely justify significant transformation effort. |
|
Is the underlying condition structurally addressable? |
Some constraints require organizational, policy, or governance changes before a solution can help. |
|
Is the business ready to act on what discovery reveals? |
Discovery may uncover changes the business must be willing to make to achieve the intended outcome. |
|
Can a Pega solution meaningfully contribute to the intended outcome? |
Not every problem is best addressed through platform capabilities. |
Together, they help the business stakeholders and the Solution Designer determine whether a Pega solution is the right response and identify a different direction when it is not. Fit also depends on whether stakeholders can describe when meaningful value should begin and whether that timing is credible.
Tip: Assessing fit honestly directs the business toward a response that can meaningfully support its intended outcome and strengthens the Solution Designer’s credibility in the conversations that follow.
Scenario: U+ Travel findings based on discovery
The Solution Designer analyzes the experience behind the double-bookings and identifies the broader challenge: U+ Travel lacks a shared and reliable view of daily operations.
Elena’s operators keep bookings in personal spreadsheets, phone messages, and text threads. To see the inventory for the day, Elena calls three operators and reconciles their answers against a whiteboard. The double-bookings are the most visible symptom, while the broader challenge is the absence of a shared and reliable view of daily operations.
Elena and the Solution Designer evaluate the challenge in manageable parts, identifying four potential areas of focus and the relationships among them.
| Candidate area of focus | Elena’s assessment | Structurally addressable |
|---|---|---|
| Shared inventory visibility | The most immediate need and the area with the strongest sponsorship | Yes, directly |
| Operator coordination during peak season | Closely connected to shared inventory visibility | Yes, directly |
| Customer communication automation | Important to Elena and supported by improvements in inventory visibility | Yes, once shared visibility is established |
| Post-booking service for weather-affected excursions | A potential area for a later release | More complex; it would require access to an external data source that has not yet been arranged |
The Solution Designer then turns the conversation toward the outcome by asking what would be different a year from now if U+ Travel improved shared visibility and operator coordination. Elena describes 30 percent booking growth without adding operators, with operators able to focus more of their time on customers and less on reconciliation.
Her answer provides the starting point for a measurable business outcome. Elena’s initial description provides the evidence that the Solution Designer and stakeholders develop into a clearer view of the challenge, its connected parts, and the change the business wants to achieve.
| How would you respond? |
Which area would you recommend as the initial focus, and what evidence supports that direction? What would you need to understand before determining what belongs in the first release? |
|---|
In practice
Compare your approach to the practices below for exploring symptoms, identifying underlying conditions, and focusing discovery.
| Practice | Why it matters | A question that puts it to work |
|---|---|---|
| Stay with the symptom long enough to understand it | The stakeholder’s language provides the raw material for understanding the challenge and defining the outcome. | Walk me through the last time this happened. |
| Ask what has kept it persistent | Persistence often reveals the constraints sustaining the problem and keeps the conversation grounded in the business’s experience. | What has kept this issue from being addressed? |
| Consider the challenge in manageable parts | Separating the parts with stakeholders builds trust and brings different priorities and perspectives into the open early. | If we addressed this part and not the others, would that create a meaningful improvement? |
| Assess fit candidly | Being candid about where a platform solution can, and cannot, contribute strengthens the credibility of your judgment. | What would need to change here that a system alone could not change? |
| Turn deliberately from problem to outcome | Making the intended outcome explicit gives the design brief direction and establishes what success should mean. | Who benefits when this is resolved, and how would they recognize or measure the improvement? |
A shared understanding of the problem provides the evidence needed to define the measurable outcome the design will serve.
Knowledge check
Check your knowledge with the following interaction.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?