Search This Blog

Sunday, January 29, 2012

Writing Good PRD

Over 940,000 results when I last Googled ‘how to write a good PRD’. More than enough documents (docs, PDF, PPTs) and templates (doc & excel) that will guide you through various sections (& topics) that constitutes a good PRD. While nothing to argue against or for these ideas as they come from rich and/ or wise experience, however I suggest that a Product Manager must consider opinion of the target audience prior to freezing in on PRD structure.  I certainly believe that talking to engineering helps me in writing a good PRD, and in all my jobs, current and previous I believed in tweaking, molding and bending of requirement document to ensure engineering understands it as it is supposed to be understood by them. All this ensuring that the gist and specifics are not lost in being the YES MAN for engineering.

Well great, good to know about my approach, but then what is my learning out of so much talk. Am I goanna present one more template or document?  Will that make sense, me writing one more option for good PRD? I don’t think so. People like google not because it provides large number of search results in hardly any time, but they link Google (or for that matter any search engine) for its accuracy and prioritization of results as per user preferences. So let me tell you my idea of good PRD, its ABCDEF. Oh! Well I am not joking, a good PRD must satisfy the condition of ABCDEF, and what is it?

Accurate Brief Clear Definition for Engineering on Features

Its simple, put down the requirement that is Accurate (pin point what exactly is required), Brief (only required words, don't show your writing skills here), Clear (no ambiguities, no assumptions) - satisfying your target audience, that is engineering.

Gotcha!! But is this all that is expected by engineering? Well there is little more than ABCDEF that a good engineering team seeks for and it is 4Ps, PPPP. Ah! Not as you understood it, let me put it straight.

Purpose [of release, product – the ultimate goal]
Plan [how you plan to take release to customer]
Priority [what comes first, next, next & so on]
People [team that works on the release]

Purpose could be aligned to over all goal, vision, need etc.
Plan speaks about process of taking the release to customer (steps involved, beta, dates, documents etc)
Priority, set priority for release content, teams and events.
People, this includes details of owners, team & responsibilities

Simple isn’t it. Believe me, if your document covers ABCDEF and PPPP as suggested, you have done a good job. Tweak rest as your target audience prefers it, ensuring gist and specifics are covered as they should be.

Anything else that will help in writing good PRD? - well, will surely share as I learn.

No comments:

Post a Comment