Presenting Technical Proposals

The proposal presentation is not a reading of the document. The audience has the document — or will have it. The presentation is the opportunity to demonstrate the thinking behind the document: why this architecture, why these trade-offs, why this phasing. The presentation earns the trust that the document alone cannot. The client sees the architect think through their problem in real time, respond to questions with depth, and demonstrate the expertise that the document claims.

1. Problem-Solution-Evidence Structure Structure the presentation in three acts. Act 1: restate the problem to demonstrate understanding. Act 2: present the solution architecture with the key trade-offs. Act 3: present the phasing, timeline, and risk mitigation as evidence that the solution is deliverable. This structure mirrors the client's decision-making process: "Do they understand us? Is the solution credible? Can they deliver?"
2. The Architecture Walkthrough Walk through the C4 Level 1 diagram live. Point to each integration with the client's systems and explain what data flows across it. This is where the presentation earns credibility — the architect who can narrate the data flow through the client's systems demonstrates that they have designed for this client, not copied a template.
3. The Q&A as Design Review Treat the Q&A as a design review where the client is the reviewer. Their questions reveal what they care about most. "What happens if the ML model accuracy drops below 85%?" tells you reliability matters more than initial accuracy. "Can we add more ticket categories later?" tells you extensibility matters. Capture every question — they inform the implementation priorities.