Hey everyone. So I'm still pretty new to the consulting side of things, and I've got a client who's understandably wary of adding another tool to their stack. They asked me to demo Humata for their team's internal docs and research PDFs.
My plan was to just upload a sample document and show the Q&A. But for a skeptical team lead, I'm worried that looks too much like a magic trick. Should I start by asking *them* for a tough, specific question they have right now from their own documents? Like, "Give me a problem you wasted time on last week."
Or maybe I should focus on the permission and data control aspect first, since that's a big worry? Any advice from folks who've been through this would be awesome 😅.
Your instinct about the "magic trick" problem is spot on. Demoing with generic sample docs builds immediate distrust because it's a controlled environment. The moment you ask for their actual problem document, you're demonstrating applicability to their specific pain points, not just showing off features.
Permission and data control is a crucial second step, but leading with it can sound defensive. Instead, I'd suggest this sequence: first, have them provide a real, complex PDF they've struggled with (an old RFC, a dense compliance doc, a messy internal playbook). Let Humata answer a genuinely difficult, context-specific question from it. That proves value. Then, immediately pivot to "Now, how this document got here and who can see it" to address security concerns organically.
They need to see it as a problem-solving tool first, and a system component second. If you start with the architecture, skeptical engineers will just start probing the hypothetical attack vectors before they've even bought into the core utility.
infrastructure is code
Yes, absolutely start by asking them for a tough, specific question. The "give me a problem you wasted time on last week" line is perfect. It instantly shifts the demo from a sales pitch to a problem-solving session. They're evaluating the tool against their own real-world friction, not a pre-cooked scenario.
That said, I'd actually prepare *two* of their documents ahead of time. Ask for one or two representative files in advance. Upload them privately before the call. Then, when you start, you can immediately say, "I took the liberty of loading your Q4 project post-mortem and the new vendor security policy. Can you show me a section your team often needs to reference?" This shows you did your homework and gets you past the upload wait time, which can kill demo momentum.
buyer beware, but buy smart
Your instinct about avoiding the magic trick is correct, but I disagree with starting by asking them for a problem on the spot. In a live demo with skeptical engineers, you have about three minutes to establish credibility before you lose them. Waiting for them to find a document and formulate a complex question burns that time and introduces awkward silence.
I'd prepare by getting one of their actual, complex documents in advance - an architecture diagram PDF or a vendor security questionnaire - and load it privately. Start the demo by stating, "I've loaded the AWS transit gateway migration doc you shared." Then immediately ask, "What's one unclear detail your team argued about last week?" This proves relevance without the dead air of an upload and shows you respect their operational reality. The security conversation becomes a natural follow-up once they're engaged by seeing their own content parsed.
You're right about the three minute credibility window, that's a real constraint. Getting a document in advance is smart.
I'd add one thing though: when you say you've pre-loaded their doc, be explicit it was a one-time thing for the demo. Say something like, "Just to save time today, I uploaded this. Normally, you or your team would control that process completely." It pre-empts the "wait, how did you get that?" security itch before they even have to scratch it.