What is the FOCUS Framework?
FOCUS is a structured prompt engineering framework built for strategic analysis, complex decision-making, and consulting-style outputs. The acronym stands for Function, Outcome, Criteria, Underlying Assumptions, and Strategy — five components designed to make every relevant constraint, expectation, and hidden belief explicit before the model begins its analysis.
- F — Function: Define the role and task type
- O — Outcome: State the desired end result
- C — Criteria: Set measurable success standards
- U — Underlying Assumptions: Surface hidden context
- S — Strategy: Specify the analytical approach
The framework's most distinctive feature is the Underlying Assumptions component. In most analytical prompts, critical context — budget constraints, team capabilities, market conditions, technical limitations — goes unstated because the prompter assumes the model will infer it correctly. FOCUS treats these assumptions as a first-class element of the prompt, forcing you to surface them deliberately.
This matters because a strategically incorrect answer — one that is well-reasoned but based on wrong assumptions — is often worse than no answer at all. FOCUS is designed for situations where the quality of reasoning matters as much as the correctness of the conclusion.
When to Use the FOCUS Framework
Strategic Analysis
Market entry, competitive positioning, growth strategy — any analysis where the conclusion depends heavily on assumptions about the competitive landscape or internal capabilities.
Decision-Making
Build/buy/partner decisions, technology choices, organizational structure changes — where trade-offs are complex and wrong assumptions lead to wrong choices.
Consulting Deliverables
Feasibility assessments, risk analyses, and strategic recommendations where the output must be grounded in the client's actual constraints, not theoretical best practices.
Architecture Reviews
Technical architecture critique and recommendations where team maturity, operational constraints, and business requirements shape what is actually viable.
Business Case Development
Investment proposals and business cases where financial assumptions, market assumptions, and execution assumptions must be made transparent to be credible.
Policy & Regulatory Analysis
Compliance assessments and policy impact analyses where jurisdictional assumptions, timeline assumptions, and scope assumptions determine the entire framing.
How to Use the FOCUS Framework
- 1
Function — Define the role and task type
Specify what the model is being asked to do and in what capacity. "Act as a strategic analyst performing a market entry assessment" is far more directive than "analyze this market." Function sets the operating mode and expertise level for the entire response.
- 2
Outcome — State the desired end result
Define the concrete deliverable you want — a recommendation, a risk register, a comparison table, a decision framework. Be specific about the form the output should take, not just the topic it should cover.
- 3
Criteria — Set measurable success standards
Define what a successful response looks like in concrete terms: how many risks to identify, what format for recommendations, which dimensions to cover. Criteria transform subjective quality into objective completeness.
- 4
Underlying Assumptions — Surface hidden context
List every assumption your analysis rests on: financial constraints, team capabilities, timeline, market conditions, technical limitations, regulatory status. If the model gets these wrong, every conclusion that follows is built on a false foundation. Write them explicitly — even the ones that seem obvious to you.
- 5
Strategy — Specify the analytical approach
Tell the model what kind of thinking to apply: first-principles reasoning, benchmarking, risk-weighted analysis, scenario planning. Strategy prevents the model from defaulting to a generic framework when a specific analytical lens is more appropriate for your situation.
Prompt Examples
Function: Perform a strategic market entry feasibility assessment. Outcome: A structured assessment of whether our SaaS project management tool should expand into the European SMB market in the next 12 months, with a clear recommendation. Criteria: The assessment must cover market size, competitive landscape, regulatory considerations (GDPR), and go-to-market channel options. It should conclude with a binary recommendation (enter now / defer) and three supporting rationale points for whichever position is taken. Underlying Assumptions: We assume our current ARR is $2.4M, growing at 40% YoY. We assume our product is English-only with no localization budget in the next 6 months. We assume GDPR compliance is not yet certified but is achievable within 4 months. We assume we have one dedicated sales hire available for European outreach. Strategy: Apply a risk-weighted feasibility lens rather than an opportunity-maximization lens — we need to know what could go wrong and how likely those risks are, more than we need to know the theoretical upside.
Function: Act as a senior engineering architect reviewing a proposed microservices migration plan. Outcome: An architectural critique of the proposed migration from a monolith to microservices, identifying critical risks and recommending a phased approach if warranted. Criteria: Identify at least 4 architectural risks. For each risk, provide a severity rating (High / Medium / Low) and a specific mitigation strategy. If a phased approach is recommended, define the phases and their sequencing rationale. Underlying Assumptions: We assume the current monolith is a 6-year-old Rails application with no automated test coverage above 30%. We assume the team is 8 engineers, none of whom have built microservices before. We assume the business cannot tolerate more than 4 hours of planned downtime per quarter. We assume Kubernetes is the target deployment platform but the team has no production Kubernetes experience. Strategy: Prioritize operational and team-capability risks over theoretical architectural purity. The goal is a realistic plan this team can execute, not the ideal architecture in the abstract.
Pros and Cons
| 🟢 Pros | 🔴 Cons |
|---|---|
| Underlying Assumptions component prevents conclusions built on wrong foundations | Requires significant upfront thinking to enumerate assumptions correctly |
| Criteria component makes quality measurable rather than subjective | Overkill for simple questions where assumptions are not a meaningful risk |
| Strategy component directs the model's analytical approach, not just its output | The Underlying Assumptions section can become unwieldy for highly complex scenarios |
| Produces outputs that are grounded in real-world constraints rather than theoretical ideals |
Frequently Asked Questions
What does FOCUS stand for in prompt engineering?
FOCUS stands for Function, Outcome, Criteria, Underlying Assumptions, and Strategy. It is a five-component framework built for strategic and analytical prompts where making hidden context explicit is as important as the question itself.
What makes the 'Underlying Assumptions' component unique?
Underlying Assumptions is the component that distinguishes FOCUS from other frameworks. It forces you to surface the hidden beliefs, constraints, or conditions your analysis rests on — things like 'we assume the market is growing at 8% per year' or 'we assume the team has no machine learning expertise'. When these go unstated, the model may produce a technically correct answer that is practically useless. Making assumptions explicit grounds the output in reality.
When should I use FOCUS over GUIDE or QUEST?
Use FOCUS when the quality of the answer depends heavily on unstated context — strategic decisions, consulting analyses, and complex trade-off evaluations. GUIDE is better when you need structured expert advice with an evaluation loop. QUEST is better when you need scoped research. FOCUS is the strongest choice when you are worried that wrong assumptions could invalidate the entire answer.
What goes in the 'Function' component?
Function describes the task or role the model is performing — what it is being asked to do. Think of it as the job title for this specific prompt: 'Act as a strategic analyst', 'Function as a code reviewer', or 'Perform a market feasibility assessment'. It sets the operating mode for everything that follows.
How do I write effective success Criteria?
Criteria should be as concrete and measurable as possible. Instead of 'give me a good analysis', write 'The analysis should identify at least 3 strategic risks, rank them by severity, and provide one mitigation strategy per risk.' Vague criteria produce vague responses. The more specific your criteria, the more consistently useful the output will be.
Can FOCUS be used for creative tasks?
FOCUS can be adapted for creative work, but it is most powerful in analytical and strategic contexts. For purely creative tasks — copywriting, fiction, design briefs — the IDEA framework's iterative structure is a better fit. For creative-strategic hybrids like brand positioning or messaging strategy, FOCUS excels because assumptions about the audience and market heavily influence what 'creative' means in that context.
How does Strategy differ from Direction in the GUIDE framework?
Strategy in FOCUS defines the high-level approach or methodology for solving the problem — the 'what kind of thinking' rather than the step-by-step sequence. Direction in GUIDE is more procedural, specifying the order of steps. FOCUS Strategy might say 'Apply a first-principles analysis rather than a benchmarking approach', whereas GUIDE Direction might say 'First identify the root cause, then propose three ranked solutions.'