Essay
Start with the decision, then build the AI
An AI product earns its place when it helps someone make a useful decision and act on it.
When I assess an AI product idea, I start with a business question: what decision is difficult today, and what would make it easier?
That question provides a practical starting point for both product strategy and engineering. It identifies who needs the result, what information matters, and what the system must do beyond producing an answer.
Describe the decision precisely
Consider a hypothetical property research tool. “Analyze properties with AI” leaves many product choices unresolved. “Help an investor decide which properties deserve further investigation” is more specific. It identifies an action and a point in a workflow where better information could help.
The distinction matters because a useful research tool may need to show supporting evidence, make comparisons easy, and identify missing information. A single score would only cover part of that job.
Work backward to the evidence
Once the decision is clear, ask what evidence a person would need to make it responsibly. In this example, that might include imagery, its capture date, relevant property attributes, and the limits of what can be inferred.
Then ask whether the necessary data is available, sufficiently current, and appropriate for the use case. These questions belong early in product development because the answers can change what the product should promise.
Design the action after the answer
An output becomes useful when it fits the next step. Does the customer shortlist an opportunity, request additional information, or send a case for human review?
That action shapes the interface and the architecture. It determines which information must be retained, which integrations matter, and where a person needs to be able to question or correct the system.
Evaluate the whole workflow
For this hypothetical tool, I would evaluate several questions together:
- Does it surface information that is relevant to the research decision?
- Can a user understand the evidence and its limitations?
- How much review is needed before taking the next step?
- What happens when information is incomplete or the system is wrong?
- Is the value of that assistance worth the cost of delivering it?
A model metric can inform those questions, but it cannot answer all of them. Product evaluation also needs to examine the experience of the person using the result.
Choose the smallest useful commitment
I would rather define an initial product around one decision we can support well than make a broad promise that is difficult to evaluate. A focused scope gives the team a clearer way to learn from customers and decide what to build next.
My approach is to connect the customer’s decision, the supporting evidence, the product workflow, and the engineering effort. That connection is where technical capability becomes a business proposition.