Meeting Notes — 2026-04-24

Participants: Max, Maha Duration: ~41 min Video: YouTube

Follow-up to 2026-04-23; Reiner away.

Framing — Max as atypical user, tech moving ahead of demand

Maha opened by testing how Max processes product questions. Max answered as a user: data sensitivity has tiers — crypto keys sacred, names/emails cautious, meeting-note words not worth worrying about individually (aggregation is the real risk). Maha's read: "you answered as a user, and you are not the typical user" — and that's fine, because right now the tech is moving forward independently of any specific customer demand. We're not waiting on a buyer to tell us what features to build.

The split of labour that emerged:

• Max / tech side: keep building features and anticipating what's coming. Already disconnected from specific systems (Teams/Zoom/etc.) — the camera+audio capture layer plugs into anything.
• Maha / customer side: bring customers, and get us to a test where the value can be validated.

Demo — use it as a buyer-feedback instrument

Max flagged a weakness in the current demo: when it surfaces something like "that answer was hierarchical," the label is technical / code-like and won't land for a non-technical buyer.

Maha's plan uses this as an opening:

• Approach known contacts with the ask "play the role of a buyer and react to our demo."
• Not a sales call, but the same people are plausible buyers — two target sources already in mind (incl. connections working with call centres).
• The feedback improves the demo; the conversation softens them toward the pilot.

Max's framing of the actual risks for the buyer: time (they spend effort + people-hours on the pilot) and data (they share data that could leak or be misused). Brand signals are how this segment typically justifies spend — and we don't have those, so trust has to come from somewhere else.

"Trust key" — the site as trust surface

Maha's request: design a single link we can send that, without us having to explain ourselves, communicates enough for the recipient to say "we trust you." Three dimensions to show:

• Team — experience, background.
• Tech / AI capability.
• The experiments we've run — evidence of genuine work.

Max's counterpoint on trust: the channel matters more than the content. A link sent by a salesperson is read as a pitch. The same link passed HR-to-HR (or coach-to-coach) reads as a recommendation. So: build something HRs / coaches want to share, and the trust arrives with the sharing, not the page.

That reframes the site from "brochure" into "something worth forwarding" — most plausibly a useful course or interactive demo, with the PeopleSpark signature underneath.

Content structure — the site

What Max is assembling (consolidating a year's worth of scattered output into one surface):

• Demo scene — the list of experiments / products people can try (incl. the LinkedIn story matcher, even if it's currently just a report).
• Mini-courses — HGL (hand-gesture language) and/or "AI in HR / dialogue work." Labs can legitimately offer education.
• Knowledge base from our calls — meeting notes and recordings, structured enough that past iterations (including dead ends) stay retrievable as institutional memory when we make new decisions.
• Partner / candidate routing — when new partner candidates are introduced, we need a place to capture them.

Context: the EMCC / ICF world is running "AI labs" during an upcoming May conference — one coach Maha knows cold-called her way into co-running one, and they're now exploring coaching-practice-with-AI in person over three days. A clearly visible PPL Spark lab page would let us plug into that circulation rather than individually pitching each contact.

Courses — two, kept separate

1. Hand-gesture language (HGL) course. Priority regardless of where the business lands. Rationale: forcing the accumulated HGL work into a teachable sequence is how we systematise it. Exposing it to real learners then tells us which gestures read universally and where we need to adjust. Max: also supports sales — more people aware of the methodology → curiosity → inbound.
2. "AI for dialogue-heavy work." Not HR-specific — sales, support, insurance, anywhere the work is dialogue. Covers what's possible today, security basics, who does what. Separate from HGL so methodology (human, transmittable by practice) doesn't get tangled with tech (AI-delivered).

Production question Maha raised: how much of the HGL course can AI construct without us sitting down to film? Max's view: the knowledge needs a structure first — what the learner should know, understand, and be able to do. Once that skeleton exists, parts become video explainers and parts become interactive practice (voice input against an agent, scripted lines to play with).

Three workstreams, explicit

Action items