Feedback Outlines

by F.

Recently I started working with an excellent editor (the human kind, not Vim). One of the things that makes her excellent is her feedback. It is, probably, the most effectively presented and actionable feedback I’ve ever gotten. On anything.

Now, this could be because of the domain (non-fiction writing) which has fairly clear criteria of quality (nowadays). And I’m not talking about that ol’ Strunk & White bullshit, either. I’m talking about the amount of wisdom in a book like Reporting Technical Information, which is truly amazing. The information on how to present information via text is out there, which may explain it entirely. Or it could be her. Or both. But I think it’s largely her.

In any event, after getting this feedback, I thought, “How am I going to remember this?” I mean, if on project #1 she says, “In the future, do X” and on project #2 she says, “In the future, do Y,” then when I do project #3, I want to be able to implement X and Y. Without some method, what would likely happen? I would implement the most recent feedback, Y, because it’s most recent and probably most salient. I might implement X, but maybe not. Or I may implement a piece of X. Some feedback is so easily learnable that this is not a problem. But what about complex feedback?

I started to collect it in an outline, using the wonderful, life changing, all-singing, all-dancing, live-and-in-person, totally-nude, longevity-enhancing, regularity-promoting OmniOutliner (which is installed on Macs at the factory) but any tool will do. The outline is simple: a major heading for each project, then two subheads under that: one for “Goodness” the other for “Missed.” Like so:

  1. Project #1: Hypoallegenic Cat Genome
    • Goodness
      1. Resulting cat has four feet
      2. Resulting cat has fur
    • Missed
      1. Resulting cat lacks eyes
      2. Resulting cat barks like a dog
  2. Project #2: Attack Hamster
    • [Etc]

I think both categories or necessary, since you want to propagate the good as well as fix the bad. After all, as you go from project to project, tuning your product to fit the needs of the customer (e.g., my editor), it’s important not to lose what’s right about the initial work.

Once the outline is in place, I take a look at it before doing each project, to remember what to do this time. As the outline grows the “Misses” should get fewer and fewer, or more and more granular, unless requirements have changed—this would probably result in more misses.

Is this a revolutionary or brilliant idea? Not even close. But it works.