Consider the bug report.

It’s a little talked-about, little-loved part of working at a startup.

Every application has bugs.  These a complex systems with thousands or even millions of lines of code.

But unless your developers are using the application every minute, they’re unlikely to find all the bugs themselves, no matter how much your QA team tests.

And so startups rely on bug reports, usually from end-users.

The problem is that most bug reports are crap.  “Feature X didn’t work.”  This drives developers up the wall, because they need to spend more time trying to hunt down the problem and reproduce it than it will take to fix it.

I’ve dedicated a surprising portion of my life to writing good bug reports.  A good bug report does the following:

1) Tells the story of what led to the bug.

2) Describes, step-by-step, what happened.

3) Includes a careful exploration of the problem

(For example, I wrote on bug report today on a dialogue box that accepted two pieces of input.  I tested all three error cases (A missing, B missing, both A and B missing) and wrote about what I found.)

4) Explains the consequences of the problem and why it matters

5) Offers suggestions, but with the understanding that the person responsible knows more

You know what?  Those aren’t just good guidelines for a software bug, they’re good guidelines for any communication you have at your startup.

After all, what are startups but attempts to fix the bugs we find in the real world!