The Book I Was Writing Was Not the Product I Ended Up Building

I started with a manuscript and a few thoughtful readers. The first thing I had to build was a better place for a conversation.

The first version of the product was a book. That was what I thought I was making, anyway.

I had a manuscript that was far enough along to read but not finished enough to leave alone. I wanted a few thoughtful people to go through it while I could still change it. I was not looking for applause. I wanted the kind of response that makes a book better: a question in the margin, a place where the argument loses its footing, a paragraph that seems clear to the writer but leaves a reader outside the room.

I had reread the manuscript enough to become a poor judge of its first impression. I knew what I meant by every sentence, which made it harder to notice what a new reader could not know yet. Early readers could show me where their attention changed, where they paused, and where a recommendation would be more useful than a general reaction. The request sounded simple: read at your own pace and tell me what to change while the text was still changeable.

So I did the obvious thing. I sent them the file.

The arrangement seemed simple. A reader could open the book on a phone, tablet, or computer. I could ask for notes, and they could send them back. Files had been doing this job for years.

The readers could read. That was not the same as being able to respond.

A file is good at leaving

The manuscript traveled well. It could be attached to a message and opened somewhere else. It did not need an account, a tour, or an explanation of a new system. From my point of view, the file had done its job the moment it arrived.

From the reader’s point of view, the real work started after that. The phone made this visible.

One early reader was working through the manuscript on a phone in the gaps between other parts of the day. They reached a passage they wanted to suggest changing. To tell me which passage, they left the book, copied a few words, and sent a message describing it as near the beginning of a chapter. I opened the manuscript, searched for the copied phrase, and tried to decide whether the note referred to the paragraph before it or the one after it.

The recommendation was useful. Finding its place was work neither of us had intended to do.

After messages like that arrived, I would keep the message open while searching the manuscript, then copy the response into a separate set of notes. If another reader referred to the same section, I had to compare two descriptions and decide whether they were talking about the same passage. The work was not technically difficult. It simply took attention away from the book and put it into the bookkeeping around the book.

That small exchange changed how I understood the mobile problem. The phone was more than a smaller screen. It was where the reader was having the thought. At the exact moment when a response became possible, the file asked the reader to leave the reading context, remember where they were, and start again in another place.

General reactions were easy to remember. Specific reactions were easy to lose. The problem was not a missing comment box. It was the distance between what was being read and where a reader was expected to answer.

The “simple” workflow kept adding steps

My first instinct was to keep the file and improve everything around it.

I could ask readers to mention chapter and page, suggest a format for their notes, or move the discussion to a shared document or email thread. Those workarounds helped only if the reader did extra work at exactly the moment a thought occurred. If the file changed, page references could drift. If two readers responded to the same paragraph, I had to reconstruct whether they were part of one conversation or two.

Every workaround moved labor between the reader and the writer. None kept the passage, the response, and the surrounding thought together.

I was treating the book as a package of text and feedback as a separate activity around it. The reader experienced them as one act: reading in order to think, then trying to respond before the thought disappeared. The boundary existed mostly because the file format made it convenient.

Files are persuasive because they look complete. They have a name, a size, a cover, and a familiar icon. They can be moved from one place to another without asking much of anyone. A file gives you a strong feeling that the work has been delivered.

But delivery is not the same as continuation. A manuscript being read by other people is also a conversation that hasn’t finished forming yet.

I was solving for possession instead of participation

The language I eventually used for the problem was possession versus participation.

The traditional digital-book workflow answers one question well: how does a reader get a copy and open it later? I needed it to answer a different one: what happens around the book after the reader starts reading?

The file was optimized for possession. The feedback loop needed participation: a reader should be able to enter the same text, locate a thought, leave a useful response, and return to the work as it changed. That distinction came directly from the phone and the missing passage in the message. I had not started with a product philosophy.

The change I needed was modest. I did not need to turn the book into a project-management tool or expose every possible interaction. I needed to move the reading experience somewhere that could keep text and response close while preserving the quiet of reading.

The web seemed like the natural place to test that idea. A web page was not automatically a better book, but a link could point readers to the same text. It could reduce the distance between “I have a thought” and “I can show you where it came from.”

The first reader was not a platform

I made an early browser-based reader for the manuscript.

I was not trying to make a publishing strategy or map the future of books. The reader was a small test: could the distance between reading and responding become shorter without flattening the reading experience?

The first success was practical. A reader could open the same text from a link, see the passage in its surrounding argument, and respond without beginning by reconstructing the location. The browser did not solve every problem of reading. It changed the starting condition. The reader no longer had to treat the text and the response as two unrelated tasks.

For someone reading on a phone, the difference was small but important. If a thought appeared, the route back to the book was a link rather than an attachment buried in a message. For me, the response arrived with a place to start looking. We had not solved the work of revision, but we had stopped losing time before the revision could begin.

That mattered because context is not decoration. When the reader and writer can see the same passage and the same version of the work, a response has somewhere to land. The person reading the book does not have to become a systems operator before doing the work of reading.

This was the point at which the project stopped being only about my manuscript. The original problem was personal and specific, but the pattern appeared anywhere people read unfinished work together. A file was good at transporting text. It was less good at carrying the life that gathered around it.

I did not begin by deciding that this deserved a company or a suite of products. I began by trying to keep one conversation from falling away from one book.

The product appeared in the gap

Eventually, the browser reader became the seed of ReaderPub.

That name came later than the problem, and the problem stayed more useful than any early description of the solution. Whenever the work drifted toward building a general system, the original question pulled it back: what does a reader need in order to stay with a book and answer it well?

I had started by wanting feedback on a book. In reality, I was asking readers to help me change it. The format I chose was designed to complete a delivery, not to support an unfinished conversation.

The book I was writing was not the product I ended up building. The first thing I had to build was a better place for a reader to say, “I’m here. I’m looking at this part. Let’s talk about what it is doing.”

That left me with a more difficult question than the one I started with: if a book file is the wrong way to ask for help, what should a reader receive instead?

?