Project Maven

Every so often a book lands squarely at the intersection of everything you've spent a career doing. Katrina Manson's account of Project Maven — the effort that grew into today's Maven Smart System — is that book for anyone who has worked capability development, experimentation, or the hard business of moving technology from a lab into the hands of soldiers.

What the Book Argues

Manson traces Maven from its 2017 origins under Marine Colonel Drew Cukor through nearly a decade of development: Google's high-profile withdrawal in 2018, Palantir's takeover of core development, and the system's eventual deployment across every branch of the military, incorporating more than 150 data feeds and the work of dozens of companies. Along the way, targeting timelines that once took hours collapsed to minutes.

Her deeper argument is about how it happened. Maven succeeded not because the Pentagon's acquisition system worked, but because a small, driven team worked around it — iterating directly with operational units, accepting imperfect early versions, and letting battlefield feedback drive development. It is, in effect, a book-length case study in experimentation done under pressure.

Where It Holds Up

The experimentation story rings true to anyone who has run one. What Manson describes — commercial imagery, algorithms, and operators in the loop, refined exercise by exercise until targeting data that took half a day moved in under a minute — is Battle Lab methodology executed at scale and under consequence. The XVIII Airborne Corps' Scarlet Dragon series, which figures in the Maven story, is exactly the model of iterative, soldier-centered experimentation that capability developers have argued for over decades: put the prototype in the formation, measure honestly, fix what breaks, repeat.

The lesson isn't that AI won. It's that iteration won — the willingness to field the 70% solution, learn from contact, and improve faster than the requirement process could have written a document.

Manson is also honest about the friction. The bureaucratic resistance, the cultural fights, the tension between a program office mindset and an operational-tempo mindset — she reports these without flattening them into villains and heroes. Leaders who have carried a new capability through an institution will recognize every chapter.

Where It Falls Short

Two critiques. First, the narrative gravitates toward personalities — Cukor, the Palantir leadership, the Silicon Valley drama — sometimes at the expense of the unglamorous machinery that actually institutionalizes a capability: the training pipelines, the sustainment tail, the doctrine writing, the integration into staff processes. Heroic-founder stories are readable, but capabilities that outlive their founders are built by systems, not personalities.

Second, the book is stronger on speed than on validation. Faster targeting is only a virtue if the targets are right. The hard experimentation questions — measures of effectiveness, error rates, what "human on the loop" means at machine tempo — get less rigorous treatment than the acquisition drama. That's the part practitioners most need examined.

What Leaders Can Use

Three takeaways worth applying regardless of your industry. First: prototype with the user, not for the user — Maven's progress came from operators touching the tool early and often, not from perfecting requirements documents. Second: protect the small team — every consequential capability effort in the book depended on leadership cover that shielded a small group from institutional antibodies long enough to show results. Third: instrument your experiments — the difference between experimentation and tinkering is honest measurement, and the parts of the Maven story that endure are the parts that were measured.