Catalogue › Opportunity Management › problem-framing

Problem framing

Turns a raw idea or tool request into a framed business problem with a named business owner, affected roles, current cost, expected outcome and baseline, and politely sends solution-first requests back to the problem. Use when an idea arrives at intake, when someone asks for an agent or Copilot feature before saying what is wrong, or when a pilot cannot say what it was meant to improve.

Department

Opportunity Management

Lifecycle

Envision

Maturity

explorer, adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

platform-neutral

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Opportunity Management plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

This skill is the front door of the opportunity lifecycle. It takes an idea, a complaint or a request for a specific tool and turns it into a problem statement that someone owns, that can be measured, and that later skills can judge. Nothing enters assessment without it. Intake usually goes wrong by accepting "we need an agent for X" as a requirement, by framing problems on behalf of a business that has not agreed it has one, or by skipping the baseline so that nobody can later say whether anything improved.

When to use

• A new idea arrives through intake, a Champion, a manager or a hackathon.
• Someone requests a specific tool or feature ("an agent for onboarding", "Copilot in our case system") without stating the problem.
• A pilot is under way but cannot say what it was meant to improve or for whom.
• Several teams describe what may be the same problem in different words and need one shared framing.

When not to use

• Deciding whether AI is the right answer once the problem is framed - use opportunity-management:ai-suitability.
• Assigning a risk tier - use opportunity-management:risk-classification.
• Comparing framed opportunities against each other - use opportunity-management:opportunity-prioritisation.
• Finding everyday Copilot scenarios for a role during adoption - use copilot-adoption:scenario-discovery.
• Setting organisation-wide outcomes - use ai-strategy:strategic-outcomes.

Questions to ask first

1. What goes wrong today, for whom, how often, and what happens as a result?
2. Who in the business is accountable for this work and would decide that the problem is solved?
3. How is the problem measured now, or what could be counted within a few weeks to establish a baseline?
4. What would be different, and by how much, if the problem were solved?
5. Which strategic outcome, if any, does this contribute to?

Required inputs

• The original request in the requester's own words, kept verbatim on the record.
• Access to the business owner, or to someone who can name them.
• Any existing data about the work: volumes, cycle times, error or rework rates, complaints, staff time.

If no business owner can be named, the opportunity is held at "awaiting owner" and does not proceed; a request without an owner is a suggestion, not an opportunity. If no baseline exists, record how and by when it will be established. Never estimate a baseline and present it as measured.

Decision framework

An opportunity is framed when every row is satisfied. Anything less returns to the requester with the specific gap.

Record an early view of the problem type as a signal for suitability, not a decision. It shapes the conversation and stops "AI" being assumed.

Practitioner approach

Keep the request verbatim, then set it aside. Ask the requester to describe the last time the problem happened: who was involved, what they were trying to do, what went wrong and what it cost. Stories surface the real failure far better than abstract questions, and they often reveal that the requested tool addresses a symptom.

When a request arrives solution-first, acknowledge the idea and redirect to the problem rather than refusing it. "An agent might well help; before we design one, can you walk me through what happens today when a new starter asks about their benefits?" Most people are happy to explain their work. The requested solution is recorded as one candidate for opportunity-management:ai-suitability to test, not as the requirement.

Find the business owner early. The requester is often not the owner; a Champion or analyst may have spotted the problem in someone else's process. Contact the owner, confirm they recognise the problem and accept accountability for the outcome, and record their role on the canvas. If the owner disagrees that there is a problem, the opportunity stops here, and that is a useful result.

Quantify current cost with whatever is available: system volumes, queue times, complaint counts, rework, or a short time sample by the team. Precision matters less than having a reference point that can be measured again later. Where nothing can be counted now, agree a light measurement over two to four weeks and hold the opportunity until it is in.

Write the problem statement in one or two sentences using the owner's words and a measure, and keep technology out of it. "Contract managers spend most of Monday compiling site reports from emails, and a third of reports arrive late" is framed. "We need an agent to write site reports" is not. Then write the expected outcome as a change in that measure.

