Breshly News

Today’s post is by programmer and writer Pete Millspaugh.

---

Earlier this year I left a job I liked at an early stage startup to write a book. To most people I talk to that sounds like quite a leap, but the nature of the work has been surprisingly similar.

Since I started writing dot com et al: the secret life of domains, I have been searching for book-market fit, just as startups search for product-market fit. I’ve been interviewing potential readers, just as startups interview potential customers. I’ve been reading and studying comparable books, just as startups keep an eye on competitors and companies they admire. I’ve been iterating fast by writing an email newsletter and tweeting in public, just as startups publish blogs and post on social media.

Writing my book like I’d run a startup has helped me build confidence and conviction about who my readers are and what they’re interested in—and perhaps as importantly, what they’re not interested in and who I’m not writing to. It has allowed me to naturally market my book and be clear-eyed about its potential.

Book-market fit

Startups try to find product-market fit. That is, they try to make something people want (and are willing to pay for). I am trying to find book-market fit. I want to write a book people will pay for and read.

Street artist fnnch refers to a similar concept for his paintings as image-market fit in his essay, How to Make a Living as an Artist:

There is a concept in entrepreneurship called Product-Market Fit. It exists when you create something that people want. This sounds easy to do, but it is not, and the vast majority of startups never do it. … I have found something similar in art, which I call Image-Market Fit. This is achieved when you create art that people want.

To find book-market fit, you need to have a good sense for the market and how your book fits in it. Your book and your target market are not fixed, either. Just as startups “pivot,” your book will change as you write it, and your market will come into focus as you discover what’s out there.

Find a model

Startups keep a close eye on direct competitors and adjacent companies they might complement in the market. To that end, one of my favorite approaches is Steve Krouse’s advice to find a model:

The core of the technique is to find a model artifact to keep an eye on while you work on your artifact, which could be a coding project, a song, a painting, an email, a social media post, an essay like this one, etc.

Star Wuerdemann applies this find-a-model concept to selecting comps for your book. Comparable titles “show where your book would be shelved in a store or who your most likely readers are” and signal “that you know something about the current marketplace and how your book fits in it.” Looking for comps means you have good reason to visit bookstores and read a lot, which I’m guessing are both things you love to do if you’ve chosen to write a book. Searching for models may double as research for your book, either for content or stylistic inspiration.

You don’t have to choose just one model/comp. It’s useful to pick and choose elements from multiple books. Per Steve:

It’s important to remember that “Plans are useless, but planning is indispensable.” In other words, you shouldn’t shouldn’t feel compelled to stick to your model so closely. Use the parts that you want, and forget about the rest.

I’m constantly keeping an eye out for models for my book and adjusting the list as I go. I have many models that match different elements of my book.

• Word by Word: The Secret Life of Dictionaries by Kory Stamper is a model of a nerdy nonfiction book that takes a technical topic and packages it as a fun and fascinating narrative. I also borrowed “The Secret Life of X” snowclone from its subtitle!
• Salt Fat Acid Heat by Samin Nosrat is a model for its doodle illustration style
• The Design of Books by Debbie Berne is a model for its physical construction (sturdy paperback, length, etc.) and illustrations
• What Is Code? by Paul Ford is a model for its writing style/voice

In addition to book models, I also look for author models. That is, programmer-writers like me who write about similar subjects, to a similar audience, or in a similar style to my writing. The hope is to draw inspiration from many authors and books to carve out my own book-market fit—a space between them on the shelf, as it were.

Find whitespace

The world is big enough that when you have an idea for a startup, someone else has probably already had that idea. Maybe many people have had that idea. Maybe some have even raised money and hired a team. Plenty of new startups enter already-competitive markets, but then again most startups fail (just as most books sell relatively few copies). When starting a company or writing a book, it helps to find some unmet demand in the market.

Part of what gave me conviction to write my book is the absence of recent books about domains. If dozens of domain books were published each year, expecting to find book-market fit as a debut author would be a tall order. There have been a handful of good books about domains over the years, and they’ve been valuable to my research, but they each occupy a niche subtopic within domains. To name a few:

• David Kesmodel’s The Domain Game (2008) covers domain investing
• Kieren McCarthy’s Sex.com (2007) covers the dramatic saga over the $12 million crown jewel of pornography domains
• Milton Mueller’s Declaring Independence in Cyberspace (2025) covers the geopolitics of internet governance

After surveying the market, I felt confident that there is considerable whitespace for a narrative nonfiction book that explores many of these subtopics across the world of domains: early internet history, economics, ethics, geopolitics, governance, etc.

Sam Arbesman told me that for his book Overcomplicated, his editor suggested positioning it as the one science/technology book his readers pick off the shelf that year. That’s not my aim, and I only know that because I’ve talked to something like a hundred people already. I’ve explained my book a hundred different ways, and each time I collect a data point about what resonates based on who I’m talking to. Sam likens this to A/B testing, which is commonplace in the startup world. When I tell family and friends—say, at a wedding—that I’m writing a book about domains, they sometimes ask (or maybe think to themselves), “…a whole book?” As a debut author, it feels unrealistic to shoot for this one-tech-book-per-year, New York Times bestseller crowd. On the other hand, when I talk to software engineers, venture capitalists, and other Internet-curious people they ask lots of questions; their eyes light up; I can see their mental wheels turning. I want to reach these nerdy nonfiction readers who pick up several technology books in a year.

While conversations that happen organically are useful, to really write a book like you’d run a startup requires systematizing these feedback loops.

