AI AI Tools Guidebook
Troubleshooting

Prompt Too Broad to Produce Useful Results

You asked a sweeping question and got a sweeping non-answer.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You asked “what is the best way to scale a startup engineering team?” and got 800 words covering hiring, culture, process, tooling, and remote work. The answer is technically right and applies to literally every startup that has ever existed. It does not apply to yours. Broad questions produce broad answers because the model has to write something that is defensible across the entire space of possible inputs. When the input space is huge, the only defensible output is the average of common advice — which is mediocrity by definition.

This page walks through how to narrow a broad question to the point where exactly one concrete answer is possible.

Common causes

1. No scale or scope

“How should I structure my engineering team” can mean a team of 3 or 300. The model writes the answer that covers both, which fits neither.

How to spot it: your question has no numbers.

2. No constraints

“What’s the best database” with no traffic, no cost limit, no team familiarity. The model has nothing to eliminate options against.

How to spot it: question is open with no “given X” or “subject to Y” clauses.

3. No deciding stakeholder

“What’s the right choice for our roadmap” — for whom? The CEO has different criteria than the engineering lead. Without a stakeholder, the model averages.

How to spot it: no role named in the prompt.

4. No success criterion

“Help me think through X” with no statement of what counts as helpful. The model writes a survey because surveys are universally non-controversial.

How to spot it: prompt has no “good output looks like” clause.

5. No input data

You asked for advice with no specifics about your situation. The model has to write generically.

How to spot it: zero concrete numbers, names, files, or data points in the prompt.

Before you change anything

  • Write down 5-10 specific facts about your situation.
  • Decide which of those facts the model should use.
  • Identify the decision-maker and what they will do with the output.
  • Define success in 2-3 measurable terms.
  • Plan to ask one narrow question rather than one broad question.

Information to collect

  • Current broad prompt.
  • The broad output you got.
  • 5+ concrete facts about your actual situation.
  • The decision the output should support.
  • Model and any system prompt.

Shortest path to fix

Step 1: Replace open verbs with decision verbs

Bad:  "What's the best way to scale our engineering team?"
Good: "We're 8 engineers shipping a B2B SaaS, currently 2 squads,
       lead time from PR to prod is 4 days. We want to halve lead time
       within 1 quarter. Pick ONE intervention from this list, defend in 3 sentences:
       (a) move to trunk-based development
       (b) add a dedicated platform engineer
       (c) cap PR size at 200 lines"

The decision verb (“pick”), the candidates, and the criterion force a concrete answer.

Step 2: Add 5 lines of concrete context

Stack: <runtime, framework, key deps with versions>
Scale: <users, requests, data size>
Constraints: <budget, deadline, team>
Tried: <what already failed>
Goal: <the deliverable with a success criterion>

This template converts generic prompts into specific ones.

Step 3: Name the decision-maker

"This decision will be made by the eng lead and reviewed by the CTO.
Eng lead optimizes for delivery speed. CTO optimizes for retention risk."

Stakeholder + their priority calibrates the answer.

Step 4: Define success in numbers

Success criteria for this answer:
- One concrete intervention named (not a list).
- Defense in <100 words.
- One risk identified and mitigated.
- One leading indicator we can watch in 2 weeks.

Numbers stop the model from hedging into prose.

Step 5: If still vague, ask the model what it needs

"What 3 specific data points would you need from me to give a
concrete answer instead of a generic one?"

Answer those, paste them back, re-ask. Two-turn approach beats single-shot vague.

Step 6: Split broad into narrow

If the question really is huge (“how do we scale”), split:

  • Prompt 1: identify the top 3 bottlenecks given our specific data.
  • Prompt 2: for the top bottleneck, pick the intervention.
  • Prompt 3: design the rollout.

Three narrow prompts produce 3x more actionable output than one broad prompt.

How to confirm the fix

  • The answer names a specific intervention, not a list.
  • The answer references your concrete facts.
  • A different team with different facts would get a different answer.
  • A teammate can act on the answer without follow-up questions.
  • Output word count is concentrated on the recommendation, not the survey.

If it still fails

  1. Context may be missing — add more specifics about your situation.
  2. The model may need to be told what to ignore (e.g., “ignore generic startup advice”).
  3. Try forcing a binary choice (“A or B”); binary is harder to hedge than open.
  4. If the question truly has no answer with your current data, your bottleneck is data collection, not prompting.

Prevention

  • Default: narrow prompts. Always include scope + constraints + decision-maker + success criteria.
  • Use a checklist before sending: who decides, with what data, optimizing for what, success looks like what.
  • For exploration, ask for one concrete strawman first, then iterate against it.
  • Audit broad-question habits: every “what’s the best way to” should trigger a narrowing step.
  • For team workflows, build a “narrow prompt” template covering scope, constraints, decision verb.
  • When tempted to ask broad, ask “what’s the smallest concrete decision I can ask about?” instead.

Tags: #Troubleshooting #Prompt #Prompt quality #Vague answer

Related Articles