Choose the decision before choosing the tool
Start with a recurring consequential customer decision for which your expertise can clarify the situation and produce a useful next step. It is easy to begin with the format because formats are tangible. My preference is to begin with the moment the customer gets stuck. Once you can explain that choice and the expert reasoning it needs, the right form is easier to assess.
“Choose the tool that fits the choice, not the tool you happen to find exciting.”
— Curtiss Witt, The Decision Economy, Chapter 16.
What should I decide before choosing technology?
Identify a question customers face when making a consequential choice. The opportunity is strongest when your expertise can clarify the situation, not merely repeat information already easy to find. Write the decision in ordinary language before selecting a calculator, assessment, planner, or other interface.
Choose a task with a clear beginning, relevant inputs, and a useful result. A narrow scope makes the logic easier to explain and maintain. Avoid starting with a tool that claims to solve an entire life or business situation without identifying which part it can responsibly support.
A useful software DSA applies expert logic to the user’s situation. Identify the circumstances that materially affect the guidance. If the same generic paragraph follows every possible input, consider whether a clear article would provide the help more honestly and with less complexity.
Someone should be accountable for the reasoning behind the tool. Identify who can explain the rules, resolve a questionable result, and approve changes. The choice of software does not supply that expertise or remove the need for a responsible owner of the decision mechanism.
Before building, describe what a person should gain even if they do not buy anything. The result might clarify a requirement, compare options, or identify a sensible next step. If no useful outcome exists without a sales conversation, revisit the tool’s promise and mechanism.
The comparison below describes two approaches to the work. It is a practical design contrast, not a measured claim that one approach always produces a better commercial outcome.
| Information and activity approach | Decision-support approach |
|---|---|
| Choose a format because it is exciting. | Choose a bounded customer decision first. |
| Collect every available input. | Ask only for circumstances that change useful guidance. |
| Test the page alone. | Test reasoning, uncertainty and the explanation. |
What belongs in a one-decision brief?
Write one question the asset will help answer. Keep it specific enough to evaluate whether the output succeeds. A phrase such as “improve readiness” needs a decision context: readiness for what, for whom, and what should the person be able to decide after using the tool?
For each proposed question, state why the answer is needed and how it changes the result. Remove inputs without a defined role. This improves the user experience and makes data handling easier to justify without collecting information merely because a form makes it convenient.
Write the reasoning in plain language before translating it into software. Include what happens when conditions conflict or information is missing. If the rules cannot be explained coherently, adding code will not resolve the underlying uncertainty about what the tool is supposed to recommend.
Describe what the user receives: an explanation, comparison, plan, or other decision-support result. Include the important limits and next step. Avoid using “personalized insights” as the entire output specification; the phrase does not tell a builder or reviewer what useful information must actually appear.
State which situations, claims, and actions the tool will not cover. Include when another source of help is needed. A narrow boundary is not a weakness when it lets the user understand precisely what the asset can contribute without mistaking it for a broader professional evaluation.
How do I choose between an assessment, calculator and planner?
An assessment can organize reported conditions and identify priorities when a defined model supports that task. Decide whether descriptive results are more appropriate than a score. Do not add a numerical total merely because users recognize the format if the number would imply unsupported precision.
A calculator fits a decision where inputs and assumptions can be transformed into a meaningful computed result. Explain what the number represents and what it does not guarantee. The output should help the user reason about the situation rather than conceal important assumptions behind apparent mathematical certainty.
A comparison tool fits a choice among options when relevant criteria can be applied consistently. Preserve unknowns and show trade-offs. Do not design the criteria simply to ensure that the tool owner’s offer always wins regardless of the customer’s circumstances or stated requirements.
A planner can turn conditions into an understandable order of tasks. It should explain what must happen first and which changes require revision. A generic checklist may still be useful, but a situation-specific planning claim needs a mechanism that actually responds to relevant inputs.
Not every useful decision-support resource needs to become software. A clear static guide can be the right first contribution when the answer does not depend on individual inputs. Preserve that value without relabeling every document as a callable DSA or building unnecessary complexity around it.
The working rule I return to is this: “Choose the tool that fits the choice, not the tool you happen to find exciting.” It is a way to judge the next piece of work, while keeping its evidence and limitations visible.
What should I test before launching the tool?
A page can load while applying the wrong rule. Create checks tied to the decision model, including cases where the expected result differs meaningfully. The goal is to determine whether the mechanism behaves as intended, not merely whether the interface produces something after submission.
Test missing answers and out-of-scope conditions as deliberately as ordinary cases. The tool should preserve uncertainty and explain its limits. A system that works only when every user supplies ideal information may fail precisely where a person most needs help understanding what remains unresolved.
Ask reviewers what the output says, why it appeared, and what they would do next. This examines the communication of the decision support. Do not assume that a technically correct result is usable simply because the development team already knows what its labels mean.
A successful test of a rule does not establish a commercial outcome or universal reliability. Record what was checked and under which conditions. When reporting readiness to launch, separate decision-logic verification, interface behavior, and any actual user feedback rather than combining them into one broad success claim.
Identify what could make the tool’s assumptions or source information stale. Assign an owner and a review process before launch. A decision-support asset is a maintained capability; the initial build does not remove the need to govern future changes that affect its guidance.
What can I learn from the Institute’s example?
DERA helps an owner decide what to improve first for one main offer. That bounded purpose explains why it asks structured questions and returns three starting actions. It is an example of selecting a mechanism around a decision, not a template every business must copy unchanged. Decision Economy Institute: live capability manifest; accessed September 2026
The assessment uses seven dimensions and descriptive statuses without an overall numerical readiness score. That choice preserves its orientation role and avoids presenting a prediction it cannot support. When designing another tool, select output language according to its own evidence and purpose. (Witt, supplied author source set, September 2026)
DERA uses owner-supplied answers and labels the result BY YOUR ACCOUNT. The interface does not convert those answers into independent verification. Another DSA should likewise state where its inputs come from and what additional evidence would be needed before stronger claims could be made. Decision Economy Institute: live capability manifest; accessed September 2026
Once the mechanism is defined, identify who should use it and through which supported routes. A human interface, REST API, Remote MCP, or browser tool may serve different consumers. The access choice should follow a real task rather than become the reason the tool exists.
Your first deliverable should identify the decision, audience, necessary inputs, expert logic, result, limits, owner, and verification plan. That is enough to make the proposed capability concrete for review. It also gives you a better basis for comparing implementation options than a request to build something “AI-ready.”
What can I do with this today?
Start with one offer and write down the next decision this article helps you examine. Give the work a defined scope before adding a new page, tool or integration.
1. Write a one-decision brief before choosing technology.
2. Identify the consequential fact or condition that remains uncertain. Name who can check it and what would establish completion.
3. If you need help ordering the business work, complete the free Decision Economy Readiness Assessment. Read its reasons and three starting actions, then choose the first task you can inspect.
Our own example is deliberately bounded. The Institute’s Method explains the owner-reported result; its capability manifest declares what the tool can do; and its assessment schema makes the question bank and data contract inspectable. These September 2026 publisher documents describe the assessment. They do not independently establish better customer or business outcomes.
Choose the decision before choosing the tool
Before the next customer faces the same unresolved choice, identify the improvement that would make the answer more useful. Use the readiness assessment to turn your reported conditions into three starting actions, and keep the next evidence check in view.
Disclaimer
Based on your answers, this assessment suggests improvement priorities; it does not independently verify your business or predict AI recommendations, sales, or business quality.
FAQ
What makes a customer decision bounded?
Choose a task with a clear beginning, relevant inputs, and a useful result. A narrow scope makes the logic easier to explain and maintain. Avoid starting with a tool that claims to solve an entire life or business situation without identifying which part it can responsibly support.
How should expert rules be described?
Write the reasoning in plain language before translating it into software. Include what happens when conditions conflict or information is missing. If the rules cannot be explained coherently, adding code will not resolve the underlying uncertainty about what the tool is supposed to recommend.
When might a calculator fit?
A calculator fits a decision where inputs and assumptions can be transformed into a meaningful computed result. Explain what the number represents and what it does not guarantee. The output should help the user reason about the situation rather than conceal important assumptions behind apparent mathematical certainty.
What does the evidence actually support?
A successful test of a rule does not establish a commercial outcome or universal reliability. Record what was checked and under which conditions. When reporting readiness to launch, separate decision-logic verification, interface behavior, and any actual user feedback rather than combining them into one broad success claim.
When should interfaces be chosen?
Once the mechanism is defined, identify who should use it and through which supported routes. A human interface, REST API, Remote MCP, or browser tool may serve different consumers. The access choice should follow a real task rather than become the reason the tool exists.
Do I need to share contact details before seeing the assessment result?
No. The complete result is available before an optional email request. If a contact commitment has held you back, try the free readiness assessment and read the plan first. Emailing it and consenting to future updates are separate choices. The result remains BY YOUR ACCOUNT.
References
Curtiss Witt. The Decision Economy, updated author-supplied manuscript, Chapter 16 for the quoted decision rule; the supplied manuscript also grounds the framework. Supplied September 2026; unpublished manuscript, so no public URL is asserted.
Decision Economy Institute: live capability manifest. Publisher’s capability declaration, accessed September 10, 2026. Describes the available routes and their limits; not an independent test of every operation.
Decision_Economy_DSA_Step_1_Decision_Model(2).docx. Supplied September 2026. Controlling assessment model and distinctions among self-report, evidence, applicability, and outcomes.
Decision Economy Institute: How this assessment works. Publisher’s own Method; ruleset de-readiness-1.0.0, accessed September 10, 2026. Not an independent outcomes study.
Decision Economy Institute: Assessment schema and question bank. Publisher’s technical contract; accessed September 10, 2026. Data shape and published question bank, not proof of real-world decision quality.
Continue exploring
What is a Decision Support Asset?
How does a DSA help without making the decision for me?
Where should a small business start preparing for AI-assisted customers?
Tags: first decision-support tool; Decision Economy; Decision Economy Institute; Curtiss Witt; customer decisions; decision support; business readiness; DERA; Better Choices; Practical action.