從決策出發，再打造 AI 產品

An AI product earns its place when it helps someone make a useful decision and act on it.

By Ahmadreza Samadi · 13 September 2026

Updated 10 October 2026

At a glance

Define the user’s decision first. Work backward to the evidence and its limits, design the next action and any human review, then evaluate the whole workflow—including incomplete information, review effort and delivery cost. Start with one decision the product can support well. The property-research example below is hypothetical.

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.

Which decision should this AI product help someone make?

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.

How would I 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.

Put the method to work

Before You Build the AI turns these questions into an interactive decision brief. Explore a worked example, adapt it to a product idea, and export a first experiment.

For the professional context behind my interest in property research workflows, see my work on AI real estate intelligence at Appraiva. The example in this essay remains hypothetical.

About the author

Ahmadreza Samadi

Technology Entrepreneur based in Dubai. Co-Founder & Technical Lead at Appraiva; Co-Founder & CEO at Royal Abraj Group.