Capture the opportunity in the backlog as soon as it has an owner, even before it is fully framed. The operating rule is that work with no backlog entry is not a project and gets no resources, which is what turns intake from a suggestion box into a pipeline. At capture the entry carries the business owner, a status, and a first estimated value as a range; the return estimate and priority are added at assessment and prioritisation, never guessed now.

Note the problem type you think you are looking at, and say it out loud to the owner. Hearing "this sounds like a hand-off problem rather than a knowledge problem" often changes the conversation more than any canvas.

Look for duplicates. If another unit has framed the same problem, merge the records and involve both owners; shared problems are often better candidates for reuse. Finally, link the opportunity to a strategic outcome where one fits, note early signs of data sensitivity or external reach for risk classification, and pass the framed opportunity on.

Outputs

• A framed opportunity on the opportunity-canvas template: verbatim request, problem statement, business owner, affected roles, current cost, expected outcome, baseline or baseline plan, strategic fit, early problem type and early risk signals.
• A backlog entry at the capture stage, with owner, status and an estimated value range, on the prioritisation-matrix template's backlog register.
• A short reply to the requester explaining what happens next, or which gap must be closed first.
• Where the opportunity stops, a recorded reason (no owner, no agreed problem, duplicate) and any referral.

Microsoft platform considerations

Not applicable, because a framed problem names no platform. Requested products are recorded only as candidate solutions for opportunity-management:ai-suitability, which checks them against the current source records.

Adoption considerations

How intake treats people decides whether they bring ideas again. Respond quickly, explain gaps in plain language, and credit the person who raised the idea, including Champions who route opportunities. Make stopping a framed opportunity feel like a result rather than a rejection.

Knowledge considerations

Ask where the information involved in the work lives and who keeps it current. Unowned or scattered knowledge is recorded as an early signal for suitability and for knowledge-management:knowledge-inventory; it is often the real problem.

Security and privacy considerations

Note at framing whether the work involves personal, confidential or regulated data, and whether outputs would reach customers or the public. These are signals for opportunity-management:risk-classification, not decisions; framing does not clear any data for use.

Responsible AI considerations

Note whether the work involves decisions about people, money, safety or rights. If it does, flag it on the canvas so risk classification and responsible AI review consider it from the start.

Evaluation requirements

Not applicable to solution testing. The framing is checked by whether the business owner agrees with the problem statement and baseline in writing, and whether a second reader could restate the problem without mentioning a tool.

Value measures

The baseline and expected outcome recorded here are the reference points for every later value claim. The business owner owns them. Measures are of the work and its outcomes, at team or process level, never of individual staff.

Scale notes

Starter

A short conversation and a one-page canvas, completed by the person leading AI with the business owner. Keep the baseline simple; a two-week tally is often enough.

Scale

A standard intake form feeding the canvas, a weekly triage that returns incomplete requests with specific gaps, and a register where duplicates can be spotted.

Enterprise

Business-unit spokes frame their own opportunities on the shared canvas; the hub checks quality and looks for problems framed in several units that suggest an enterprise solution.

Hand-offs

• To opportunity-management:ai-suitability to decide whether AI is the right answer.
• To opportunity-management:risk-classification once a candidate pattern is chosen.
• To copilot-adoption:scenario-discovery when the problem is clearly about individuals using tools they already have.

Reviewer gates

Not applicable. Framing is an intake step and releases nothing; reviewer gates apply after risk classification.

Failure modes

• A tool request is accepted as the requirement, and the solution is built for a problem nobody defined.
• The requester is recorded as owner, leaves or loses interest, and the solution is orphaned.
• No baseline is taken, so the benefit can never be demonstrated and the initiative cannot be judged at scale-or-stop.
• Framing becomes a bureaucratic hurdle, and people route ideas around intake.
• Ideas agreed in meetings never reach the backlog, so work starts with no owner, no baseline and no record.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Accept a technology or product as the problem statement.
• Advance an opportunity without a named business owner who agrees the problem exists.
• Invent or estimate a baseline and record it as measured.
• Dismiss a solution-first request without helping the requester describe the problem.