Books

This is the first time we publish The Medical Futurist's Technology Adoption Curve, showing 50 of the most promising digital health technologies the way we, at The Medical Futurist, see them today. 

You want to analyse, understand and capture the subject matter of a domain, typically because you want to build a software system in that domain? You're looking for abstractions to describe and ultimately execute said subject matter? Then this book is for you: it's chock-full of experience and practices for tackling this challenge.

This book brings the fundamentals of Machine Learning to you, using tools and techniques used to solve real-world problems in Computer Vision, Natural Language Processing, and Time Series analysis. The skills taught in this book will lay the foundation for you to advance your journey to Machine Learning Mastery!

Palantir: Spy-tech, enterprise AI, or the architect of Operational Sovereignty? This unparalleled Second Edition analysis (current as of December 2025) cuts through the hype and controversy to reveal Palantir's core technology, its path from meme stock to S&P 500, and its unique strategy for a complex age. Essential insights await.

Hai mai sentito dire “facciamo gli OKR come Google”?Bene. Questo libro inizia proprio spiegando perché non dovresti farlo. Tra aneddoti, canvas colorati e qualche camicia hawaiana di troppo, scoprirai che gli OKR non servono a correre più forte, ma a capire dove vale la pena andare.

The most advanced (show me!) systems engineering writing on the 'constraints' subject. For technical leaders.

Dive into the heart of innovation with the Data Hub Framework—a strategic blueprint transforming raw data into valuable insights. Uncover the layers shaping operational brilliance, customer satisfaction, and unparalleled data-driven value. Welcome to the future of data strategy.

