
- David Senra — Made an episode about the autobiography, calling it “incredible” and singling out how “unapologetically extreme” Bloomberg is. source ↗
Michael Bloomberg's autobiography, recounting his firing from Salomon Brothers in 1981 with a severance payout, and how he used that capital and his Wall Street trading-floor experience to found Innovative Market Systems — later Bloomberg LP — building the Bloomberg Terminal from scratch when off-the-shelf computers couldn't do what he needed. The book covers landing Merrill Lynch as an early investor and customer, out-executing larger, slower-moving competitors in financial data, and his approach to building a company culture around openness, product obsession, and constant iteration.
Founders covered this book in episode #228, and David Senra frames Bloomberg's story as a case study in turning a forced ending into a founding moment. Getting pushed out of Salomon Brothers with a severance check, rather than derailing him, became the funding and the freedom to build something of his own — Senra repeatedly uses this as an example of founders needing to treat rejection or firing as raw material rather than a verdict on their worth.
The second lesson is Bloomberg's insistence on building the product himself when nothing on the market fit the need: with no suitable off-the-shelf terminal for financial professionals, he built proprietary hardware and software from first principles, informed by his years actually sitting on a trading floor and understanding the workflow better than any outside vendor could. Senra frames this as the founder advantage of deep domain obsession — you build the tool you wish existed because you were the desperate customer first.
The third theme is speed and iteration over long-range planning. Bloomberg prioritized shipping, getting feedback from users like Merrill Lynch (an early investor and customer), and continuously improving the terminal rather than locking into a rigid multi-year roadmap. Founders draw from this the discipline of staying close to the actual user, iterating in public, and letting real usage — not internal planning — dictate what to build next.