Stop Asking 'What's the Problem?': What Is AWS AI BPR?
I recently had an opportunity to learn about AWS AI BPR. When I have worked on AI projects, I have often started by identifying problems and bottlenecks and then adopted established business frameworks such as design thinking or systems thinking. That is why the title of the official AWS article, “The Day We Stopped Asking ‘What’s Your Problem?’,” struck me as remarkably fresh. This article began with my desire to understand how that approach changes the conventional way of running a project.
AWS AI BPR, or AI-driven Business Process Re-Engineering, does more than use AI to make problematic tasks more efficient. It begins with the value and strengths an organization already delivers, then restructures business processes around AI agents. AWS presents it as a four-to-five-hour program.[1]
Using the official AWS article as a starting point, this article examines AI BPR and how to apply it to a real AI project.
What Is AWS AI BPR?
AWS AI BPR is a business transformation method for clarifying the value that must be protected and redesigning the roles of people and AI, rather than simply replacing troublesome work with AI.
A conventional AI project often follows a sequence like this:
- Visualize the current operation
- Identify problems and bottlenecks
- Develop an AI-based solution
- Measure the effect with KPIs
This sequence is not inherently wrong. It is effective when the target is clear and the problem can be solved through known methods. However, when a transformation involves anxiety about handing work to AI or reluctance to change areas of responsibility, presenting a rational solution may not be enough to create movement.
AWS’s initial program also used a problem-solving sequence of goal setting, bottleneck identification, solution development, and simulation. AWS explains that it rebuilt the framework after outcomes stayed within the range of solutions participants already expected or returned to the conclusion that people should continue doing the work.[1]
The important point is that AI BPR does not ignore problems. It does not make the problem the first question. It first establishes which value the organization wants to strengthen. Participants then reconsider the elements of the work and choose what to delegate to AI and where people should become more capable.
Why Begin with Strengths Instead of Problems?
When participants are asked, “What is the problem?” they search for flaws and waste in the current operation. The resulting ideas tend to improve the operation as it already exists: shortening processing time, reducing manual entry, or making search faster.
The basis of discussion changes when the questions become, “Why do customers choose us?” and “Which value must we not lose?” Instead of looking only at a problem such as slow report production, a team can begin with the value of helping frontline staff make decisions sooner and keeping commitments to customers. That opens the possibility of redesigning information collection, judgment, and communication as a whole, rather than improving one part of a report.
AWS summarizes the redesigned AI BPR around three characteristics.[1]
- Strengths-based starting point: Find existing customer value and organizational strengths, then consider how to amplify them
- Psychologically safe role shifting: Let participants choose whether to delegate work to AI or raise the value of the human role
- Immediate feedback: Produce artifacts during the conversation and test the hypothesis on the same day
My main takeaway is that problem analysis and a strengths-based approach do not have to be competing choices. The observation, relationship mapping, and hypothesis testing developed through design thinking and systems thinking remain useful. Changing the opening question, however, can prevent the analysis from being limited to repairing today’s defects.
Understanding the Four Steps in Plain Language
The rebuilt AI BPR proceeds through four steps: Observe, Shift, Simulate, and Forecast. Including the standard times published by AWS, the process can be summarized as follows.[1]
| Step | Plain-language meaning | Main activity | Standard time |
|---|---|---|---|
| Observe | Find what matters | Map operations, customer value, strengths, and risks | 40 minutes |
| Shift | Rearrange roles | Break down the work and choose what AI should take on and where people should excel | 50 minutes |
| Simulate | Run a small test | Prototype the transformation scenario and evaluate changes in quality and impact | 60 minutes |
| Forecast | Turn it into a plan | Define the next experiment, owner, deadline, and decision criteria from the evaluation | 20 minutes |
Observe: Look at Value Before Workflow
Use interviews and existing materials to clarify who receives value, what that value is, and which judgments or experience sustain it. The workflow still matters, but the point is to connect each activity to strengths and risks rather than merely produce a task inventory.
Shift: Choose the Roles of People and AI Again
Break the work into smaller units and assess each one with questions such as:
- Can it be delegated to AI without damaging value?
- Can AI help people deepen their expertise?
- Which decisions must remain under human responsibility?
- Who intervenes during an exception, and how does recovery work?
Do not decide only on the basis of whether automation is possible. Redesign roles with value, accountability, and exception handling included.
Simulate: Build a Working Hypothesis, Not a Presentation
Test the selected scenario with safe sample data modeled on real data or within a tightly limited area of the operation. The goal is not to build the completed system. The goal is to learn whether it works with ambiguous inputs, who can judge its quality, and whether human effort actually moves to higher-value work.
Forecast: Turn PoC Impressions into the Next Decision
Use the simulation results to decide what to test next. Define not only an owner and deadline but also the conditions for continuing, revising, or stopping. This prevents the work from ending with “that was a good demo” and allows the team to evaluate both technical feasibility and business transformation.
How to Apply It to a Real AI Project
Connecting the four AWS steps to project decisions matters more than reproducing the format mechanically. I think the following six-stage interpretation makes the method easier to apply in practice.
1. Describe the Transformation Target as One Customer Value
Do not define the target only as a department or operation, such as “sales work” or “customer support.” Express it as the intended value, such as “reduce uncertainty before a customer receives the first response.”
2. Put Decision-Makers and Practitioners in the Same Room
When executives, operations specialists, or technologists work alone, value, practicality, or accountability will be missing. Include people who know the work, people who can approve a change, and people who can explain AI’s limitations.
3. Map Strengths, Value, and Risk on One Observe Sheet
For each activity, record more than the task itself.
| Item | Example question |
|---|---|
| Customer value | Whose decision does this work help, and how? |
| Strength | Why do customers or other teams trust this work? |
| Tacit knowledge | What signals do only experienced staff notice? |
| Risk | What is lost when an error, delay, or outage occurs? |
4. Use Four Role Categories During Shift
Avoid reducing every decision to “automate” or “do not automate.” Classify roles into AI execution, AI advice to a person, human-AI collaboration, and decisions retained by people. This supports gradual designs, such as keeping high-risk decisions with people while moving information gathering and option generation to AI.
5. Test the Smallest Transformation Scenario During Simulate
The first test should measure changes in the overall operation, not only model accuracy.
- Did time or quality connected to customer value improve?
- Did the human review burden decrease, or did it move elsewhere?
- Could the process stop and recover safely during an exception?
- Can practitioners accept their redesigned role?
6. Document the Next Investment Decision During Forecast
Create a one-page record of the test to run over roughly the next 30 days, its owner, required data, security and legal reviews, and success conditions. Separate technical indicators from business indicators. In addition to response accuracy, for example, measure time to first response and escalation rate.
Points Not to Overlook During Adoption
A Strengths-Based Start Does Not Hide Problems
If a strengths focus is interpreted as discussing only positive topics, structural problems and conflict will be missed. Observe must make risks visible, and Simulate must test failure conditions. Strength is the entry point for discussion, not a reason to weaken validation.
A Successful AI Demo Is Not a Successful Business Transformation
Even when a prototype works, it is not ready for production if data updates, permissions, auditability, incident response, and operating costs remain unresolved. Simulate should examine the human roles required for operation, not only attractive outputs.
Adopting AWS Services Is Not the Objective
AI BPR is a method offered by AWS, but the first decisions concern the value to protect and the roles to change, not service names. Technology choices follow from data, security, the existing environment, and operational capability.
Four to Five Hours Does Not Complete the Transformation
The short program produces a transformation scenario, prototype, evaluation, and next plan. Organizational rollout, governance, training, and continuous evaluation still require separate work. The workshop should be treated as a starting point for faster decisions, not the finish line.
Summary
The distinctive feature of AWS AI BPR is not the use of AI itself. It is the decision to change the order of the questions.
- Begin with the value to protect and amplify, not with problems and bottlenecks
- Choose not only the work to hand to AI but also the work where people should excel
- Simulate during the session instead of stopping with a proposal
- Connect PoC results to the next investment decision and execution plan
For me, “The Day We Stopped Asking ‘What’s Your Problem?’” does not reject the design thinking or systems thinking I have used before. I see it as a prompt to change the question that comes before observation and structural analysis, expanding an AI project from a small efficiency improvement into a redesign of business value.
In the next AI project, before asking, “What is causing difficulty?” try asking, “Which value do you want to keep delivering to customers?” and “When AI joins the process, where do people want to focus?” That small change is a practical way to begin applying AI BPR.
References
- Amazon Web Services, AI-driven Business Process Re-Engineering: The Day We Stopped Asking “What’s Your Problem?”, April 21, 2026