Framing Business Requests as Decision-Centered Problem Statements

Hello — this course begins with the part of engineering work that code agents cannot reliably do for you: deciding what problem is worth solving before producing a plausible implementation.

In ambiguous startup work, requests often arrive as a proposed solution: “build an agent,” “add an LLM workflow,” “improve the dashboard,” or “research this market.” Claude Code can turn such a request into a coherent plan and a large diff very quickly. But fluency is not evidence that the request represents the right problem, user, or decision. Your job at this stage is to make the decision explicit and make the problem legible enough to investigate.

By the end of this lesson, you will be able to turn a broad request into a decision-centered problem statement: a compact statement that identifies the decision, the affected people, their current difficulty, the business consequence, and the observable outcome that would justify action.

---

Start with the decision, not the requested artifact

Consider these requests:

• “Build a research agent for the sales team.”
• “Use an LLM to reduce support workload.”
• “Create a dashboard for customer health.”
• “Investigate why users churn.”

Each sounds actionable, but none yet says what someone needs to decide. They name an artifact, technology, or activity—not the decision that should be improved by the work.

A decision-centered framing starts with a question such as:

What decision will this work enable, and what evidence would make that decision rational?

For example, the request “build a research agent for sales” might conceal several materially different decisions:

1. Should the company invest in reducing the time sales representatives spend preparing account briefs?
2. Is the central problem speed of research, or trust in the claims included in the brief?
3. Should the team pilot a workflow for a specific sales segment before building a general platform?
4. Is the bottleneck actually missing CRM data rather than web research?

Each decision calls for different evidence, different experiments, and potentially different systems. If you delegate immediately, an agent may select one interpretation and implement it confidently. That is not necessarily bad engineering; it is unvalidated product judgment.

A useful distinction:

Level	Example	Why it is insufficient alone
Requested solution	“Build a research agent.”	Assumes an agent is the right intervention.
Business aim	“Help sales close more enterprise deals.”	Directionally useful, but too broad to act on.
Problem	“SDRs cannot assemble trustworthy account context quickly enough before outreach.”	Identifies a specific obstacle, but needs a decision and outcome.
Decision-centered problem statement	“Decide whether to invest in reducing trustworthy account-research time for enterprise SDRs, based on evidence that the current process delays or weakens outreach and that improvement would change a business-relevant outcome.”	Creates a basis for investigation and a later go/no-go choice.

The statement does not need to prove the case. Its function is to state the proposition that needs to be investigated without quietly hard-coding a favored solution.

---

Separate the opportunity from the first solution idea

The Silicon Valley Product Group describes an opportunity through three questions: the problem, the target persona, and how success will be recognized. Its important warning is that a proposed feature and the underlying problem should be separated, because the first solution may fail while the problem remains.

For internal ML and platform work, replace “customer” with the relevant user or decision-maker. A customer might be an external buyer, but it could also be a support specialist, analyst, account executive, researcher, or on-call engineer. The key is to identify the person whose work is currently impaired—not simply the colleague who submitted the ticket.

The “job” matters as much as the persona. “Sales team” is not a job. “An SDR preparing a credible first outreach message for a named enterprise account” is much closer. It places the work in a context where you can observe a failure mode and measure whether it improves.

---

The anatomy of a decision-centered problem statement

A strong statement answers five questions in a small amount of prose.

1. Decision — What choice should the organization be able to make?
2. Affected user — Whose work, behavior, or outcome is impaired?
3. Job and context — What is that person trying to accomplish, and when?
4. Current failure and consequence — What goes wrong today, and why does it matter?
5. Desired outcome — What observable change would justify action?

A practical template is:

By [decision date or trigger], decide whether to [invest, pilot, prioritize, stop, or change something] for [specific user group].
These users need to [job in a context], but currently [observable failure], which causes [business or user consequence].
We will regard the problem as worth acting on if [observable outcome or decision-relevant signal] can be achieved.

Notice what is absent: framework choices, model providers, orchestration libraries, retrieval architecture, and agent prompts. Those may later become relevant, but placing them in the initial statement prematurely turns hypotheses into requirements.

Worked example: from “build a research agent” to a decision

Assume a commercial team says:

“We need a research agent that finds useful information about enterprise prospects.”

A weak restatement would be:

Build an LLM agent that searches the web, summarizes companies, and exports a report.

This is an implementation brief. It assumes web search, summaries, reports, and an LLM agent are all useful.

A stronger, solution-neutral problem statement could be:

By the next planning cycle, decide whether to fund a limited intervention that reduces account-preparation friction for SDRs working on enterprise prospects.
Before outreach, these SDRs need to assemble a brief containing relevant, trustworthy account context, but they currently reconcile fragmented sources and cannot quickly verify important claims. This produces inconsistent preparation effort and reduces confidence in personalized outreach.
The opportunity is worth pursuing if evidence shows that improving the speed and traceability of account preparation materially changes a defined outreach-quality or productivity signal.

This version is not “finished” just because it reads well. Its value is that it makes the important uncertainties visible:

• Are SDRs truly the primary affected users?
• Is the dominant pain speed, evidence traceability, missing data, or something else?
• Does preparation quality meaningfully influence outreach outcomes?
• What signal would be credible enough to support investment?

