Mistral: Why we would keep the memo
We read the seven-page strategic memo in full, and explain why we would retain the memo rather than compress it into a timeline. The memo remains useful supporting material.
Reading the full deck
Reviewed the complete seven-page public strategic memo. It is a document intended to be read. We would preserve the memo and add a brief reading guide, rather than treat its density as a slide-design failure.
Read the source documentThe memo argues that valuable AI models will be controlled by a small number of companies, then presents a European alternative built around access to model internals, data control, and deployment choices. It supports that position with the team, infrastructure plans, commercial exploration, and a dated roadmap. The argument develops across the document; lifting one roadmap page out of it loses the reasons for those choices.
What already works
The memo explains trade-offs in enough detail for a careful reader. It connects technical choices to customer concerns and describes business exploration alongside model development. Its density is often appropriate for a written document. We would preserve the memo as follow-up reading.
Walk through the original, page by page 7 pages reviewed
Page 1 · Market and concentration
Introduces the technology and argues that model builders will hold much of the value. In a meeting, get to Mistral’s specific position sooner.
Page 2 · Customer constraints and Europe
Privacy, access, and opaque data sources establish the proposed opening. Group them by the buyer decision each affects.
Page 3 · Technical differences
Open models, access to internals, data control, and deployment choices are explained in detail. Distinguish what is broadly available from what is reserved commercially.
Page 4 · Business approach and team
Commercial routes and the team appear on one page. They deserve separate attention in a spoken presentation.
Page 5 · Infrastructure, customers, and roadmap
Compute, data relationships, customer exploration, and the first-year plan make execution concrete. The page carries too many threads for a single projected slide.
Page 6 · Dated delivery plan
The page connects dated model milestones to access, integration, and commercial goals. Keep those qualifications; a simple timeline would omit much of the argument.
Page 7 · Later stages and financing
Connects later capabilities, safety work, and financing needs. Keep these as historical plans, not claims about what was subsequently delivered.
What we would change
Add a brief guide to the argument.
At the beginning, summarize the customer constraint, Mistral’s proposed response, and the decision being requested. Point readers to the supporting sections. The underlying reasoning should remain in the memo.
Put the commercial choices beside the technology choices.
Explain who gets model access, what they pay for, and which deployment options address which concerns. The original describes several possibilities; a meeting version should identify the decisions still being tested.
Use separate tracks only in a live presentation.
If a meeting requires slides, separate technical delivery from customer integration and keep the original qualifications. Do not replace the written roadmap with a few headline dates.
The order we’d use
Customer constraints → Mistral’s approach → team → access and commercial options → infrastructure → technical and commercial milestones → financing and next decisions. Send the memo as supporting reading.
The edit we would make
We would retain the original roadmap page. It connects model capabilities, access, integrations, and commercial plans in a way that a three-date timeline cannot. The useful addition is a short guide to the argument and the decision, not a stripped-down substitute.
This page earns its detail.
Mistral’s roadmap is part of a written argument. It explains the first model family, access choices, integration work, later capabilities, and commercial plans. A three-date timeline loses those relationships. We would keep the memo.
What the memo already does well
It describes model development and business development running in parallel. Technical choices have commercial consequences, and the prose makes those connections explicit.
The edit we would make
Add a short reading guide at the beginning of the memo: the customer constraint, the proposed technical response, and the decision being requested. Keep the supporting argument and the dated plan intact.
If this becomes a live presentation
Build separate slides for model delivery and customer integration. Preserve the original dates and qualifications. That is a different format with a different job—not a better version of this page.
Turning a plan into a presentation?
Use the Standard Deck’s summary and roadmap layouts to walk through the decision. These original source pages are not template examples.
See the Standard Deck layouts — $99