I’d like to suggest an improvement to how we capture prompts in Pega Blueprint.
Today, the prompt is entered into the Functional Description section. In my experience, that framing encourages solution designers and builders to describe what the application should do—but not always why it is needed or what success should look like.
Three important pieces of context can get left out:
- The business problem: What is happening today that needs to change? Who is affected, and what is the business impact?
- The desired outcomes: What specific results are we trying to achieve—not just what functionality do we want to build?
- The metrics we want to improve: What is the current baseline, and what measurable improvement are we targeting?
For example, “Build an application to manage customer service requests” describes functionality. A richer prompt would also explain the underlying problem—such as inconsistent routing or slow resolution—and identify the desired outcomes and the measures that will demonstrate success.
A suggested improvement
Rather than relying on one Functional Description field, could Blueprint guide users through a more structured set of inputs?
- Business Problem / Current-State Challenges
- Desired Business Outcomes
- Success Metrics — Current Baseline and Target
- Functional Description
These could be lightweight guided prompts rather than mandatory fields. Where a baseline or target is not yet known, users could identify that gap rather than skip the topic entirely.
The goal isn’t to make prompting more complicated. It’s to help us define the problem before designing the solution, and connect the resulting Blueprint to the business value we intend to deliver.
I’d welcome the Circle’s perspective:
Would this structure improve your Blueprint conversations?
How are you incorporating business problems, outcomes, and measurable success into your prompts today?