Those questions are not defects in the statement. They are the beginning of a disciplined investigation.

---

Frame from the user’s point of view

The Working Backwards PR/FAQ guidance insists that the problem paragraph be written from the customer’s point of view. That principle is useful beyond product launches: a business goal becomes actionable only when connected to a concrete user problem.

For internal systems, you will rarely calculate a literal total addressable market. Still, the underlying test transfers well:

• How many people or workflows are affected?
• How often does the failure occur?
• What does it cost in time, error, delay, lost opportunity, risk, or dissatisfaction?
• Is the problem important enough that people would change their behavior to solve it?

A recurring trap is to describe a technology limitation as the problem:

“We do not have an agent that can browse the web.”

That may be true, but it says nothing about why the absence matters. Compare it with:

“Analysts preparing a competitive brief must manually search and reconcile sources, so a time-sensitive recommendation is often delayed or lacks traceable support.”

The second version gives you a failure that can be observed and, eventually, tested. It also leaves open several possible interventions: a better data source, a structured workflow, a human research process, an agent, or a decision to do nothing.

---

Gather the raw material before compressing it

The problem-framing board below uses four prompts: who, what, when/where, and why. It is a useful way to collect observations before trying to write polished prose.

For engineering and research requests, use those prompts with a decision lens:

Prompt	What to capture	Example for an account-research request
Who?	The affected user and any materially different user groups	SDRs handling enterprise accounts, not “Sales” in general
What?	The job and the observed breakdown	Create a credible account brief; claims are slow to find and hard to verify
When/where?	The workflow moment and conditions	Before first outreach, especially for new or unfamiliar accounts
Why now?	The business consequence and reason a decision is needed	Preparation time is variable; leadership is considering investment in enablement
What outcome?	A decision-relevant sign of improvement	Faster preparation with sources attached, without a drop in claim quality

At this point, resist two temptations.

First, do not turn every sticky note into a “fact.” A stakeholder saying “reps waste hours” is a claim that may be worth checking, not automatically a measurement. Second, do not fill blank boxes with plausible stories. A code agent can generate a fully populated framing board in seconds; that does not convert guesses into evidence.

Use explicit language:

• Observed: “Three sampled briefs lacked links to supporting sources.”
• Reported: “The sales lead says account preparation is inconsistent.”
• Inferred: “Inconsistent preparation may reduce personalization.”
• Unknown: “Whether preparation quality changes meeting conversion.”

This discipline protects you from an especially dangerous agent-era failure mode: treating a coherent narrative as a validated one.

---

Watch a concise framing demonstration

The following short excerpts show the definition of problem framing and then the moment where workshop notes are consolidated into a statement. Watch for the shift from collecting details to selecting one problem worth addressing.

The important move is compression with accountability. You begin with many possible users, pains, contexts, and causes. A decision-centered statement chooses a target and a decision without pretending that every causal explanation is known.

---

A quality check before you ask an agent to build

Before opening Claude Code or authorizing a prototype, inspect the statement with this review checklist:

1. Is there a real decision?
   Someone should be able to say what they will decide differently after the work: fund, pilot, prioritize, redesign, stop, or defer.

2. Is the affected user specific?
   “Users,” “the business,” and “the sales team” often hide incompatible needs.

3. Does it state a job in context?
   Identify what the person is trying to accomplish and the moment where the problem occurs.

4. Is the current failure observable?
   “The experience is poor” is an evaluation. “Users abandon the workflow after an unsupported result” is an observable pattern.

5. Is there a meaningful consequence?
   Explain why the organization should spend attention, money, or risk budget on this rather than another problem.

6. Is success described without prescribing the implementation?
   “Deploy a RAG pipeline” is a deliverable. “Provide traceable answers within a useful latency budget” is an outcome.

7. Can you point to what is known versus assumed?
   A statement may contain assumptions, but they should remain visible rather than disguised as facts.

The PR/FAQ review process expresses a related standard: reviewers should ask whether the customer and problem are clearly defined, whether the solution addresses the problem, and whether people would actually change their behavior. Treat this as truth-seeking rather than a pitch-defense exercise. The purpose of review is not to make the initial request look inevitable; it is to improve the decision quality.

A compact operational habit is to write the statement in the task or design document before asking an agent for a plan. Then give the agent a bounded role:

“Do not propose implementation yet. Restate the decision-centered problem, identify the solution assumptions embedded in this request, and list the evidence that would distinguish the top two interpretations.”

This uses the agent for structured critique while preserving responsibility for the framing. If its restatement reveals a different target user, outcome, or decision than you intended, you have found ambiguity cheaply—before it becomes code, architecture, or a polished but irrelevant demo.

---

Key takeaways

A broad request is not yet a problem statement. It may be a solution idea, a business aspiration, or an untested story about what is wrong.

A decision-centered problem statement:

• names the decision the work should inform;
• identifies a specific affected user and job;
• describes an observable present failure;
• connects that failure to a meaningful consequence; and
• defines a solution-neutral outcome that would justify action.

The immediate goal is not certainty. It is to transform vague ambiguity into visible, examinable uncertainty—without allowing an agent’s confidence or speed to conceal assumptions.

Next, you will classify those uncertainties: which parts of a request are unclear because of requirements, which because of implementation, and which because the available evidence is weak.