The Book your Analytics Work is Already Most of the way Toward

Most data people have written a book already. It is just scattered where nobody can find it.

There is the onboarding doc you wrote because the last three hires asked the same five questions. The notebook with forty markdown cells explaining why the naive uplift number was wrong. The wiki page about the metric your team retired and the reason it was retired. The deck for the internal training session you have now run four times. Add it up and you are often sitting on twenty to thirty thousand words of material that has already survived contact with a skeptical audience, which is more than most first drafts can say.

Turning that into a book is a real project rather than a formatting exercise, and the part people get wrong is the arithmetic, so most of what follows has numbers in it. Your analytics experience already builds a strong foundation for an artificial intelligence course, helping you understand data, patterns, and decision-making before moving into advanced AI concepts.

Start with the size question

A 6 by 9 inch paperback set at 11 point with ordinary line spacing holds roughly 300 words a page. So a 250 page book is about 75,000 words. That is what people picture when they say “a book”, and picturing it is why most technical books die in month five.

You do not need that. Practical guides in a narrow area regularly land between 35,000 and 50,000 words, which prints as 120 to 170 pages. Amazon’s paperback minimum is 24 pages. A 40,000 word book on how to run and read experiments inside a company that has no data science team is a book. A 75,000 word book on “data analytics” is a textbook, and you are not going to finish a textbook in your evenings.

Pick the narrow one. It also sells better. Someone searching for marketing mix modeling in Python is a buyer. Someone searching for data science is a browser.

The material that does not survive the move

Almost none of your best examples can be published as they stand. The interesting case study is interesting because it happened at your employer, with their data, under a contract that says you will not do this. Internal metric definitions leak more about a business than most people realise, and a churn model whose features are named after your own product surfaces is a competitive document.

So you rebuild the examples. The UCI Machine Learning Repository, data.gov and the New York City taxi trip records will carry most of what a Python or SQL chapter needs, and the taxi data is large enough that performance points land honestly instead of being cute. Kaggle works too, but check the licence on each individual dataset rather than assuming the platform grants you anything.

Budget about a day for every chapter that has code in it. Rebuilding an example so the numbers still make the point you originally made takes longer than writing the prose around it, and it is the single most underestimated line in the plan. On the upside, the rebuilt version is the one your readers can actually run, which the original never was.

Outline with a word budget attached

A list of chapter titles is not an outline. Give each chapter three things: the question it answers, the artifact the reader has at the end of it, and a word count.

A worked version. Twelve chapters at 3,000 words each is 36,000, and front and back matter adds perhaps 2,500 more. That is a 130 page paperback and a very respectable ebook. Now the plan can be checked. If a chapter cannot name the thing the reader can do when they finish it, it is a topic rather than a chapter, and it should be merged into its neighbour or cut. Two or three chapters usually fail that test, which is a good thing to discover in week one rather than week nine.

The word count per chapter matters more than it sounds. It converts an unbounded task into a measurable one, and measurable tasks get finished.

Where drafting help pays and where it costs you

Analysts stall at chapter four. Not for lack of knowledge, which is the whole point of the book, but because producing 3,000 clean words twelve times is a different skill from knowing the material, and it is a skill most technical people have never had to build.

That is the gap an AI book writer is built for, and the difference from a chat assistant is what it drafts against: an outline you approved rather than your last message, with a sample of your existing writing as the reference for tone, so chapter nine still sounds like chapter one. On the platform I use you can get the full plan and a first chapter back before paying anything, which is enough to find out whether the output is worth editing or whether you are better off writing it yourself.

Now the limits, because they matter more here than in most subjects. A model does not know your company’s definition of activation, it does not know which of two contradictory papers your field actually follows, and it is confidently wrong about version specific behaviour in libraries that changed their API. Anything it produces near a code block is a hypothesis. Treat the draft as a first pass that removes the blank page problem and moves the work to editing, which is where a technical author is genuinely good.

Code in a book breaks in ways prose does not

Reflowable EPUB wraps long lines wherever it feels like, so a 110 character pandas chain becomes four ragged lines with no indentation left. Keep code lines under about 65 characters and they survive both the paperback and the ebook. That means shorter variable names than you would use at work and intermediate assignments instead of chained calls, which is annoying and worth doing anyway.

Put the runnable version in a public repository and reference it. The book carries the lines that make the point, the repo carries the imports, the fixtures and the environment file. State your versions in the front matter, Python 3.12 and pandas 2.2 or whatever you actually used, and print the month the book was finished. Readers are forgiving about a dated book and unforgiving about a book that pretends to be timeless.

Technical review is not a formality

Find two readers. One who knows the subject better than you do, and one who is exactly your target reader and knows none of it. The expert catches the claims that are subtly false. The novice catches the sentence in chapter two that assumes something you never explained, which is the error that actually loses readers.

Then run every code block yourself, in a clean container, from a fresh checkout. Not the notebook where you wrote it. The number of listings that only work because of a variable defined in a cell you deleted is higher than anyone expects.

Finding the expert reader is the part I have no reliable method for. Asking in a subject specific community worked twice for me and produced silence the third time. Offering to review someone else’s draft first works better than asking cold, and it costs you a weekend.

What publishing it does, and what it does not

It does not pay you. A niche technical book sells in the hundreds. Amazon pays 70 percent on ebooks listed between $2.99 and $9.99 and 35 percent outside that band, and takes a small delivery fee off the 70 percent option, so a $9.99 ebook nets you a little under seven dollars. Paperbacks pay 60 percent of list minus print cost, and print cost on a 250 page black and white 6 by 9 in the United States is around four dollars. Four hundred copies over two years is a few thousand dollars. It is not a salary and it is not a side business.

What it does is change the kind of conversation people have with you. A book is the strongest artifact you can put in front of a hiring committee, it is what turns a conference application into a keynote, and it is a thing you can hand a client instead of explaining your approach for the fourth time. Those returns are real and they are indirect, so decide up front which one you are after. If the answer is money, write a course instead.

A schedule that survives a full time job

Two weeks for the outline and for rebuilding the datasets. Eight weeks at one chapter a week. Two weeks for review, code verification, cover and formatting. Twelve weeks at five or six hours a week, which is one long evening and one slow Sunday morning.

The version of this that fails is the one that starts with chapter one on a Sunday afternoon. The version that works starts with a list of twelve questions you are already tired of answering.