I’m at Agile2005 this week. I always expect to meet interesting people at this conference, and I haven’t been disappointed.
Of course, I introduced myself and thanked him for his helpful comments.
But when I thanked him, he said he was a afraid we’d be insulted because he pointed out broken sentences and areas to improve. Au contraire. We were very grateful both for the content of his comments and his time and attention.
Any time some one spends that much time helping improve a product, it’s a gift.
And the way feedback is delivered makes the difference between whether it’s received as gift or a slap.
Here’s how our reviewer structured his feedback:
1. Comments about what he liked about the ms.
2. Global comments.
3. Specific detailed comments about areas to improve and areas where he didn’t understand what we were getting at.
4. A wrap up of what he liked about the ms.
This is an effective structure for feedback on a product. (But as you know from earlier posts, not an effective way to give interpersonal feedback — the icky tasting praise sandwich.)
When a reviewer starts with a long list of what’s wrong, the product author (whether it’s prose, code, design, whatever) will probably never hear the positive comments. And it’s useful to know what is working–the parts to keep as they are.