Scope problems before features

A problem statement should describe a real situation rather than hide a preferred solution. “We need a chatbot” is a solution statement. “New support agents spend a median of 18 minutes finding the current returns policy, causing slow replies and inconsistent explanations” describes a situation that can be investigated.

Use five fields:

1. User: Who experiences the difficulty? Avoid “everyone.”
2. Job: What are they trying to accomplish?
3. Friction: What interrupts or degrades that job?
4. Evidence: What observation, research, or measurement supports the claim?
5. Consequence: What happens to the user or organization?

AI can turn notes into candidate problem statements, identify missing fields, and propose questions. It cannot manufacture evidence. Require it to label unsupported details as assumptions and leave unknown values visible.

An outcome describes a change in behavior or condition. A mechanism describes how the product might create that change. “Reduce time to a policy-grounded first draft from 18 minutes to under 6 minutes” is an outcome. “Add retrieval-augmented generation” is a mechanism.

This distinction protects the team from solution lock-in. A better search interface, clearer policy taxonomy, or workflow change might deliver the outcome more reliably than generation. Ask AI for several mechanisms only after the outcome is explicit. Include a non-AI option in the comparison so novelty does not receive an automatic advantage.

Define both a success measure and a guardrail. The support team might target median draft time while guarding policy-citation accuracy, escalation rate, and customer harm. Speed alone rewards fast wrong answers.

Broad AI concepts combine many capabilities and consequences. “Handle customer support” could mean classifying intent, retrieving policy, drafting a reply, issuing refunds, updating an account, or sending the final response. These are not one feature. They have different data needs, failure costs, and owners.

Break the workflow into observable steps. For each step, ask:

• Is the input available and permitted?
• Is the desired output inspectable?
• Can a person correct it before harm?
• How variable is the task?
• What happens when the model is uncertain?
• Does the step make a recommendation or cause an external action?

A bounded first slice might retrieve approved policy passages and draft an internal reply for agent review. Auto-sending messages or issuing refunds stays out of scope. The first slice still provides value and creates evidence about quality, edits, and exceptions.

“Not in version one” is not an apology. It is part of the product contract. Exclusions align expectations, constrain architecture, and prevent a prototype from becoming an unreviewed production system.

Useful exclusions are specific:

• no automatic refunds, credits, or account changes;
• no answers when an approved source is absent;
• no use of private customer data for unrelated model training;
• no support for legal threats or safety emergencies;
• no customer-facing send without agent approval;
• no languages that have not been evaluated.

Pair each exclusion with safe behavior. A legal threat should route to the existing escalation queue. Missing evidence should produce “source not found,” not a plausible answer. An unsupported language should fall back to the current process.

Once the team has a draft scope, ask an assistant to act as a critic. Provide the evidence and request:

• hidden assumptions;
• users excluded by the framing;
• alternate explanations for the observed friction;
• cheaper non-AI interventions;
• likely scope-creep requests;
• harmful incentives created by the metrics;
• testable questions that would change the decision.

Treat the response as a question generator, not as research. A model may suggest a plausible risk that does not apply, or overlook a domain-specific constraint. The PM verifies each useful challenge with users, operators, legal or security partners, and system owners.

A concise scope card can contain:

Problem: Support agents lose time locating current policy and sometimes use outdated guidance.
Evidence: Ticket observation, search logs, and quality-review findings, with dates and sample sizes.
Target user: Tier-one support agents handling standard returns.
Outcome: Faster policy-grounded drafts with no increase in policy errors.
First slice: Retrieve approved passages and draft for review.
Not included: Sending, refunds, legal cases, and unsupported languages.
Measures: Draft time, citation support, edit rate, escalation rate, and severe-error count.
Decision gate: Proceed only after representative evaluation and workflow review.

The card should be short enough to discuss and precise enough to reject additions. Link every claim to its evidence source in the team’s actual planning system.