Session 07. Preparing an Engineering Company for an Industry Exhibition

29 September 2026 · combined lecture and practical session · 1 hour 24 minutes 48 seconds. Source: the full automatic L4 transcript. The material has been editorially reconstructed; actual examples, assessments and the lecturer's observations must be distinguished from universal requirements and statistically demonstrated patterns.

The session's place in the course narrative

Earlier topics took us from service and product business models through team organization, customer discovery, RFI/RFQ/RFC, proposals, contracting, discovery and first architecture concepts. We now need to test whether students can reproduce this path as their own engineering company before progressing to hiring, Jira or GitHub Projects, and sprint delivery. The educational sequence is: positioning → deliverables → exhibition meeting → follow-up → customer request → proposal → engineering delivery.

1. A team becomes a company when it can introduce itself

Each of the four student groups models an independent company in a branch of embedded engineering. The team must define its name, specialization and division of responsibilities: founder or leadership, engineering, sales, marketing and technical expertise. Assigning everyone the CEO role is not credible: a business without people who can fulfil orders contains an internal contradiction.

A specialization statement should answer three questions: Which customer problem do we solve? Which technology area do we know? What outcome demonstrates our competence? “We develop software” is weak positioning. “We design and verify embedded control systems with hardware–software integration” is considerably more precise, but still needs examples and evidence.

2. Three required deliverables

These artifacts have distinct roles rather than duplicating one another. A business card enables contact; the digital version reduces friction during exchange; the one-pager starts a technical discussion. The team must also agree on a short, one- or two-sentence introduction for presenting the company verbally.

3. Physical and digital cards: one identity, different channels

The lecturer shows examples from several technology companies, emphasizing economy of space, consistent typography and a coherent corporate identity. All cards belonging to one team must use the same brand template. Different logos, shifting colors or inconsistent field order weaken the impression of a coherent organization.

A professional email address in the company's own domain generally inspires more confidence than an impersonal private mailbox. Yet the domain, names and website must be tested in practice rather than merely drawn on a mock-up. English personal names should be rendered consistently, preferably using official transliteration; mixing languages within a minimal card undermines its clarity. A QR graphic without a functioning target is decoration, not a working interface.

Engineering analogy: a business card is an external interface to a person and an organization. If the displayed address does not exist, the interface is defective regardless of the quality of its graphic design.

4. The one-pager as a conversation starter

The session examines an A5 handout used at Auto.AI. Its purpose is not to squeeze in the entire company presentation but to offer two or three immediate entry points into an engineering discussion. A useful first side includes the company name and one strong message; a relevant technical visual; two to four core areas of expertise; and verifiable case studies or customer and partner references, provided their use is authorized. The second side can extend the engineering capability description, show verifiable partnerships and provide website and contact details.

Adapt the handout to its audience: for automotive visitors, highlight ECUs, V&V, functional safety or HIL; for industrial engineering, automation, control, sensing and integration; for AI, your own relevant results. A long list of famous brands unrelated to the audience's actual problem is less persuasive than one relevant and convincingly documented case.

A graphic should explain the technology, not merely fill blank space. Restrict the word count, establish a readable hierarchy, and leave detailed explanations for a live conversation or the website. In the transcript, the lecturer contrasts concise and overloaded examples, explaining why high information density without visual hierarchy impedes immediate comprehension.

5. Trust as a verifiable result

Customers quickly check consistency across the company's identity: logo, website, email domain, names, people, roles and examples of projects. Publicly claimed clients and partnerships must be real and authorized for disclosure. Fictional organizations can be used in an educational role-play, but they must not be represented publicly as verified real contracts.

A convenient editorial review model (a teaching model, not an empirical formula):

C = I × R × A, where C denotes the notional coherence of the presentation, I the consistency of identity (0–1), R relevance to the customer (0–1), and A the verifiability of claims (0–1). If any factor is zero, the presentation is unsuitable for a professional contact. This equation is not a statistically calibrated measure of trust.

6. From business card to CRM: what follows the exchange

At a conference, cards are collected, digitized, supplemented with meeting context and entered into a contact-management system, CRM or a training spreadsheet. Contact does not equal contract. Notes should record: who the person is; their organization; the specific pain point; matching expertise; the agreed next action; its owner; and its due date. Digital cards accelerate data capture but cannot replace understanding of the engineering need.

7. Review of the first student's result

At the end of the session, the lecturer reviews a student's card. He recognizes the logo and the Lead Software Engineer title but identifies a personal Gmail address, inconsistent use of Ukrainian and English, and a QR code that does not lead anywhere. The company website is missing too. This vividly separates a layout that “looks finished” from an artifact ready to be used at a real exhibition.

8. Practical assignment: acceptance criteria

1. The team defines its name, embedded specialization, target customer and roles.
2. Each member prepares a printed and a digital contact card using one shared design system.
3. The team prepares one two-sided one-pager with concrete competencies, relevant images, evidence and contacts.
4. Team members cross-check names, titles, company email addresses, links, QR codes, branding and language consistency.
5. Each member can explain in 30–60 seconds how the company can help a specific engineering customer.

Definition of ready: the artifacts make it possible to conduct the next day's exhibition role-play and exchange genuine contacts, not just display pictures.

9. Self-check questions

• Why does a common business-card template matter more than individualized decoration?
• How is a one-pager different from a commercial proposal?
• What should a QR code do, and how do you prove that it works?
• Which case is most relevant to present at an automotive conference, and why?
• How does a collected contact become a qualified lead rather than another row in Excel?

Transition to the next session

Once the materials exist, the team must test the consistency of its identity, the credibility of its organizational structure and its readiness for a real dialogue. The practice on 30 September shifts from creating artifacts to auditing them and demonstrates the structure of a technical proposal needed after customer follow-up.