Session 10. From an Exhibition Contact to Technical Discovery: Follow-up, Team and Presentation

13 October 2026 · lecture and practical workshop · 1 h 39 min 02 s. Based on the automatic transcript IgorSikorskyKPI_L6_13102026.md (the recording label L6 is not the site's chronological session number). These notes retain the teaching argument and its principal examples; they are not a verbatim transcript. Otto, Udo and AutoCircuit belong to a classroom simulation. Their financial, technical and commercial statements are not verified references to actual contracts or companies.

Position in the course: from a lead to a meaningful request

In Session 09 the teams met prospective customers at an exhibition and sought agreement to continue the conversation. Session 10 asks whether a team can turn a chance contact into a structured professional interaction. This is where discussing services begins to become identification of a genuine engineering problem. The lecture covers reporting after an exhibition, public technical communication, invitations to follow-up meetings, selecting specialists, meeting structure and an interactive company presentation.

This is not engineering design yet, nor is it a signed contract. The intended outcome is an interested counterpart, a mutually agreed technical next step and a documented hypothesis about a need. At the end of the session the lecturer announces a forthcoming practical assignment: a mini-proposal and initial decomposition of features. Advice on negotiation style should be read as the lecturer's experience and as teaching heuristics, rather than universal laws of corporate conduct.

1. Returning from a conference: information is an outcome too

A team brings back more than contacts: it brings observations about the market. Which technologies were demonstrated? Which problems recurred? What changed in competitors' product ranges? Which engineering approaches drew attention? The lecturer recommends a concise report to the line manager so that the findings can inform a strategic discussion, such as a quarterly business review (QBR). Such a report should clearly distinguish an observation from an interpretation or forecast.

A practical report addresses four questions: what was observed; why it matters; which opportunity or risk it suggests; which action is proposed. Where possible, include a link to public evidence, the demonstration's name and date, relevant contacts and limits on reusing information. A vendor's marketing claim is not automatically a verified engineering result. For instance, an AI-based battery-control demonstration calls for architecture, metrics and test conditions to be examined before it is included in a company roadmap.

2. Post-event publication: making engineering expertise visible

Separate from the private internal report, the participant can work with marketing on a public post. The author describes an emerging trend, the underlying engineering problem, their analysis and plausible applications; marketing supports editing and distribution. The technical participant must review the result before publication, since they are responsible for accurate technical statements and for not disclosing other parties' data, promising unproven performance or violating an NDA.

LinkedIn is presented as an example of a professional contact network. After meeting in person, a connection request and relevant subsequent exchanges can be appropriate. But the number of connections is not the number of customers. A public post that identifies a real engineering problem and demonstrates independent reasoning can foster future trust; it cannot guarantee lead generation or sales.

3. A webinar as a continuation of technical inquiry

A second channel is a webinar or recorded expert interview reflecting on the conference. Unlike a short post, it allows time to explain technical reasoning, limitations of demonstrations and questions from an audience. The lecturer compares such publications to additional fishing lines left in the water after the exhibition. The image illustrates multiple engagement channels; it is not a predictive sales model.

To keep a webinar from turning into a purely promotional event, organize it as problem → observation → technical explanation → limitations → open questions. Do not name contacts or companies without permission or present internal evidence as public. A useful outcome need not be a sales inquiry: an expert conversation or a new research contact is valuable as well.

4. Why an exhibition acquaintance may no longer remember us

Preparing a follow-up begins with a realistic view of the situation. In the scenario Otto and Udo have returned to work and may not remember a short conversation among dozens of other encounters. The team should not rely on the enthusiasm shown at the stand. The recipient needs context: where the meeting happened, what subject was discussed and why a new conversation is being proposed.

The lesson from the role-play is that initiative lies with the team seeking cooperation. It should retrieve its meeting notes, verify the business contact, specify what the next call is meant to achieve and make a clear invitation without exaggeration. This is the transition from uncommitted interest to a managed next action.

5. The first follow-up message: brief, specific and offering choices

Together with the students, the lecturer assembles a practical message pattern: an appropriately formal greeting, a reminder of the earlier encounter, a concise purpose, three alternative times across different days or periods of the day, room for the recipient to propose their own time, and a signature. The tone should be respectful and unambiguous without becoming overly familiar. Choosing among Hi, Hello and Dear depends on the actual relationship, the organization's conventions and context—not merely on the other person's age.

Classroom example (not an actual email): “Hi Udo, it was a pleasure speaking with you at the conference about production automation. Would you be interested in a short meeting to explore possible areas for cooperation? We can offer Tuesday at 10:00, Wednesday at 14:00 or Friday at 16:00 (Kyiv time). If these options do not work, we would be happy to accommodate a time that suits you. Best regards, …” The times are illustrative, not confirmed meeting slots.

6. “Those times do not work”: avoid endless guessing

In the scenario, Udo agrees with the idea of a meeting but rejects the suggested times without offering an alternative. The sensible response is to thank him and ask him to propose a suitable slot, rather than sending three more arbitrary options. Once a time is agreed, the team creates a calendar invitation with a link to the online meeting. Time zone, duration and platform must be explicit.

Contact-management model: contact → invitation → agreed slot → calendar event → completed follow-up. These are process states, not evidence of a conversion rate. For operational analysis, one could record T_response—elapsed time between the initial message and a reply; T_meeting—time between first contact and the meeting taking place; and N_confirmed—the count of confirmed meetings. Such metrics are useful only if the events are defined and measured consistently.

7. Who should attend the first meeting?

The lecture proposes a compact team combining three functions: the person who originally met the prospect; an engagement specialist who facilitates the conversation; and a delivery representative who considers whether the proposed work can actually be performed. A specialist—for example a Computer Vision architect—may join where a narrow domain requires it. Inviting a large group solely to appear impressive may be uncomfortable for a customer who attends alone.

The original contact preserves context and continuity. Engagement facilitates discussion, notices the other party's reactions and secures agreed next steps. Delivery is responsible for the realism of timelines, staffing, risk and constraints and should challenge unapproved technical or commercial commitments. These are recommended functions for this teaching scenario, not a mandatory organization chart for every company.

8. Bringing in an expert from another department without undue escalation

If the team needs a Computer Vision specialist from a different delivery unit, the lecturer suggests first coordinating a short allocation with the person's line manager. That manager knows the engineer's workload and the team's constraints. With approval, the team can approach the engineer directly, explain the customer context, the expected contribution and approximate time required. Immediately involving C-level executives in this routine situation can look like unnecessary escalation.

This is not a rigid universal rule. Authority and staffing arrangements vary by company: some engineers manage their own time and some managers require additional approval to change allocations. The lecturer also favors direct and informal internal communication; the appropriate level of formality is defined by the organization, not by a universal prohibition on formal forms of address.

9. Preparing the meeting: purpose, agenda and the customer's comfort

The call should not begin with sharing slides immediately. First greet the participants, check time and connection, introduce everyone, let the customer describe their own role and then propose the agenda. During the role-play the student initially forgets to invite Udo to speak. The lecturer returns to a central principle: the other person should feel like a participant in the discussion, not merely an audience for a slide deck.

A concise introduction includes name → position → area of responsibility → relevant experience. Academic degrees or professional titles may help when relevant, but do not replace technical evidence. If someone loses the connection, the facilitator briefly acknowledges the issue and changes the speaking order rather than allowing a long pause. A meeting needs an explicit purpose and desired outcome; “show all the slides” is not an outcome.

10. The AutoCircuit presentation: from polished slides to discovery

In the practical segment a student presents a fictional company, AutoCircuit, as a provider of automotive embedded solutions involving ECUs, ADAS, sensors, in-vehicle networks, electric-vehicle systems, development and validation. The presentation mentions CAN, CAN FD, Automotive Ethernet, C/C++, HIL/SIL and functional-safety themes. The lecturer praises the presentation's structure and the student's confident delivery, but identifies a critical shortcoming: the talk becomes a monologue that does not test the customer's interest.

The number of engineers, OEM names, purportedly deployed products and stated latency reduction in this presentation are claims inside a student role-play, not independently validated facts about a real business. Technical acronyms must also be used meaningfully: HIL means hardware-in-the-loop and SIL means software-in-the-loop; CAN FD and Automotive Ethernet have different properties, and listing them is not proof of competence. A real proposal requires verifiable results, measurement conditions and authorization to publish customer references.

11. Interaction: the customer's response is information

After a capability slide, the presenter might ask: “How closely does this area match the challenge you are facing?” or “Which constraints are currently the hardest for you?”. A pause invites the customer to describe a concrete problem and lets the team test its assumptions. If the customer responds actively when CAN FD is mentioned, that suggests a hypothesis of interest to be tested through questions. Body language alone is not proof of a requirement.

The presentation works better as a loop: short fact → question → customer response → clarification → next fact, rather than a compulsory reading of all the slides. A follow-up is intended to identify the outline of the problem, not prematurely commit to an architecture or price. A meaningful exchange can then lead naturally to dedicated technical discovery and a future proposal.

12. Competence boundaries and responsible handover of a technical question

The student presents herself as a Computer Vision team lead, yet the prospective customer may ask about CAN FD or low-level network behavior. Expecting one person to provide equal expertise on CV, the CAN bus, hardware integration, EMC and safety is methodologically unsound. Acknowledging the limits of one's expertise is professional responsibility, not weakness. A sound response is to record the question, agree a technical follow-up and bring in the appropriate architect or engineer.

A technical next step needs at least some inputs: the system's function, interfaces, operational context, timing and safety constraints, compatibility conditions and expected tests. For example, “we are interested in CAN FD” does not specify bus rates, network topology, diagnostics or available ECUs. Those questions belong in a specialist discussion—not in an unprepared promise made at the first meeting.

13. From discovery to proposal and backlog

The session's logical progression is first contact → follow-up → technical discovery → clarified need → proposal → decomposition → implementation. The proposal should connect the actual problem to scope boundaries, assumptions, architectural options, verification, resources and risks. Subsequently the team can move to a backlog in Jira or GitHub Project. These stages had not been completed in the 13 October session: the lecturer describes them as forthcoming practical work.

The lecture stresses that the course should not remain permanently in marketing. Communicating engineering value is important precisely because it helps secure a real engineering object to design. For the next workshop, the lecturer plans to review other teams' presentations, prepare a short proposal in Word and—if time permits—begin splitting the work into features. This is a forecast supported by the lecture, not an account of work already published.

Workshop: artifacts to prepare after the session

1. Conference report: describe three observations and separate fact, interpretation and proposed action for each.
2. Personalized invitation: draft a 20–30-minute follow-up invitation referring to the original discussion, three time options and a time zone.
3. Meeting roles: assign ownership of the customer relationship, facilitation, delivery feasibility and any specialized technical questions.
4. Agenda: allocate 20 minutes so that the customer can introduce themselves, clarify their problem and agree on a next step.
5. Question matrix: prepare five discovery questions that distinguish an actual customer need from your hypothesis about it.
6. Mini-proposal: produce an outline with problem, scope, needs/assumptions, technical approach, acceptance criteria, risks and the next meeting.

Questions for self-assessment

• Why should an exhibition visit produce an engineering report in addition to a contact list?
• What distinguishes a LinkedIn follower, a lead, a confirmed meeting and a customer?
• Why is a time-specific invitation usually more actionable than “let us talk sometime”?
• Why does the first follow-up need a delivery representative even when engagement leads the discussion?
• When is a CV architect necessary, and when does inviting one merely overload the meeting?
• What reaction during a presentation may suggest a customer pain point, and how can that hypothesis be checked?
• How do we distinguish a hypothetical student example naming well-known brands from verified commercial evidence?
• What must be documented before technical discovery and a proposal can begin?

Forecast for the next one or two sessions, based on the transcript

According to the lecturer, the next practical session should begin with brief reviews of the other student teams' presentations. The planned next task is to write a mini-proposal in Word around the discussed scenario, followed by an initial step toward feature decomposition. Until there is a record showing that those activities took place, they remain plans rather than completed parts of the teaching archive.