The Meeting That Sets the Tone
The kickoff is the first working session after the contract is signed, and it does more good or more damage than any other single meeting in the program. Everything downstream, the schedule, the change process, who calls whom when something breaks, gets its default settings here. Run as a friendly introduction, it produces a project where nobody is sure who decides things. Run properly, it produces a written baseline both sides can point at nine months later.
Expect three to five hours for a moderately complex electromechanical product, often split across two sessions. Remote works fine, and for distributed teams it is the norm; the practical mechanics of running a program that way are covered in developing a product remotely.
Who Should Be in the Room
From the engineering firm: the project manager who will own the schedule, the lead engineer from each discipline the product actually needs, and usually the person who wrote the proposal so that what was promised and what is understood get reconciled in public. If a discipline is central to the product and its lead is absent, ask why.
From your side: whoever holds the budget, whoever will make product decisions day to day, and anyone with irreplaceable domain knowledge. If you are a solo founder those are all you. If you have a manufacturing partner or a distributor already lined up, having them present for the first hour is unusually valuable, because constraints from downstream are cheapest to absorb now.
Keep it small. A kickoff with fourteen people in it becomes a presentation, and presentations do not surface disagreements.
What Gets Put on the Table
A well-run agenda works through five blocks.
The product and the market. You present, not them. Who the user is, what problem the product solves, what it competes against, what the buyer will pay, and what the launch window is driven by. Engineers make hundreds of small judgment calls, and they make better ones when they understand the business context rather than only the specification.
Requirements walkthrough. Line by line through the specification, with the engineering team challenging anything ambiguous, contradictory, or unverifiable. This is where you discover that two of your requirements cannot both be true. If you do not yet have a baselined specification, the kickoff should produce the plan for creating one; see how to write a product requirements document.
Technical approach and known unknowns. The firm presents the architecture they intend to pursue, the alternatives they considered, and the parts they genuinely do not know yet. A team that claims no open technical risks at kickoff is either not being candid or has not read the specification.
Schedule, gates, and deliverables. Not a bar chart with a launch date at the end, but named phases with entry and exit criteria and a specific artifact at each gate. Agree what evidence closes each gate.
Logistics and governance. Meeting cadence, where files live, who is authorized to approve a change, how invoices map to milestones, and what the escalation path is when something goes wrong at 6 p.m. on a Friday.
Decisions That Should Be Made, Not Deferred
- Target production volume and unit cost. Every architecture decision downstream depends on whether you are building 500 units a year or 50,000.
- Target markets and therefore the regulatory set. Adding a market later can invalidate a design; deciding now costs nothing.
- The single decision maker on your side. Named, with authority. Committees are how three-week decisions become three-month decisions.
- Change control process. How a change is requested, who prices it, and who approves it.
- Ownership of design files and IP. This is in the contract, but confirm the practical version: do you receive native CAD and firmware source, or only exported files? The distinction matters enormously, and the background is in who owns the IP in product development.
- Definition of done for the engagement. A working prototype is a different finish line than a released manufacturing package.
What to Bring
Bring the physical things first: any existing prototype, however crude, competitor products you have bought and taken apart, and samples of materials or finishes you like. A cardboard mockup teaches an engineer more in thirty seconds than four pages of description.
Then the documents: your requirements draft, any CAD or sketches, patents or applications, prior test data, feedback from users you have already spoken to, and quotes you have received from other vendors or factories. If you have a target retail price and channel margins, bring those numbers, because they set the cost ceiling.
Finally, bring your questions in writing. Good ones include what part of this worries you most, what has gone wrong on similar projects you have run, what will you need from me and when, and what would cause this schedule to slip. The contractual side of these answers should already be settled, and if it is not, revisit product development contract terms before the meeting rather than after.
The Written Summary Is the Deliverable
Within a few business days the firm should send a kickoff summary: decisions made, action items with owners and dates, open questions, assumptions being made, and any changes to scope or schedule agreed in the room. Read it carefully. Assumptions are the part people skim, and an assumption you did not notice becomes a change order later.
If the summary does not arrive, or arrives as three bullet points, that is real information about how the project will be documented. It is the kind of signal worth weighing while choosing a partner, alongside everything in how to choose a product design firm and the warning list in red flags when hiring an engineering firm.
Keep the summary. It is the baseline against which every later argument about scope gets settled.
Start Your Project on a Solid Baseline
Projects House runs structured kickoffs that end with a written baseline, named gates, and a change process both sides understand. Tell us about your product and where it stands through our contact form.