AI-Assisted Decision Making for Founders
Use AI to prepare a decision: organize evidence, identify alternatives and challenge assumptions. Keep the decision criteria, source verification and accountability with a named person. A fluent recommendation does not establish that the underlying facts are complete or current.
The most useful starting prompt is a decision brief, not “What should I do?” Define the choice, deadline, constraints, options and information already available.
Separate facts from interpretation
Create an evidence table before asking for a recommendation. Each entry should have a source, date and status. Distinguish an observed fact from an estimate, a stakeholder preference and an unresolved question.
Ask the assistant to reference those entries when reasoning. Require it to mark unsupported assumptions and explain which additional facts could change its view. Then check the references yourself. Source links help inspection, but do not guarantee that an interpretation follows from the cited material.
| Decision input | Example | How to handle it |
|---|---|---|
| Verified constraint | Available engineering weeks | Treat as a boundary unless the owner changes it |
| Estimate | Expected support demand | Model a range and identify its basis |
| Preference | Customers want fewer setup steps | Check whose preference and how it was observed |
| Unknown | Procurement approval time | Investigate or preserve uncertainty |
Generate alternatives before ranking them
Have the assistant propose meaningfully different options, including delaying, narrowing or doing nothing. Ask for the strongest case against each favored option. This can expose assumptions, but model-generated criticism is still a reasoning aid rather than independent validation.
Choose criteria before scoring. For a product decision, they might include customer value, implementation effort, operational burden and reversibility. Avoid a weighted spreadsheet that hides disagreement behind precise decimals. If two people disagree about the importance of a criterion, discuss that choice explicitly.
Check sensitivity: if a modest change in one uncertain input reverses the ranking, the decision needs better evidence or a smaller commitment. Use ranges rather than asking a model to manufacture probabilities for events with no measured basis.
Worked example: prioritize a feature
Illustrative decision: a startup can spend its next cycle building a requested dashboard or improving a difficult import process. Three large prospects asked about the dashboard. Support records show existing customers repeatedly need help importing data.
An assistant organizes the evidence and drafts a comparison. The founder checks whether the prospects’ requests represent purchase conditions, whether support tickets involve unique customers and whether the import problem blocks activation. A count of mentions alone cannot decide the issue.
The team then considers a third option: repair one import failure and demonstrate a manual dashboard export before committing to a full dashboard. This preserves the ability to learn about both problems. The decision owner records the chosen scope, evidence and the condition that would trigger reconsideration, such as a confirmed customer commitment the current plan cannot satisfy.
Leave a decision record
Save the question, options, verified sources, assumptions, decision owner and review date. Record rejected options and the reason they were rejected. Keep the AI-generated analysis separate from the final rationale so later reviewers can see what a person actually endorsed.
For a consequential decision, use an independent reviewer with relevant expertise and access to the original evidence. Asking the same assistant to approve its own recommendation is not independent review. Legal, financial or other specialist questions may require a qualified professional for the relevant jurisdiction and facts.
Evaluate the process as well as the outcome. A reasonable decision can have an unfavorable result under uncertainty; a favorable result does not excuse invented evidence. Revisit the record when the assumed conditions change.
Use AI in entrepreneurship to identify appropriate support tasks, the tool-selection guide to choose an assistant and the integration overview for operating controls.
Write a decision brief that can be challenged
Before using an assistant, fill in the decision deadline, owner, available options and consequences of delay. State which constraints are fixed and which can be negotiated. A requirement that is merely preferred should not silently eliminate a useful option.
Include an evidence register with a short identifier for each record. For example, E1 might be an interview transcript, E2 a verified support count and E3 an engineering estimate. Ask the assistant to attach those identifiers to claims and distinguish an observed fact from its interpretation.
An illustrative prompt is:
Compare the supplied options using only the evidence register. For each option, state the supported benefit, uncertain assumptions, downside, reversibility and missing information. Do not invent probabilities or customer commitments. Identify the assumption whose resolution could most change the decision.
Review the response against the originals. A reference to E1 does not prove the claim follows from E1. Preserve missing information instead of forcing a complete-looking answer.
Use sensitivity analysis to direct research
A weighted comparison can help organize preferences, but its numbers are often judgments rather than measurements. Record the basis for each score and test how the ordering changes when uncertain scores or weights move.
Illustrative continuation of the feature example: the dashboard appears attractive mainly because three prospects might purchase after it is built. If that purchase condition is unconfirmed, compare scenarios with no purchase, one purchase and the plausible upper case. Do the same for import improvements: how many accounts are actually blocked, and what would resolution change?
If the dashboard wins only under the most favorable assumption, the next task is to verify the purchase condition. If the import improvement remains useful across reasonable scenarios, the team may favor a small reversible fix while investigating the larger feature. The analysis identifies what to learn; it does not manufacture certainty.
Ask how costly the decision is to reverse. A brief customer interview or prototype may be worth doing before a large commitment, but research also consumes time. State which uncertainty matters enough to investigate and when the team will decide despite remaining ambiguity.
Recognize common failure patterns
| Failure pattern | What it looks like | Practical correction |
|---|---|---|
| Unsupported precision | Exact market or success probability without a basis | Replace with sourced facts or labelled scenarios |
| Confirmation seeking | Prompt asks only why the favored option is best | Request alternative explanations and disconfirming evidence |
| Evidence duplication | Several articles repeat one original claim | Trace sources to their origin |
| Hidden objective change | The answer optimizes speed when quality matters | Restate decision criteria |
| False consensus | A summary erases disagreement | Preserve dissenting observations and their context |
A model-generated counterargument can be useful but is not independent evidence. If the question is whether a customer will buy, another paragraph of reasoning is weaker than a concrete conversation with the budget owner. If the question is contractual interpretation, obtain appropriate specialist review of the actual terms.
Keep decision authority separate from execution
An assistant may recommend a price change, staffing action or vendor purchase. That recommendation should not automatically become permission to execute. Define what the system may draft and what a person must approve.
For a reversible internal decision, a short record may suffice. For a significant financial or legal commitment, the decision process should include relevant expertise, current facts and the applicable jurisdiction. Do not infer approval from silence or from the fact that a model repeated a recommendation confidently.
Where tools can act, present the specific target, scope and consequence before approval. Record what was authorized and confirm what actually occurred. A decision to investigate a supplier is not a decision to purchase its service.
Review learning without judging only the outcome
Set a review date and conditions that trigger an earlier revisit. For the feature example, those conditions might include a confirmed customer commitment, evidence that imports no longer block activation or a material change in engineering effort.
At review, compare assumptions with observations. Separate a weak process from bad luck. A well-supported decision can have an unfavorable result; an unsupported gamble can turn out favorably. Preserve the original rationale so hindsight does not rewrite the record.
Use the experiment-plan template to investigate a disputed assumption. The most useful output from AI-assisted decision making may be a smaller next action and a clearer reason to revisit it, rather than a confident final recommendation.
Sources and further reading
- NIST AI Risk Management Framework, for considering risks in AI-supported work
- NIST Govern Playbook, for accountability and documentation considerations
- Google: understand the problem before selecting ML