The demo is not a presentation
A guide to getting useful feedback on your AI tool prototype
You have spent weeks building something. You have a working prototype, a stakeholder willing to look at it, and a meeting on the calendar. The natural instinct is to prepare a presentation. Walk them through the features, show them what it can do, and hope they are impressed.
This approach may not get you the information you need to move forward.
A stakeholder demo is not a performance. Rather, consider the demo a structured conversation with a working prototype as the focal point. You are not there to impress anyone. You are there to learn things about your tool that you cannot learn on your own, things that only someone embedded in the actual workflow can tell you. Everything in this guide serves that purpose.
I have organized this around two questions that students in the AI Law and Policy Clinic should consider before presenting their work. The first is: what do you actually need to know before the meeting starts? The second is: how do you run the meeting so that you walk out with feedback you can act on?
What you need to know before the meeting
Know your audience’s relationship to the problem
The standard advice is “know your audience,” but that is too vague to be useful. What you need to understand is how your stakeholder currently experiences the problem your tool is meant to address. Three dimensions matter.
First, technical fluency. How much can you assume about their understanding of what your tool does? If the answer is very little, and it usually is, then your language during the demo has to change entirely. You do not explain the retrieval pipeline. You explain what happens when they upload a document and ask a question.
Second, the current workflow. What does the stakeholder currently do to accomplish this task without your tool? How long does it take? Where are the friction points? This is the baseline your tool is measured against. If you do not know it, you cannot interpret their feedback. A stakeholder who says “this is interesting” may mean “this solves a real problem I have every day” or “this is a neat trick that has nothing to do with how I actually work.” You need enough context to tell the difference.
Third, institutional constraints. What rules, norms, or resource limitations govern how work gets done in their setting? A tool that requires a login that their IT department will not approve is dead on arrival, regardless of how well it performs. A tool that assumes reliable internet access in a field office that lacks it is solving the wrong problem. What about data security, such that no data can ever leave the premises? These are things you should know before the meeting, not things you discover during it.
If you walk in without this knowledge, you will spend the meeting learning things you should have already understood, and you will lose the opportunity to get feedback on the tool itself.
Understand your own technology
This one is uncomfortable, but it matters. Using a no-code builder does not exempt you from understanding the technology you have built. If you assembled a RAG-based chatbot using a platform that handles the infrastructure for you, such as Josef Q, you still need to be able to explain, at a conceptual level, what happens between the moment a user submits a query and the moment an answer appears on screen.
I am not talking about mathematics. I am talking about the architecture. Documents are split into chunks. Those chunks are converted into numerical representations and stored. When a user asks a question, the system finds the chunks most semantically similar to the query and passes them to a language model, which generates a response grounded in that retrieved text. That is a paragraph. You should be able to deliver it clearly and confidently because the stakeholder will ask questions that require clarity and confidence.
Here is why this matters practically. Document preparation has consequences that are invisible unless you understand chunking. A poorly formatted 200-page PDF will produce worse answers than a set of clean, well-organized documents, and if you do not understand why, you will blame the model when the problem is the corpus. Stakeholder implementation questions require real answers. When a legal aid organization asks what happens when a statute changes and the documents need updating, you need to explain the update process. When they ask where their data is stored, you need to know whether the platform sends data to a third-party API or keeps it local. These are not hypothetical questions. They come up in every stakeholder meeting I have observed.
There is a deeper issue as well. A RAG system that retrieves the wrong chunks will still produce a fluent, confident-sounding answer. If you do not understand retrieval, you will not know how to test for this. You will demo a tool that looks like it works, and miss that it is pulling from the wrong section of the wrong document. The stakeholder will not catch this either, because the output reads well. This is exactly the kind of failure that erodes trust once someone discovers it in practice.
A chatbot built on a RAG system is not “an AI that reads your documents.” It is a system that requires document curation, ongoing maintenance, monitoring, and periodic evaluation. If you cannot articulate this, the stakeholder will underestimate what adoption actually requires, and the tool will fail after you hand it off.
You should be able to explain, in plain language, what your tool does at each stage of its process, what can go wrong at each stage, and what decisions you made that affect its performance. If you cannot do that, you are not ready to demo.
Be honest about what you are showing
This is the principle students are most likely to skip, and it is the one that matters most for the stakeholder relationship. You need to walk into the meeting knowing whether you are showing a proof of concept or a production-ready tool, and you need to say so explicitly.
A proof of concept demonstrates that a workflow can be supported by the technology. It does not demonstrate that the tool should be deployed. If that is what you have, say so: “This shows that the approach is viable. Moving to production would require formal evaluation, corpus maintenance planning, integration work, and resources that go beyond what I can provide in this clinic.” You should be able to provide a rough sense of what lies between the prototype and what a client or litigant would actually interact with. Not a budget, but an honest description of the remaining work.
If you are claiming something closer to production readiness, the standard is substantially higher. In a legal context, the eyeball test is not sufficient. You cannot watch the tool produce a plausible-looking output and call it validated. Every critical task the AI performs needs systematic evaluation: test cases that cover clear inputs, boundary cases, and out-of-scope queries; defined acceptable error rates grounded in the consequences of getting it wrong; and verification at each step of the pipeline, not just the final output. I have written about this evaluation framework in detail in a previous post. A student claiming production readiness should be able to describe the evaluation they conducted, not just the features they built and observed.
The reason this matters for the stakeholder meeting is straightforward. Stakeholders will often assume that a working demo means the tool is ready. It is your responsibility to set expectations accurately. Overselling a proof of concept as production-ready creates a trust problem that is very difficult to recover from. And underselling production-ready work by failing to describe the evaluation behind it leaves the stakeholder without the confidence they need to advocate for adoption within their organization.
Anticipate concerns and be prepared to speak to them
Stakeholders in legal settings will have questions that go beyond the tool’s features. The most important one is some version of: can we trust this? You need to be ready for it, and the answer cannot be “it seems to work well.”
This means you have to be able to explain clearly where you are in the evaluation process. What have you tested? How thoroughly? What do you know about the tool’s accuracy, and what do you not yet know? If your honest answer is that you have tested it informally but have not conducted a systematic evaluation, say that. The stakeholder can work with honesty. What they cannot work with is vague assurance.
A common mistake is investing heavily in an impressive-looking user interface while neglecting the harder work of testing accuracy and consistency. A polished interface creates the impression that the tool is further along than it actually is. If the stakeholder asks a question the tool has not been evaluated against, and the tool produces a confident but wrong answer, the visual polish makes the failure worse, not better. It signals that you prioritized appearance over reliability.
This is particularly important to understand when it comes to tools built on large language models. These are probabilistic models. They do not return the same answer every time in the same way. A tool that produces the correct response to a query today may produce a slightly different, and potentially incorrect, response to the same query tomorrow. This is not a bug in your implementation. It is a fundamental characteristic of the technology. It means that testing a tool once and seeing a correct answer is not sufficient. You need to verify that the tool produces correct and consistent answers across repeated queries, across varied phrasings of the same question, and across the full range of inputs it is likely to encounter in practice.
If you cannot speak to this, the stakeholder’s trust concerns will go unanswered, and unanswered trust concerns are where adoption goes to die. You do not need to have all the answers. You do need to demonstrate that you understand the questions and have a plan for addressing them.
How to run the meeting
Present the MVP and nothing else
The technologies available for building AI tools make it trivially easy to add features. A sidebar here, a summary function there, a second input modality that seemed interesting. Each addition feels like progress. It is not. Each addition is a new thing that can break, a new thing you have to explain, and a new thing the stakeholder has to form an opinion about. You are splitting their attention across features rather than concentrating it on the core function the tool exists to perform.
Present the smallest version of the tool that performs the core task end-to-end. One form, one workflow, one use case. Not a vision of what the tool could become, but a working instance of what it does right now. The stakeholder needs to react to something concrete, not to a roadmap.
If you built extra features, do not hide them. Just do not demo them yet. The stakeholder meeting is about validating the core workflow. Once that is validated, you earn the right to expand.
Demo the workflow, not the tool
Students naturally demo tools in isolation. They open the interface, show its features, and walk through its capabilities. What they should do instead is demo the tool inside the workflow it is meant to support.
If the tool helps a legal aid attorney draft a section of a filing, do not demo the tool in a vacuum. Walk through the attorney’s actual process: they receive the case, they review the relevant documents, they reach the point where your tool enters, they use the tool, they review the output, and they continue with the rest of their work. The stakeholder should see where the tool enters and exits their existing process.
This is how you surface the real friction points. A tool that works perfectly in isolation may create problems at the integration points: the output format does not match what the attorney needs for the next step, the tool assumes information the attorney does not have at that stage of the workflow, or the review process takes longer than doing the task manually. These are things a feature demo will never reveal. A workflow demo exposes them immediately.
Structure the feedback you are asking for
Do not present your tool and then ask, “so what do you think?” The stakeholder will give you polite generalities. They are experts in their domain, not in giving product feedback. You have to structure the conversation so that their expertise gets channeled into observations you can act on.
Come with specific questions prepared in advance. Does this output match what you would produce yourself, and where does it diverge? At what point in your current workflow would you actually use this? What would stop you from using this tomorrow? Is there anything in the output that would be unacceptable in your professional context, whether that means filing it with a court, submitting it to an agency, or sharing it with a client? Based on what you have seen, what would you need to see before you would be comfortable using this with real cases?
That last question ties the feedback conversation back to the proof-of-concept question. It tells you what the stakeholder’s deployment threshold actually looks like, in their own terms, and gives you a concrete target for the next iteration.
Listen like a researcher, not a developer
When stakeholders give feedback, students have two common failure modes. The first is defensiveness: explaining why the tool did what it did, justifying design choices, narrating the technical constraints. The stakeholder does not need this. They are telling you about their experience. Your job is to record it.
The second is real-time problem-solving. “I can fix that right now,” or “that would be an easy add.” This derails the conversation from feedback collection into a live debugging session. The impulse is understandable, but it is counterproductive. The meeting is for gathering information. The building happens after.
The discipline is straightforward. Take notes. Ask follow-up questions that deepen your understanding of their reaction. Resist the urge to respond with solutions. You are conducting a structured interview, not a co-design session. The synthesis and prioritization happen after the meeting, not during it.
Translate feedback into the next concrete step
After the meeting, convert what you heard into a specific, bounded next action. Not a feature list. A single iteration. What is the one thing you now know needs to change, and what does the next version of the MVP look like with that change made?
Scope creep happens when students try to incorporate everything they heard at once instead of prioritizing. The stakeholder may have given you ten observations. Three of them are about the core workflow. Two are about nice-to-have features. Five are about things that matter for production but not for the current stage of development. Sort them. Act on the ones that address the core function. File the rest for later.
The cycle then repeats: a constrained MVP, demoed inside a real workflow, with structured feedback that produces a single next iteration. This is how tools get built. Not in one inspired sprint, but through repeated contact with the people who will actually use them.