Last week, I talked a little about how your book is like a tech start-up, complete with “beta-testers” for gathering “user-requirements.” This week, we look at what kind of “beta-feedback” is useful, and follow through on the “tech start-up” life-cycle metaphor.
What Kind of Feedback Makes Your Book Better?
In a tech start-up, there are some basic questions one asks of beta-testers to get a sense for how “user friendly” their experience of the new website/app/software really is. These questions include things like:
- Do you answer your user’s questions?
- Is your navigation clear and simple?
- Do you provide anchor text?
- Does your design guide the eye?
- Do you start link names with important keywords?
Similarly, a writer needs honest, detailed feedback about these writing issues:
- character development
- point of view
- clarity in specific lines or passages of the prose
Since so much of finding an audience and selling a book is about how a book is positioned in the marketplace, it’s also important to get feedback about how your book compares to other books in its genre, and whether the way it’s presented (for example, the book’s cover and title) makes sense to a reader. A writer should get feedback on his or her synopsis too.
Is One of These Things Really Unlike the Other?
So take a look back at the user experience questions from a typical tech start-up, and compare them to the common elements of writing for which a writer needs feedback.
- Do you answer your user’s [reader’s] questions? This is a plot question. What questions does the story raise in your reader’s mind? Are those questions adequately resolved by the plot’s end?
- Is your navigation clear and simple? In web and software design, this applies to finding one’s way around different parts of the application. But turning pages is pretty clear and simple, isn’t it? How does this apply to writing? It could be things like “stage-blocking” (how your character’s move around and are positioned in the setting of the scene), or providing an adequate sense of time and place to your reader, to ground them in your setting early on. What “tools” are you giving your reader to help them “navigate” through the complex and abstract space and time of your writing? Are they clear and simple?
- Do you provide anchor text? In tech-design, this means making it clear to your visitor where links are headed by discussing the target site before you ask them to “click here.” This is a question of building trust and authority for you as a writer in your reader’s mind. Is your writing clear and concise? Does every word build on and lead toward the resolution of your story premise? Are you answering your reader’s questions more or less as they arise, or providing suspense in a sufficiently trustworthy way that they’re willing to hang on until the question is answered? Are your characters sympathetic?
As you can see, with a little imagination, it isn’t hard to turn “book writing” into “software for a reader’s brain,” and carefully craft a simple list of questions for your beta-readers that can provide you with complex and constructive feedback for improving your book and understanding its place in your market. (You can find a complete 57-point tech start-up usability checklist here.)
How Else Is Your Book Like A Start-Up?
To answer this question, consider again the software development life-cycle:
Thus far, we’ve looked at how beta-readers qualify as “analyzing user requirements.”
Is it such a far stretch to see how “design the program” qualifies as “planning your rewrite”? Not every beta-reader is going to offer the same feedback, and not every morsel of feedback is going to agree with every other morsel. Analyzing the feedback and selecting what you will use and what you can safely disregard is part of planning your rewrite. One has to balance one’s “user requirements” against one’s vision of the work under consideration. With website design, it may not matter that one user wants “cornflower blue” as the dominant color scheme, and it may not matter that one reader wants you to dwell more on the reactions of a walk-on character to the main story action. But if all your users agree that the navigation is confusing, and all your readers agree that the main story action in scene nine is godawful unclear? It’s worth considering tweaking the navigation/action in scene nine, isn’t it?
So what’s “code the program”? The rewrite, silly. And “document and test the system”? I call this “version control,” keeping a record of the original draft, a version of the draft with changes made, and a clean version of the second draft, without any of the original unchanged text. The version with changes made and highlighted (using “Track Changes” in MS Word, if that’s your “software development kit”) is then shared back to the beta-readers: “Is this better?”
At the point of “operate and maintain system” is where things get dice-y. By now, you have two rounds of feedback from your users/beta-readers. Is that enough? Is your book ready for prime-time and real customers?
This is where you have to be brutally honest with yourself. As the saying goes, “Time is money.” The more time you invest in your book without selling it, the longer you go without making money, and the greater the risk of the project’s financial failure before it gets out of beta.
Most start-ups have a certain limited amount of “start-up capital.” This is money from angel investors, crowd-funding, your own nest-egg, that surprise inheritance from your great-aunt Sally, or the “disposable income” from your day-job, and the number of sleepless nights you can keep investing in your book. Once the time and/or the start-up capital are depleted, the start-up either has to pull the trigger and hope for the best, or seek out additional rounds of start-up capitalization, or jump ship on the project. In project management parlance, we call this a “kill-point”: should we just kill the project now and cut losses?
Digital Publishing and the Authorpreneur
In the old days of print publishing, once a book was published, that was “the version of record.” If it was widely successful in its first few print runs, the publisher might agree to an “unabridged version” that highlighted everything the author’s editor originally cut, and in non-fiction publishing, a publisher might get extended life out of “revised editions” of a successful title. But these were exceptions, not the rule.
Today’s digital publishing environment changes the game somewhat. Author’s can adopt tech start-up philosophies such as “perfect is the enemy of done,” “good is good enough,” and “minimally viable product” in order to get the book from beta to market while start-up capital is still available, and then use the moderate-to-good success of the book to woo additional capital investment for “version two,” the revised edition of a book. This is as simple as going “back to the drawing board” with additional rounds of beta-readings and real customer feedback, doing additional rewrites, and then uploading the revised files to your publishing platform of choice (Kindle Direct, Smashwords, etc.).
And every publisher should understand the value of their backlist: a revised edition is a perfect opportunity to relaunch a book with flagging sales and reinvigorate that revenue portfolio.
So you have to ask yourself after each rewrite: “Is it good enough? Am I done? Is this ready enough for the market that I can reasonably expect to earn back some of my investment long enough to make it better, and better again?”
“Or am I going to keep slaving away in the basement of my own obscurity?”