In an AI product, feasibility belongs in discovery

Product discovery, as most teams practise it, is about desirability. Do people have this problem, would they change how they work to solve it, would anyone pay for it. Feasibility is handed to engineering as an estimate: yes, it can be built, and it will take about this long.

That division of labour works when software does what it was written to do. In an AI product it is the wrong way round. Almost any feature can be demonstrated within a week. Whether it can be made good enough — on your documents, for your users, at a cost you can carry — cannot be settled at a whiteboard, and it is the question that decides whether there is a product at all.

Why the usual split fails

The demo answers a different question. A demo shows that the model can produce a good answer. A product has to produce an acceptable one on the bad days: the ambiguous request, the badly scanned annex, the customer who writes in two languages at once. Demos are curated by whoever runs them, usually without anyone meaning to.

Engineering cannot estimate it honestly. How long it will take to reach acceptable quality has no real answer until someone has run real cases. Teams give a number anyway, because the roadmap needs one, and the plan is then built on a guess presented as an estimate.

User research tests the happy path. Show people a prototype that is always right and they will like it. That says nothing about whether they will still use it after the third confident, wrong answer — which is the moment that actually decides adoption.

Two tracks in the same weeks

Discovery for an AI-native app runs two tracks side by side, and neither is allowed to finish first.

Is it worth having? The classic question, asked more precisely: what does the task cost today, timed rather than described, and what would a person do with an output that is usually right and occasionally, plausibly, wrong?

Can it be done well enough? Pull a sample of real inputs — say, a hundred, chosen to include the awkward ones before anyone has seen an output — and run them through the simplest credible approach. Not a product: a script and a spreadsheet. Someone who does the work marks each result good, fixable or wrong.

What does a wrong answer cost here? This is where the two tracks meet. A wrong summary of an internal meeting costs a minute of somebody’s time. A wrong figure in a customer quote costs a margin, or a customer. The same error rate can be a product in one place and a liability in another, so the result of the probe means nothing until it has been priced.

Infographic

Discovery with a feasibility track

1. 01Time the taskHow the work is done today, measured rather than described.
2. 02Sample real inputsAwkward cases included, chosen before anyone sees an output.
3. 03Run a crude probeThe simplest credible approach. A script, no interface yet.
4. 04Grade with the expertEach result marked good, fixable or wrong.
5. 05Price the errorsWhat a wrong answer costs in this particular task.
6. 06DecideGo, reshape the task, or stop while stopping is cheap.

Three outcomes, all useful

Go. With a rough quality level, a list of the categories that fail, and a cost of being wrong that the design can absorb. The graded sample becomes the first version of the evaluation set, so none of the work is thrown away.

Reshape. The most common result: the model is good at half of the task. The product becomes that half — drafting rather than sending, sorting rather than deciding — and is often a better product for it, because the person keeps the part where judgement matters.

Stop. Cheaply. Two weeks and a spreadsheet instead of two quarters and a launch nobody uses. This is the outcome discovery exists to make possible, and a team that only ever comes out of discovery with a yes is not really doing discovery.

Who has to be in the room

The probe needs the person who knows what a good answer looks like, not a proxy for them. A product manager can read outputs and form an impression; only someone who does the work can tell that an answer is fluent, plausible and wrong.

Book their hours before discovery starts. The usual reason the second track is quietly dropped is not scepticism. It is that this person had a day job and was never actually available.

Where design comes in

In AI-native apps design the first step is watching the current task with timings, and the prototype that follows has realistically wrong answers built into it, because a prototype that only ever shows good outputs tests nothing that matters. Run alongside a probe on real data, it lets discovery answer both questions before any engineering budget is committed.