Session 11. Negotiating after the first contact: discovery, partnership and transition to a project

14 October 2026 · Practice session 4 · 1 h 38 min 33 s. Based on the automatic transcript IgorSikorskyKPI_P4_14102026.mp4.md. This is an edited teaching note, not a verbatim transcript. The companies, participants, results and negotiations in both scenarios are classroom role-play. Commercial figures and technical capabilities claimed by participants were not independently verified. Details of the fictional defence product and the complete raw transcript are excluded from public publication.

Where this session fits: practise conversion, not an impressive speech

Session 10 examined the post-event contact, follow-up and preparation for a first meaningful meeting. Session 11, explicitly identified by the lecturer as eleventh in course chronology and fourth practical session, continued that exercise. The aim was to move a prospective customer from introduction to a defined need and an agreed next action, rather than merely showing corporate slides.

At the beginning, some student artefacts remained outstanding, including landing pages, presentations and assignments from previous sessions. Reviewing and correcting them became part of the practice. The main method was facilitated role-play with pauses, feedback and repeated attempts. The outcome was readiness for an RFI, planning and a proposal—not a signed contract.

1. Follow-up: from a written agreement to a calendar invitation

After a professional event, the team contacts a fictional engineering manager, Otto. The email should refer to the previous conversation, suggest specific meeting options and allow the recipient to propose another time. A meeting is agreed only after the other party confirms the time—not when the team selects a convenient slot unilaterally.

The lecturer highlighted unnecessary correspondence: after agreement, there is usually no need to send a separate email saying “we will send the link later”. Instead, create the calendar event with attendees, time zone, subject and meeting link. The invitation must reflect the agreed purpose. The calendar invite operationalizes an agreement; it does not substitute for agreement.

2. Who attends and why their incentives differ

In the first scenario, the team selected four roles: Engagement Manager, Partnership Manager, Delivery Manager and Engineering/Technical Lead. Each answers different questions; an unexplained large delegation may confuse the customer.

The exercise distinguishes selling an engineering service from joint product development. These are different business models, and their goals can compete. Engagement wants to generate paid work promptly; Partnership evaluates the longer common future; Delivery controls the feasibility of commitments. The team should align its position before the meeting instead of hiding these conflicts.

3. Round-table introductions build trust

After the event, the customer knows only one member of the team. Each participant should briefly state their name, role, area of responsibility and, when relevant, one professional strength. Handovers should be natural and concise. Clear responsibilities matter more than impressive titles.

During role-play, the lecturer interrupted lengthy thanks, unrelated explanations and uncertain self-presentation. The sound lesson is to speak concisely, confidently and truthfully. Professional confidence must not become fabricated tenure, clients or achievements, or concealment of material risks.

4. An agenda protects the meeting's purpose

Before presenting slides, the team should clarify why the meeting was called, what must be understood, how time is allocated and what decision is expected. One possible flow is introductions → short company overview → customer's interests → a relevant technical case → questions and next steps.

The other student scenario initially lacked an agenda. The lecturer pointed this out immediately: without an agreed purpose, a presentation can become a self-contained monologue. A striking visual or motto does not compensate for a weak agenda.

5. Why a generic company presentation fails

The first team had prepared a substantial deck about a fictional embedded company: global offices, headcount, customer brands, technologies, hardware platforms, testing and the product lifecycle. It worked as a classroom speech, but afterward it was unclear what exactly was offered to this particular Otto: a service, a product or joint development.

Before building a targeted deck, research the original event notes, the prospect's site, products, customers, vacancies, publicly described initiatives and professional profiles of relevant stakeholders. These inputs support hypotheses, not certainty; a question must test the hypothesis about the customer's need. Every logo, partnership, client statistic and technical claim on a slide needs a truthful source and permission for disclosure.

6. A presentation must support two-way discovery

In the first attempt, the student mostly spoke and left little opportunity for the customer to respond. The lecturer demonstrated how to interrupt the slide flow with a relevant question, listen to the answer and change the conversation's course.

If a slide lists hardware, software and infrastructure capabilities, ask which is closest to the customer's interests. If the answer is software, refine the level: firmware, HAL, middleware, architecture or application. Only then narrow down the domain. This is progressive problem qualification rather than trying to guess the requirement in advance.

7. From broad interest to a concrete request

In the first scenario, the fictional customer progressively specified the interest: software engineering → application level → automotive parking systems → difficulty detecting obscured obstacles. This is an example of conversational qualification, not a real customer order or verified engineering requirement.

At this point the presentation changes its value: it is no longer a list of company skills but a tool for discovering a specific problem. The next step is to record that problem in the customer's words, ask about constraints, available inputs, acceptance criteria and unknowns. The team should not commit to a solution before conducting technical discovery.

8. Engagement orchestrates; experts supply substance

The lecturer likened the Engagement Manager to a conductor: they maintain the meeting's rhythm, invite the right experts and watch the customer's reactions. Technical Lead supplies technical depth; Partnership addresses the cooperation model; Delivery assesses execution feasibility. One presenter should not attempt to speak for all disciplines.

When the customer shows technical interest, involve the engineering lead. When the discussion turns to phases, delivery timing or contract models, bring in Delivery. Timing matters: overly early discussion of restrictions can interrupt productive discovery, but those restrictions cannot be ignored when preparing a proposal.

9. Confirm feedback with questions, not facial expressions

The lecturer drew attention to non-verbal reactions such as engagement, distraction or an unusually strong response to a slide. Such clues can guide follow-up questions but are not reliable proof of a need. Confirmation comes from an explicit answer, agreed meeting note or an actual request from the customer.

