Of Blogs and BRDs

So…2 months into my professional blogging experiment and I have some observations.

1. 1. Posting frequency is not where I’d like it to be. This is not for lack of content, as I’ve got 5-6 articles in various stages of completion. It’s more a factor of setting aside writing time, and editing these articles into consumable content.

2. Level of depth varies. I prefer to read blog posts with links to other content, rather than pure opinion pieces. But I also know these can look like research pieces if there isn’t enough analysis of the content. This is more a case of finding the right voice and balance for content.

3. The biggest shift here is moving from content acquisition to content dissemination. I can spend hours on Google Reader, and am great at forwarding articles of interest to others on my team. But taking the time to synthesize this content and draw conclusions takes time, and more brain cells.

This is the same challenge I face whenever writing or reviewing Business Requirements Docs. The research and surveying part of BRDs is my favorite part. I enjoy seeing what’s out there, finding new content, and measuring against current products and investments. But once I’ve accumulated all of this content, how do I put it all into a nice tidy package to hand over to development so they will know what to build? How do you prioritize the must-haves vs the nice to haves? How do I convey the excitement I have around the product or the process to development, and (hopefully) inspire them to go beyond my requirements to build a great product? How do I get them to read anything beyond the requirements list? I think I need a cup of coffee.

Writing a BRD is an art, not a science. Every company has a different format and requires different content. Some BRDs are purely requirements lists, with details presented in nice easy subbullets. This is great if you want a check list to ensure development knows WHAT to build, and an artifact for accountability. But a good BRD needs to also include the WHY. (Note: that’s Why, not How). Why are these features important? Why are they prioritized in this way? Why do they need to be built now vs in 3 years? The more context that is provided for the development audience, the more likely they are to agree with your scope and priorities.

Tying this back to the blog experiment, I’m going to continue to focus on the interpretation of content, vs just sharing links. (If you want links, follow me on Twitter). I think synthesizing information, and framing an argument is what makes blogs (and BRDs) valuable. This will require some extra dedication of brain cells. So, if you need me, I’ll be at Peet’s, working on shaping up some of these works in progress.