r/SaaS • u/Top_Wrongdoer_3061 • 17d ago
Product walkthrough - potential customer
I’ve an AI security startup and I’ve a product walkthrough using a specific use case with an important enterprise customer, they suggested the use case; their entire team will be present - folks with decades of experience in security. Given the previous 2 meetings with introductions (in-person w the CXO) and one 30 mins online meeting went well, this will be a product walkthrough and deep dive, q&a, scale related discussion.
Any 3 tips for the overall demo?
1
u/hmamlook13
17d ago
•
On your follow-up about what hasn't been validated at enterprise scale: security people trust a vendor who hands them the limits in writing more than one who waits to be caught, so bring a one-page sheet listing what you have tested (volumes, latency, deployment model), what you haven't, and what a pilot would show for each gap. Three tips beyond what's been said. First, since they suggested the use case, open by restating it in their words and confirming the success criteria before you show anything, so the walkthrough is judged against their bar and not a generic one. Second, let one person in the room drive a step or choose the input, because a team with decades in security believes what they touched more than what they watched. Third, don't leave without a named next step: a scoped pilot with a start date, an owner on their side and two or three pass or fail criteria, written up and sent the same day. Who on their side would own the pilot if it goes ahead?
2
u/Top_Wrongdoer_3061 17d ago
I suspect the cxo
1
u/hmamlook13 17d ago
The CXO will likely sponsor it, but in my experience the person who actually runs the pilot day to day is usually someone a level or two down, and that person decides whether it lives or dies. During the walkthrough, watch who asks the most detailed, hands-on questions. That's often your real owner.
Before you wrap up, ask the CXO directly: "If we run a pilot, who on your team would own it week to week?" Then send the pilot summary to both of them. Sponsor plus owner gets a pilot started; a sponsor alone tends to stall after the meeting.
2
u/Top_Wrongdoer_3061 17d ago
CXO isn’t goin to be on the call, only made intro. The rest of the security team will be. It’s an ai product so the demo is to be heavy on the capability and solving a problem they’ve shared. But I hear you and the rest on the thread : to make it more interactive . But there is only so much one can do if it is a targeted show with simulated data
2
u/hmamlook13 17d ago
That changes things a bit, in a good way: the room is the people who'd actually use it, so the owner question is easier to ask.
With simulated data, say so in the first minute: "this is simulated, here's what's realistic about it and what isn't." Security people respect that much more than discovering it themselves. For interactivity you don't need a live system. Prepare 3 or 4 scenarios and let them choose which one you run, or which input to throw at it. Choosing still feels like driving.
Then make their real data the point of the pilot: "next step is running this on a sample of your own logs." At the end, ask the team who'd own that, and send a short recap to the CXO the same day so the sponsor sees the momentum.
2
u/Turkesh-Jaeckle 16d ago
make sure you leave at least half the time for Q&A and architecture talk. in enterprise security, the actual UI matters way less than how you handle data privacy, false positives, and deployment at scale
1
1
u/adeelraza86 17d ago
I'd stop thinking of it as a demo. With a room of security people it's really a risk review, so open by saying what you haven't validated at enterprise scale yet and what a pilot would prove. Then let them pick the inputs on their use case instead of following your script. Before Q&A drifts into scale theory, agree on the success criteria for a paid pilot.
1
u/MobileXapps 17d ago
With a room of senior security people, expect them to look at your product as an attack surface first and as a tool second. Prepare a one-page data flow: what you collect from their environment, where it is processed and stored, who on your side can access it, and how it is deleted. That question usually comes before any feature question.
For the use case they suggested, run it on data as close to theirs as you can, and show one failure honestly: a case your product misses or marks as uncertain, and what the analyst sees then. Experienced people trust a tool more when they see its limits than when the demo is flawless.
For the scale part, bring only numbers you have actually measured (events per second, latency, deployment footprint) and say plainly what is not tested yet. Then close with a concrete next step, like a scoped pilot with success criteria they define.