Before writing a single chapter, you need to answer two questions with absolute clarity: What is this book about? and Who is it for? Every decision you make afterward flows from these answers.
The most common mistake aspiring technical authors make is centering their book on a technology rather than a problem. “A book about Kubernetes” is a topic. “A book that teaches backend developers how to deploy and manage containerized applications in production” is a purpose.
Readers do not buy books because they want to learn a tool. They buy books because they have a problem and believe the tool can solve it. Your job is to bridge that gap.
Ask yourself:
Write down a single sentence that captures your book’s purpose. Refine it until it is sharp. This sentence will guide every structural and editorial decision.
“Everyone who wants to learn X” is not a target audience. A book that tries to serve beginners, intermediate practitioners, and experts simultaneously serves none of them well.
Define your reader as a specific person:
Create a fictional reader persona. Give them a name, a job title, and a scenario. For example:
Maria is a backend developer with 3 years of experience in Python. She works at a mid-size startup and her team is migrating from a monolithic application to microservices. She has heard of Kubernetes but has never used it. She needs to understand not just the “how” but the “why” behind container orchestration to make good architectural decisions for her team.
When you write, write for Maria. Every time you wonder whether to explain a concept or skip it, ask: “Would Maria need this?”
Scope is the boundary of what your book covers and, just as importantly, what it does not cover.
A book with too narrow a scope feels like a long blog post. A book with too broad a scope becomes a superficial overview. The right scope gives readers a complete understanding of one well-defined domain.
The Deep Dive: Covers one technology or concept exhaustively. Assumes some prior knowledge. Example: “Effective Java” by Joshua Bloch.
The Practical Guide: Walks readers through building something real, teaching concepts along the way. Example: “Flask Web Development” by Miguel Grinberg.
The Survey: Covers a broad field at a consistent depth, giving readers a map of the territory. Example: “Designing Data-Intensive Applications” by Martin Kleppmann.
Decide which archetype fits your book. This determines how deep you go and how wide you spread.
Write down what your book will NOT cover. This is as important as the table of contents. It prevents scope creep and gives you permission to say “that’s outside the scope of this book” while writing.
Examples:
Before investing months of work, validate that there is demand for your book.
Share a draft table of contents with 5-10 people who fit your target reader profile. Ask them:
Their feedback will tell you more than weeks of introspection.
Combine your purpose, audience, and scope into a value proposition: a short paragraph that explains what the book is, who it is for, and what the reader will gain.
“This book teaches mid-level Python developers how to build, deploy, and operate microservices using Kubernetes. Through practical examples and real-world scenarios, readers will go from zero Kubernetes knowledge to confidently managing production workloads. No prior container experience is required, but familiarity with Python web frameworks is assumed.”
This paragraph serves as your north star. Pin it to the wall above your desk.
| ← Introduction | Table of Contents | Chapter 2: Structuring a Technical Book → |