After each substantive segment, ask: “Which of these matters most to you?”, “Where is the biggest current difficulty?”, or “Which constraint is critical?”. Record answers in meeting notes and label unverified assumptions as assumptions.

10. The first scenario's proper outcome: RFI and another discovery step

At the end of the first scenario, the fictional customer agreed to describe expectations for a software component and consider a subsequent technical discussion. The conversation used RFI and RFC. RFI commonly means Request for Information; RFC has process-dependent meanings (for example, Request for Change), so a real team must clarify the intended document and its purpose. Do not assume RFC is a universal term for a technical request.

Instead of selling blindly, the team can request a brief problem statement, assess feasibility, prepare a preliminary scope and organize another discussion. This is not yet a contract, but it is a verifiable next action with an owner and an expected outcome.

11. Delivery takes over: from an idea to a plan and proposal

When the customer asks about project phases, the Delivery Manager gathers the appropriate roles—embedded software, hardware, QA and engineering leadership, depending on the problem. The result should not be a generic “we can do it”, but a feasible draft plan.

The lecturer explicitly named the artefacts: team composition, work breakdown, Gantt chart, phases, deliverables, risks and cost estimate. Assumptions, dependencies and acceptance criteria should also be explicit. Fixed Price and Time & Materials require different levels of scope certainty and change/risk management. Choose a commercial model based on uncertainty, not habit.

12. Second role-play: a strong product can miss the core business

Another student team presented a fictional technology company with a strong niche and demonstration product. The presentation began with a motto, without adequate team introductions or a clear agenda. The lecturer paused the exercise, provided focused feedback and requested a revised introduction.

The central issue appeared later: the product story barely matched the fictional customer's core business in industrial automation. The phrase core business was a reason to stop the promotional monologue and explore whether other company activities could offer a point of cooperation. The case is fictional; participants' product performance claims are not treated as verified facts.

13. An adjacent business as an entry point—without invented fit

After a clarifying question, the fictional customer mentioned another area of activity that needed intelligent software components. The team saw that some of its expertise might be transferable to this context, which justified discussing a separate meeting and future proposal.

The key lesson is: a poor fit with the core business does not imply that no opportunity exists, but related technology does not prove suitability either. Application context, constraints, compliance, ownership and the real portability of components must be checked. This public teaching note intentionally does not include operational descriptions of the fictional military use case or autonomous targeting techniques.

14. Partnership, contracting and intellectual property

Toward the end of the second scenario, the participants debated whether the company should be a vendor of engineering services or insist on a partnership arrangement. The students argued for retaining rights to their previous work rather than automatically transferring all intellectual property to the customer.

The essential distinction is background IP—technology and assets existing before the relationship—and foreground IP, the outputs created under the new project. A contract must address ownership, licences, reuse rights, disclosure under NDA and related obligations. In regulated and defence domains, relevant export, contractual and legal restrictions need separate review. The classroom conversation does not establish a universal legal prohibition of any particular partnership model.

15. End negotiations with artefacts

In both scenarios, success is not measured by eloquence or slide count. What matters is a recorded problem statement, stakeholder, known requirements, unresolved assumptions, owners, next contact date and proposal format. These preserve discovery context for the handoff to Delivery.

It is essential to distinguish achieved results from discussed possibilities: willingness to meet again is not a won bid; a student's Gantt chart is not an approved baseline; a fictional product is not evidence of a supplier's verified technical capability.

16. Practical deliverables for the student team

After role-play, the team should prepare material that can be reviewed in the next class:

• Meeting brief: purpose, roles, agenda, initial questions and desired outcome.
• Account research: concise public facts about the prospect, separately marked hypotheses.
• Discovery log: customer questions/answers, priorities, risks, unknowns and sources of claims.
• Tailored deck: brief introduction, relevant strengths, one or two cases, cooperation models and next step.
• Mini-proposal: problem, scope, assumptions, outputs, phases, staffing, risks and acceptance criteria.
• Delivery draft: initial Work Breakdown Structure, schedule dependencies, Gantt chart and rough budget.

These items are assignments and assessment criteria, not a claim that all student teams had completed them when the recording ended.

17. How practical work is assessed

Strong performance demonstrates five qualities: tailoring the presentation to the customer, disciplined introductions and speaker handovers, asking open and follow-up questions, separating service/product/partnership models, and turning the meeting's outcome into a verifiable artefact.

Factual integrity and confidentiality are also assessed. Names, numbers, contracts or products used in class cannot be promoted as genuine success stories without verification. Technical specifics from a fictional defence scenario are not required to understand the engineering-business method taught here.

Self-check questions

• How is an agreed meeting different from a calendar invite merely being sent?
• Why can Engagement and Partnership advocate different business models in one scenario?
• How can participants clarify their roles without excessive titles and long introductions?
• What question moves from a broad interest to firmware, HAL, middleware or application level?
• Why is a reaction to a slide only a clue, not proof of a need?
• What information must be recorded before proposing an engineering solution?
• When should the Technical Lead speak, and when should Delivery take the lead?
• Which proposal components should follow an RFI before a contract is approved?
• What distinguishes background IP from foreground IP?
• How can one avoid treating a classroom scenario as a verified commercial case?

What was announced next

At the end of the session, the lecturer announced another simulation for the following week involving RFI and RFC: he would temporarily act as Delivery Manager, students would take project-team roles and prepare phases, a Gantt chart, risks, a cost estimate and a short proposal for the fictional customer. This is a plan, not a completed session or a published result. Jira/backlog and implementation may follow after conditions are agreed.