Microsoft AI: shape the problem before you build

Key insights

• Treat “we need an AI agent” as a proposed solution, not a defined business problem.
• Gate 1 requires a business problem, baseline and target, sponsor and owner, and a choice of approach.
• Use fixed-rule automation for structured inputs and repeatable steps; consider AI for free text, judgment or changing paths.
• A person can review AI-drafted replies when errors could affect customers.
• If a gate fails, pause and address the gap rather than moving to the next stage.

Microsoft AI projects are easier to assess when teams define the business problem and a measurable outcome before choosing a tool. This approach matters to business owners, makers and IT teams deciding whether to use AI, traditional automation or a combination. Suparna Banerjee lays out this problem-shaping approach in a practical article about moving Microsoft AI initiatives toward production.

What it does

Problem shaping turns a broad request such as “we need an AI agent” into a specific problem that a team can assess. The distinction matters because a proposed tool does not explain who needs help, what is slowing work down or what result would count as success. Teams can then compare possible solutions against the work instead of assuming that AI is the answer.

The approach uses five decision gates across the path to production. The first asks whether the problem is shaped and worth solving; the second checks whether the team selected the simplest fit. Later gates cover guardrails, build readiness and production readiness. A failed gate means the team should stop and fix the gap before proceeding.

For the first gate, the article says teams should describe the problem in business terms, establish a baseline and target, identify a sponsor and business owner, and decide whether the solution needs AI, automation or both. This puts the outcome and accountability ahead of the technology choice.

Who it is for and what you need

This method is aimed at teams exploring an AI or automation initiative, including the business people who own the process and the technical people who may build and support a solution. It is useful before comparing Microsoft tools because the discovery questions include who will use the solution, how many users there are, what licenses they already have and whether the need is seasonal or ongoing.

The source does not specify a required Microsoft license, product plan, tenant setting, region or rollout stage for this planning approach. It is not a product feature that must be enabled in a particular menu. Microsoft’s Cloud Adoption Framework materials and Copilot Studio guidance are listed as further reading, but the source does not state that following this method requires a specific service.

Teams should also know where relevant data lives and who owns it, which systems the solution must read from or act on, and what a wrong answer could cost. Those answers inform the boundaries of the proposed solution; the article does not provide a detailed security or governance configuration.

How it works

Start discovery with questions about the present process rather than jumping to a design. The source groups these into basics and deeper questions, including where bottlenecks occur, who the users are, how success will be measured and who will build, own and support the result.

1. Write down the business problem, users and current bottleneck. Avoid using a product name as the problem statement.
2. Establish how the process performs now and set a target. Without a baseline and a way to measure success, the team cannot evaluate whether the change helped.
3. Map the required information and actions. Identify data locations and owners, systems the solution must read from or update, and the consequences of an incorrect result.
4. Compare the work with simpler options. Fixed rules and structured inputs may suit traditional automation; free-text requests, judgment and changing paths may justify AI. A predictable process can also contain one AI step.
5. Review Gate 1 before selecting a tool. Proceed only when the problem, measure, sponsor and owner are clear and the team has chosen an appropriate approach.

Banerjee’s illustrative customer-support example shows how discovery can narrow an open-ended request. Rather than building an agent for support in general, the example focuses on order-status emails that take about eight minutes to answer. The proposed design reads the request, looks up order data through a read-only connector, drafts a reply and leaves a person to review and send it.

The example sets a target of reducing handling time to under one minute, but the article explicitly labels its figures illustrative, not customer results. Its value is the reasoning: constrain what the system can do, keep human review where a wrong answer matters, and define a measure tied to the original work.

Limitations and open questions

The article gives a discovery framework, not implementation instructions. It does not provide product configuration steps, a cost estimate, a licensing comparison, or detailed guidance for data access and governance. Teams need further assessment before they can determine architecture or production readiness.

The approach also does not claim that AI is preferable whenever a workflow involves language. Its contrast is between predictable, structured work that can use fixed rules and cases involving free text, judgment or paths that can change. The support example includes human review, while another example pairs Power Automate with a structured new-starter request and fixed approvals.

How much accuracy, review effort or cost is acceptable depends on the specific process; the source does not set thresholds. It does provide a practical stopping rule: if the success measure, owner or appropriate approach is unclear, do not treat the idea as ready to build.

Sources

• Microsoft Cloud Adoption Framework: AI adoption
• Microsoft Cloud Adoption Framework: Plan for AI adoption
• Microsoft Copilot Studio guidance
• Suparna Banerjee’s problem-shaping article

Frequently asked questions

What should a team define before building a Microsoft AI solution?

Define the business problem, users, current baseline, target, sponsor and business owner. Also identify the data, systems, consequences of errors and whether AI is needed.

When should I use AI instead of Power Automate?

The source suggests traditional automation for structured inputs and fixed, repeatable rules. AI may fit free-text requests, judgment or changing paths; some processes can combine both.

Does this approach require a specific Microsoft license?

No required license is specified. The discovery questions include checking which licenses users already have, but the article does not provide a license or plan requirement.

What is Gate 1 in the AI project process?

Gate 1 checks whether the problem is shaped and worth solving. Move forward only with a business-defined problem, baseline and target, named sponsor and owner, and a decision about AI versus automation.