01
Start with the problem
Describe the situation in your own words. You do not need everything at once. Pinkgarden structures who is affected, how the process works today, the consequences, and what success looks like.
ExampleCreate a new discovery project.
Our customer support team receives around 500 emails every day from customers asking for the status of their orders in SAP. Agents currently open SAP, find the order, and reply manually.
Or start simplerWe spend too much time answering customers who want to know where their SAP orders are.
Then askHelp me explore the problem before we discuss solutions.
Or start from a recording or a whiteboard
Upload a Zoom or Teams transcript, or photos of a whiteboard. Add a short prompt and Pinkgarden will structure the problem so you can keep going.
TranscriptHere’s the Zoom transcript. Create a discovery project and structure the problem.
WhiteboardHere are whiteboard photos. Turn these into a scoped use case.
02
Develop Discovery through conversation
Add detail as you learn more. Ask what is still missing. Ask Pinkgarden to challenge your assumptions. Discovery becomes an iterative conversation, not a form you complete up front.
Add factsThe main users affected are customer service agents.
Each request takes approximately five minutes to process manually.
Find gapsWhat information are we still missing before the Discovery is complete?
ChallengeReview the Discovery critically. What assumptions are we making?
OrAsk me the most important questions we should answer before designing a solution.
03
Explore alternative use cases
Once the problem is clear, do not settle on the first idea. Ask for alternatives, compare them, then choose one as the basis for deeper work.
PromptBased on the Discovery, propose three different use cases that could solve the problem.
You might get
Reactive automationRetrieve SAP order status automatically when a customer contacts support.
Proactive communicationNotify the customer when the order reaches important milestones.
Self-serviceLet customers retrieve their current order status themselves.
CompareCompare these alternatives based on business value, complexity, and impact on the current process.
SelectLet’s continue with the reactive automation use case.
04
Describe your system landscape
Tell Pinkgarden which systems matter. It uses that context to evaluate what you can do with what you already have, and where something new may be needed.
LandscapeWe currently use SAP S/4HANA for order management and ServiceNow for customer service.
Optional platformSAP BTP is available but isn’t currently used for this process.
Then askBased on these systems, what solution options do we have?
OrCould this be solved using only our existing systems?
05
Identify what the solution needs to do
Stay on business capabilities before APIs or architecture. Separate what the solution must accomplish from how it will be built.
PromptWhat capabilities are required to automate this use case?
- Identify the customer
- Identify the relevant order
- Retrieve current order status
- Determine the response
- Respond to the customer
- Handle missing orders
ChallengeAre we missing any capabilities for exceptions or error handling?
ScopeWhich capabilities are essential for the first version?
06
Run a Fit / Gap analysis
Compare the required capabilities with the systems you actually have. See what is supported, what is partial, and where something new is required.
PromptRun a Fit / Gap analysis for this use case using SAP S/4HANA and ServiceNow.
FocusShow me only the gaps.
ExplainExplain why retrieving order status is only considered a partial fit.
ExploreCould SAP BTP close any of these gaps?
ChallengeBe critical. Are we introducing unnecessary custom development?
07
Explore the integration
Once capability fit is understood, move into how the systems work together. The conversation shifts from business design toward solution architecture.
PromptHow could ServiceNow retrieve the order status from SAP S/4HANA?
ValidateCheck whether the systems have interfaces that support this design.
AlternativesCould this be event-driven instead of requesting the order status every time?
CompareCompare the API-based and event-driven approaches.
08
Capture uncertainty instead of guessing
You do not have to resolve every question immediately. Make unknowns explicit as open questions, assumptions, or decisions. The design can mature without turning guesses into facts.
Open questionWe don’t know yet whether SAP exposes the required event. Create this as an open question.
AssumptionAssume for now that ServiceNow can identify the SAP customer, but record that assumption.
DecisionWe need the SAP architect to decide whether BTP should be part of the integration. Track that as a decision.
ReviewShow me all open questions and decisions for this use case.
UpdateThe architect has confirmed that BTP must handle the integration. Update the decision.
09
Check the solution against architecture principles
Before you finalize, challenge the design against your organization’s policies. Connect the individual use case to enterprise architecture and governance, including Clean Core.
PromptReview the proposed solution against our architecture policies.
Clean CoreDoes this solution comply with our SAP Clean Core policy?
ConflictsShow me any policy conflicts.
RemediateSuggest an alternative architecture that complies with the policy.
10
Create the specification
When the important questions are answered, turn the accumulated work into a specification. It is not generated from a single prompt. It is built from everything established in the conversation.
PromptCreate a functional specification for this use case based on everything we have established.
RefineShow me the main flow.
Add the exception where the SAP order cannot be found.
Add the security requirements.
Make the integration responsibilities between ServiceNow, BTP, and SAP explicit.
Add acceptance criteria for the complete flow.
Final checkReview the specification and identify anything that is still ambiguous or missing.