Chapter 1: Welcome to the CasinoThe Planning Meeting Nobody Talks About Look around the room.There are eight people at this table. Four engineers, a product manager, a Scrum Master, a VP of Engineering, and a Director of Product who is visiting from the floor above and has brought her laptop, which she is not quite looking at. The calendar invite said "Sprint Planning" and blocked two hours. It is currently running at two hours forty minutes and nobody has acknowledged this.On the screen at the front of the room there is a spreadsheet. The spreadsheet has a column called Velocity and a column called Points Remaining and a column called Sprints To Go and a column called Projected Completion. The Projected Completion column says October 14.Nobody in this room believes October 14.The VP of Engineering, whose name is James, has been looking at a slightly different version of this spreadsheet for six months. Every two weeks the Projected Completion date moves. Not dramatically — two days here, a week there, occasionally a fortnight when a sprint goes badly sideways. The date has moved, in aggregate, eleven weeks since the project started. James has learned to present the date in a tone that suggests it is stable. He has become, without intending to, an expert in the performance of confidence he does not feel.The Director of Product, whose name is Miriam, knows the date is wrong. She has been in this industry for fourteen years. She has attended hundreds of sprint reviews. She has heard the date presented in exactly this tone — measured, considered, slightly defensive — at least forty times before. The date was wrong forty of those times. She is already doing the mental arithmetic for her own planning: take whatever James says and add eight weeks.The engineers know the date is wrong. The one sitting closest to the door — her name is Fatima, she has been on the project since week one — privately believes the project is at least sixteen weeks from completion. She has not said this out loud because the last time she said something like it, in a retrospective three months ago, the conversation became uncomfortable in a way that took two weeks to fully dissipate.The Scrum Master knows the date is probably wrong. He is twenty-six years old and this is his second job and he has not yet developed the vocabulary to say so in a way that will be heard rather than dismissed.The product manager knows the date is wrong and has already sent a Slack message to a peer in another department that says, essentially, don't count on October 14.Eight people in a room. Every one of them knows, to varying degrees and with varying specificity, that what is written on the screen does not correspond to reality. Nobody says so. The meeting continues. October 14 becomes the plan.This is not a dysfunctional team. This is a normal team. This is every team. This is the planning meeting that happens every two weeks at thousands of companies across the industry, in slightly different rooms with slightly different spreadsheets and slightly different versions of James and Miriam and Fatima — all performing the same ritual of false certainty that everyone in the room recognises as false and nobody has the structural support to name.Welcome to the casino. The Chips on the TableHere is what is actually at stake in that room.The October 14 date was mentioned to a customer in a sales call. Not committed to — mentioned, in the way that salespeople mention things when they are trying to close a deal and the prospect needs a rough timeline. The sales rep said "we're targeting Q4" and the prospect heard a commitment. There is now an enterprise contract in negotiation with an implied dependency on something in Q4.The October 14 date was included in a board update. Not the P50 from a Monte Carlo simulation — there is no Monte Carlo simulation. Just the number from the spreadsheet, presented as the plan. The board is making capital allocation decisions that touch this date.Two engineers were hired to help hit the October 14 date. They started three weeks ago. They are still ramping. They have, in the short term, reduced the team's throughput while they get up to speed — which is one of the reasons the last sprint came in below average, which is one of the reasons the Projected Completion column moved again.Fatima has been quietly considering a competing offer for two months. One of the things keeping her on the fence is that she doesn't want to leave in the middle of a project. The project, as represented by the spreadsheet, is six weeks from done. The project, as she understands it from the inside, is four months from done. If she knew the honest number, she would make a different decision about her career.The chips on the table are real. Customer relationships, capital allocation, hiring decisions, the career calculations of engineers who deserve accurate information — these are not abstract. They are denominated in money and time and trust and the professional lives of actual people.The spreadsheet is lying to all of them. What Velocity Was Supposed to BeBefore we go any further, let's be fair.Velocity was not designed to do this. The people who introduced it into software development were not trying to create a planning casino. They were trying to solve a real problem: how does a team know if it is moving at a sustainable pace? The original intent of velocity was as a team health metric — a rough signal, used internally, to help teams understand their own capacity and avoid over-committing. Not a forecast. Not a commitment. A pulse check.The corruption happened gradually and then all at once. Managers discovered that velocity numbers existed and requested them in status updates. Status updates became roadmap inputs. Roadmap inputs became commitments. Commitments became the basis for customer contracts, investor decks, hiring plans, and board presentations. The metric that was designed to help a team reflect on its own pace became the instrument by which that team's pace was judged, reported, and planned against by people who had no visibility into the assumptions baked into the number.Goodhart's Law arrived, as it always does: when a measure becomes a target, it ceases to be a good measure. Teams under pressure to maintain velocity learned to size stories generously. Generous sizing produced stable velocity numbers. Stable velocity numbers produced credible-looking spreadsheets. Credible-looking spreadsheets went into board decks. Board decks got funded.Nobody set out to build a casino. They built one anyway, one sprint at a time, one comfortable fiction stacked on another.The result is the room we described at the top of this chapter. Eight people. One wrong date. Everyone knowing. Nobody saying. The Gambler's PsychologyThere is a moment in a casino, familiar to anyone who has spent time at a card table, when the gambler knows the night is going in the wrong direction. The cards are cold. The stack is shorter than it was an hour ago. The rational decision — leave now, cut the loss, come back another night with a clear head — is obvious.The gambler doesn't leave.What keeps the gambler at the table is not stupidity. It is a set of cognitive mechanisms that evolved to serve humans well in environments that do not include card tables — and that malfunction badly at card tables, and at sprint planning meetings.The hot hand fallacy says: the last three sprints were good, we're in a streak, this momentum will continue. The gambler's fallacy says: we've had four bad sprints, we're due for a good one. Anchoring says: we told the board Q4, we have to make Q4 work, the original date structures all our thinking. Confirmation bias says: the burndown chart is actually fine if you interpret it the right way. Availability bias says: the one sprint that went smoothly is the one we keep talking about.These are not character flaws. They are features of human cognition that work well in many contexts and catastrophically in the specific context of software planning. They operate below the level of conscious attention. They run in the background while the intelligent, experienced, well-intentioned people in the room do their best to produce an honest forecast — and they corrupt the output anyway.The planning meeting is not a casino because the people in it are gamblers. It is a casino because it is designed the same way a casino is designed: to favour a specific outcome — the comfortable fiction, the confident date, the plan that ends the meeting — over the accurate picture of reality that would serve everyone at the table better.The casino is the architecture, not the people. What This Book IsThis book is for Fatima.It is for James, who is performing confidence he doesn't feel and deserves a better tool than the one he has. It is for Miriam, who has been adding eight weeks to every estimate in her head for fourteen years and would like to stop having to do that. It is for the Scrum Master who doesn't yet have the vocabulary. It is for the product manager who already sent the Slack message.It is for the engineers who have been told their velocity is too low and have responded by inflating their estimates — who know that this is wrong and do it anyway because the system gives them no alternative.It is not for the people who designed the casino. It is not aimed at dismantling the industry's planning mythology from the outside. It is aimed at the people inside the myth who can see it clearly and need both the analytical tools and the political vocabulary to push back.Here is what you will learn.Part II will give you the cognitive map of the biases that run the planning meeting. The hot hand fallacy, the gambler's fallacy, anchoring, confirmation bias, availability bias, survivorship bias — named, explained, and illustrated with specific people in specific companies making specific decisions that cost specific amounts of money. You will recognise these patterns. You have lived most of them.Part III will give you the statistical case. Not formulas — the concepts, in plain English, with the mathematics in an appendix for those who want it. You will understand coefficient of variation and why a CV above 30% makes velocity-based planning meaningless. You will understand fat-tailed distributions and why your disasters are ten times more likely than your model assumes. You will understand sample size and why eighteen sprints of data is not enough to support the confidence you're placing in it.Part IV will give you the tools. Monte Carlo simulation, explained well enough that you can run it in a spreadsheet by the time you finish the chapter. Sensitivity analysis that shows you scope is a more powerful lever than estimation accuracy by a factor of five. Bayesian updating that makes your forecast smarter as the project progresses rather than more defensive.Part V will give you the replacement system. Cycle time instead of velocity. Throughput instead of points. The probability roadmap. The pre-mortem and the designated skeptic and the forecast tracking spreadsheet. The five-component honest forecast and the three responses to "you seem uncertain."And it will give you the conversation — the one in the board meeting, the one with the CFO, the one with the customer who has a contract dependency on a date — done honestly, with confidence, armed with something better than a comfortable lie. The Only Promise This Book MakesThis book will not make software development predictable.Software development is not predictable. It involves human beings working on problems that have never been solved before, with tools that are evolving as they use them, in organisations that change around them. Uncertainty is not a bug in this process. It is a feature of the work itself.What this book will do is make your uncertainty legible. Nameable. Measurable. Presentable to a CFO without apology. It will show you how to tell the difference between the uncertainty that can be reduced — through scope management, team stability, batch size reduction — and the uncertainty that cannot, and must simply be accounted for honestly in the forecast.The teams that have made this shift — Priya Nair at Bridgeport Analytics, Cassandra Obi at Lakeshore Health Technologies, Robert Okafor at Thornfield Software, Daniel Achebe at Northgate Capital Systems — did not suddenly become better at predicting the future. They became better at describing their uncertainty accurately, and building planning systems that work with uncertainty rather than against it.Their stakeholders, initially resistant, eventually came to prefer the honest forecast over the confident fiction. Not because uncertainty is comfortable. Because trust built on reality is durable in a way that trust built on false certainty is not.The date on the spreadsheet says October 14.Nobody in the room believes it.That is not a planning meeting. That is a casino where everyone at the table knows the house is winning and nobody has said so yet.This book is the moment someone says so. Key TakeawaysThe planning meeting where everyone knows the date is wrong but nobody says so is not a dysfunctional exception — it is the industry norm. The room described at the top of this chapter is every room. The performance of false certainty is learned behaviour, not individual failure.The chips on the table are real. Customer commitments, board decisions, hiring plans, and the career calculations of engineers who deserve accurate information — all of them denominated in the date on the spreadsheet.Velocity was not designed to be a planning instrument. It was a team health metric. The corruption from internal pulse check to external commitment happened gradually and then all at once, one stakeholder request at a time.The cognitive biases that run the planning meeting are not character flaws. They are features of human cognition operating in an environment they were not designed for. Awareness alone does not fix them. Architecture does.The casino is the architecture, not the people. The planning system is designed — whether intentionally or not — to favour the comfortable fiction over the accurate picture. Redesigning the system is the intervention.This book is for the people inside the myth who can see it clearly. Not a dismantling from the outside — a toolkit for the people already in the room who need the analytical tools and the political vocabulary to push back.Uncertainty is not the enemy. It is a feature of the work. The goal is not to eliminate it but to make it legible, measurable, and honestly presentable — so that real decisions can be made on real ground. Coming Up NextBefore we get to the cognitive traps and the statistical failures and the replacement system, there is one question that deserves a direct answer.How did we get here?Velocity was a good idea once. It served a real purpose for the teams that invented it. Understanding exactly how it went from a useful internal calibration tool to the instrument of a planning casino — the corruption sequence, the specific decisions, the specific pressures that turned a team health metric into a commitment mechanism — is not just historical context.It is a warning about what happens to any metric when an organisation decides it is too useful to stay honest.Chapter 2 is the story of how a good tool became a bad one. It is, in miniature, the story of the entire book. Want to keep reading?The Gambler's Fallacy is available now on LeanPub in PDF and EPUB.You've just met James, Miriam, and Fatima. The rest of the book gives you everything you need to change the meeting they're trapped in — the cognitive map, the statistical tools, and the replacement system that turns false certainty into defensible, honest forecasts.Suggested price: $24.99 — or pay what you feel it's worth.Get the full book on LeanPub → © 2026 Theo van Stratum, PhD. All rights reserved. This preview chapter may be shared freely for non-commercial purposes with attribution.

