A readiness assessment that tests whether an AI opportunity has a defined user decision, bounded model role, evidence, control, evaluation and recovery plan.
An AI concept can sound compelling while leaving the actual product undefined. The team may know which model it wants to use but not whose decision is improved, what evidence the output needs, which actions the system may take or how failure returns to a safe state.
The Tcules AI Product UX Readiness Assessment examines the product contract before a team commits to a larger build. It ends with a disposition: research the user and decision, define the product model, prototype a bounded scenario, build a controlled release, improve an existing feature or defer the idea.
Who is trying to decide or accomplish what? What changes if the product helps? Summarising faster is not enough when the real job is to approve a claim, investigate a risk or choose an intervention.
Does the model retrieve, classify, recommend, generate or act? Which objects can it read or change? What requires explicit human commitment? The role must be bounded in product terms, not only by a prompt.
Which data can be used, who is authorised to provide it and what source or provenance should remain visible? Client confidentiality and tool restrictions define the delivery boundary as well as the product experience.
What does the product do when information is missing, retrieval is incomplete, the model conflicts with policy, a tool call fails or the answer is plausible but unsupported? Failure needs a visible state and a route forward.
Who can inspect, correct, reject, escalate, undo or retry? Human in the loop is not a control unless the person has relevant evidence and decision authority before the consequence becomes difficult to reverse.
Which representative scenarios, criteria and failure classes decide whether the product is useful and safe enough to advance? Evaluation should test the user decision and the complete workflow, not only model output in isolation.
Each row connects the current evidence condition to the recommended next move and the step the team should avoid until readiness improves.
| Evidence condition | Recommended next move | What not to do yet |
|---|---|---|
User decision remains vague | Research the work and define the decision | Select a model or build a general assistant |
Decision is clear but model role is broad | Define scenarios, tools, objects and authority | Allow unbounded action |
Interaction is plausible but failure is unknown | Prototype difficult and partial states | Treat a happy-path demo as product proof |
Workflow is bounded but quality criteria are missing | Build an evaluation set and failure taxonomy | Optimise one generic quality score |
Evidence and control are sufficient for a narrow case | Build a controlled release | Expand across roles and use cases immediately |
Existing feature is used but difficult to rely on | Audit evidence, correction, recovery and monitoring | Add confidence language without changing control |
The assessment can conclude that AI is not the right product intervention. A deterministic rule, better search, improved information architecture or a normal workflow change may resolve the need with less variability and operating cost.
ConnectX began with personas, KPIs and AI concepts but no product structure connecting a request to data and interface behaviour. Eight scenarios bounded intent, tools, data, modules, twin state and action before the coded demonstration was treated as coherent.
BuildTwin shows a different readiness problem. AI could run structural-drawing checks, but the accountable engineer needed source evidence, observations, missing-input states, correction and escalation before a result could support a decision.
The assessment is useful before an AI roadmap commitment, before expanding an initial feature or when a demonstration cannot yet answer how the product should behave under real conditions.
Bring the proposed user decision, any current prototype and the failure that would be most expensive to discover after launch.
Bring the proposed user decision, any current prototype and the failure that would be most expensive to discover after launch.
