A team agrees to build an AI learning assistant. The prototype answers questions, the demo looks convincing, and there is already a list of features for version one.
I would pause on one question: what have we learned about the learner?
A working demo tells us something about the technology. It does not tell us whether somebody wants help in that moment, trusts the answer, or comes back after trying it. Product discovery before an MVP should reduce the uncertainty that could make the build pointless.
Start with a recent situation, not a feature opinion
“Would you use an AI tutor?” invites an easy yes.
“Tell me about the last time you got stuck during training” is more useful. You can ask what the person tried, how long it took, whom they asked, and what happened next.
For a fictional training product, I would want to understand whether the difficult part is finding information, interpreting it, practising a skill, or getting permission to proceed. Those are different problems. A chat interface is not automatically a good answer to all four.
Do not treat a handful of positive interviews as a market estimate. Use them to identify patterns and sharpen the questions you test next.
Write the risky assumptions down
For the same learning assistant, the assumptions might look like this:
| Assumption | What would make it doubtful? | A small test |
|---|---|---|
| Learners need help during the task | They mostly seek help before starting | Observe when questions occur |
| The available material contains the answer | Key answers live only in someone's head | Audit a sample of actual questions |
| Learners can tell when an answer is uncertain | They accept plausible errors without checking | Test answer and uncertainty designs |
| Voice is useful in the setting | People avoid speaking in shared spaces | Compare voice and text in context |
The tests are suggestions for an illustrative product, not a universal research plan. Consent, privacy, and the setting affect how you can run them.
Test the thing that could change the decision
A polished prototype is not always the next useful step.
If the main uncertainty is whether people need the help at all, show the task and ask about their current behaviour. If the uncertainty is whether source material can answer their questions, try a small content audit. If it is whether the interaction makes sense, test a rough prototype.
I would choose the test by the decision it could change. “We should do more research” is too vague to guide a team.
SVPG makes a similar point: discovery is not useful when what you learn cannot change the plan. Its guidance covers testing the opportunity and the solution, not just collecting positive feedback. 1
Before starting, write down what you will do with different results. If learners cannot find a useful answer even when a person provides it manually, making the response automatic may not solve the underlying problem.
Keep feasibility and trust in the conversation
Discovery is not only an interview activity. Bring engineering into the discussion of data availability, integration, permissions, and response time. Bring the relevant domain expertise into what counts as a safe, useful answer.
For an AI product, a successful response on one example is not a dependable system. Evaluation needs its own plan, including cases where the assistant should not answer.
Likewise, an interaction people enjoy can still be difficult to support or too expensive for the intended business. The MVP should test a viable product proposition, not only an attractive screen.
Define what the MVP is meant to teach you
“Launch chat” is a delivery milestone.
“Learn whether new employees can complete this training task with less avoidable assistance” is a learning objective. It tells you something about the users, the task, and the evidence you need.
Choose a narrow scope that lets you observe the behaviour. Record what remains untested, so an early success does not become a claim that the whole product is proven.
There is no need to delay every build until uncertainty disappears. That will never happen. I would rather build a smaller thing around an explicit uncertainty than a larger thing around an assumption nobody has named.