Feedback loops

Startups talk about iterating in tight feedback loops. Ship new features each week, write about them in public, fix bugs, talk to users, repeat. I’ve taken pages from this startup playbook for my book by interviewing readers and working in public, namely through my email newsletter/blog (and to a lesser extent, social media).

Interview readers

Startups conduct “user interviews” to gauge how their product is resonating and what needs to change. I held user interviews weekly as a founding engineer at my last job. I thought about those interviews as searching for 10 unhappy users to gather feedback from.

When only 10 programmers had used Membrane, 10 out of 10 might be unhappy in some way. Then at 100 users, maybe 10 are still unhappy. Once we reach 1,000 programmers relying on Membrane, just 10 are unhappy. And at 10k, 100k, 1m, and beyond, merely 10 unhappy users would make Membrane a world-class product. … Having 10 unhappy users really just means we are getting consistent feedback, learning, and improving.

Nowadays I conduct reader interviews for my book, hopefully to find many happy readers when I publish. Reader interviews help me move toward book-market fit, but they also pull in early adopters who champion my work and spread the word. One interview often leads to the next, or even the next few.

I interview programmers, designers, writers, founders, venture capitalists, domain investors, domain brokers, internet historians, and really anyone who I’d like to talk to about domains. I aim to interview at least one person a week, ideally more. Many of my interviews are ostensibly for research—i.e. for me to learn something about domains—but those conversations still teach me something about the who and what—who I’m writing to and what interests them.

The work of a writer can be isolating, and although it’s not the primary purpose, reader interviews help offset that. I consider myself an ambivert, and I often dread scheduled meetings with strangers, but I always come away more energized about my book.

Email readers

Interviewing readers one on one provides focused feedback, but emailing readers all at once provides higher leverage. If my book is a startup, my email newsletters are the “beta” version of my product. I write a blog post—something akin to a rough draft of a chapter—every couple weeks and send it over the wire. Readers test the beta and reply with explicit feedback or implicit feedback (e.g. by sharing with friends or unsubscribing).

One of the very first things I did after deciding to write a book was set up an email signup form on my book website’s homepage. I had done the same thing on my personal blog well before I knew what I wanted to email—or whether I wanted to email at all. We are living in The Era of the Email Newsletter, and even if you’re worried about reader email fatigue it doesn’t hurt to collect email addresses. A direct relationship with your readers is worth having up your sleeve. There’s a difference between voluntarily subscribing (with the option to unsubscribe) to a book newsletter and being sent emails you didn’t opt into—and it’s up to you the author to be judicious and respectful of that.

One of my “whys” for publishing an email newsletter and blog comes from Henrik Karlsson’s essay, A blog post is a very long and complex search query to find fascinating people and make them route interesting stuff to your inbox. Henrik’s thesis is right there in the title: by publishing a blog post, you’re erecting a beacon to attract readers who you can learn something from. Rather than search for them, they come to you. This very essay is a beacon—you can comment or email me to say hello!

Writing emails is a form of working on your book in public. Not only do you collect feedback, but you also include your reader as a member of your team, in a sense. This reply from one of my readers nailed it:

I like feeling like I’m part of the process. It’s smart to develop the book in semi-public—I’m sure you’re going to get a ton of useful feedback along the way.

Work in public

Startups often work in public to some degree—e.g. blogging and posting on social media—to get feedback, promote their product, and attract potential hires. Many startups even “open source” their code, inviting contributions and scrutiny from the general public (to identify security vulnerabilities, for example). Many software engineers embrace this work-in-public philosophy or the related learn in public ethos that Shawn Wang helped spread. Shawn talks about leaving a trail of “learning exhaust” by writing a blog, starting a newsletter, or drawing cartoons (“people loooove cartoons”).

Whatever your thing is, make the thing you wish you had found. … Just talk to yourself from 3 months ago.

Shawn’s advice here is one way I think about who my readership is: it’s me before I started writing the book. A programmer who’s bought a handful of domains and wondered about all those different endings to the right of the dot.

I conduct some book research in public, like my wiki for top-level domains and A Brief History of Domains, which I started for my own understanding as a way to organize my historical knowledge of domains and find gaps. I decided to make that historical timeline public, and it has been my most popular domain writing to date. It also gave me signal to lean further into illustrations for my book and to find comps whose doodle style matches what I’m going for.

When I started working on my book, I was surprised to realize that it felt so similar to working at a startup. I should not have been surprised (but still was) by the other side of that coin: if you’re writing a book, you may be preparing yourself to be a startup founder or early employee.

Run your startup like you’d write a book

I’ve made the case that running a startup is good preparation for writing a book. I actually think it goes the other way, too.

It’s a startup cliché to “wear many hats.” If you’re writing a book—and especially if you are self-publishing—you wear most or all of the hats. It’s one of the things that drew me to writing a book in the first place, outside of the writing itself. Beyond learning about your subject matter and the craft of writing, you have the opportunity to learn about the nuts and bolts of typography, cover design, email, publishing, and plenty more.

One reason startups are hard, though, is that they require indefinite time commitment from the founders. You don’t start a company and tell potential customers and employees that you hope to be done with it in two years. Writing a book offers a lot of the same experience in a more timeboxed way. Plus, a book is a great excuse to meet people who work in the space you’re interested in.

I wrote this essay with authors in mind, but I’ll end with its secondary purpose: to nudge more programmers, entrepreneurs, and aspiring startup founders to write books. If that’s you, before you start that company, write that book!