A Unified Theory of Influence—From Ancient Persuaders to AI Futures Influence is everywhere: in the parent teaching a child, the advertiser crafting a message, the algorithm curating a feed, the state deploying propaganda. Yet we lack a comprehensive framework for understanding influence across these domains. This book provides one. Influencers and the Influenced integrates memetic theory—the study of cultural replicators—with persuasion psychology and network science to explain how ideas, beliefs, and behaviors spread through populations. The analysis spans from humanity’s earliest influencers (parents, priests, teachers) through the contemporary landscape of social media creators to speculative futures involving artificial intelligence and post-human cognition.

Most people try to get clients by promoting themselves.This book shows a different approach.Community Authority Marketing explains how consistent participation in online communities can turn visibility into inbound client conversations—without ads, cold outreach, or aggressive selling.Instead of chasing attention, you’ll learn how to build authority through teaching, advising, and showing proof over time.The result is a simple, repeatable system for attracting clients naturally.

Product teams are shipping more than ever. Outcomes are getting harder to explain. Roadmaps promise certainty. Backlogs stay full. Delivery speeds up. Yet value lags behind effort and learning arrives too late. The Operating System of Product explores why this happens and what replaces it. It shows how product work changes when execution is no longer the bottleneck and why roles, prioritisation and feedback loops must evolve together. This is not a book about better roadmaps. It is about replacing the system that needs them.

In The Paradox of Progress, Amir Bagherpour shows that success depends on how societies and organizations navigate rapid technological change, including large-scale economic displacement and a fundamental shift in the nature of work. While history offers parallels in past industrial transformations, today’s transition is unfolding on a dramatically compressed timeline—advancing at many times the velocity of the Industrial Revolution.By blending economic history with data-driven analysis, Bagherpour explains how the rate of adaptation determines whether progress strengthens or destabilizes the status quo. Drawing on advanced forecasting and simulation results, the book offers practical insights for leaders seeking to harness rapid technological change to build durable economic and institutional strength.

Master the journey from on-premises to the cloud! This comprehensive guide unlocks the secrets of migrating Business Central, Dynamics NAV, and Dynamics GP workloads to Business Central online. Learn how to plan migrations, configure Azure Data Factory pipelines, handle incremental replication, and execute successful cutover strategies. Whether you're preparing for MB-820 certification or leading your first cloud migration project, this is your complete roadmap from planning through go-live and beyond.