Title: Editorial: Product Definition

The key to successful product definition is dissatisfied customers, for customers only complain about problems they really care about.

In defining the features of my current project I have tried to reduce them to a minimally useful set, leaving just enough substance to get the customer interested. The first version may make no sales, but if it draws some complaints then I will be happy, as every complaint is an opportunity to satisfy a need.

The product requirements document, PRD, is central to the product definition activity. It lists the features that the product is to provide. It specifically does not prescribe any particular design or implementation strategy.

There are three sections to a PRD: the general goals of the project, the itemized feature list, and a detailed feature list offering evidence of the feature's worthiness.

The goals should be broad, and most features should fit within the category of a goal. Perhaps the goals of a PRD for a 2.0 product would be:

The feature list briefly describes each feature and orders them by priority. Each list item includes a snappy name for easy reference, a brief descriptive paragraph, and a list of any dependent features. Priority is denoted by order. Each feature on the list is deemed more important than the subsequent features on the list. This prioritization exercise can involve much soul searching, but pays off greatly towards the end of the project.

The detailed feature list includes a more expansive entry for each feature providing a complete description of the feature, and as much marketplace evidence as could be collected. The marketplace validates the worth of the feature, and so influences its priority. Evidence can be drawn from interviews with customers and salespeople, support and professional services staff, and also from industry research reports, competitor information, and plain gut feeling.

The framework provided by the PRD is designed to guide the project definition process to ensure that the most return will be realized from the resources being put into the project. Thinking of features is easy. Validating them against a marketplace is hard work.

A product manager usually owns the PRD, and collects and validates contributions from many sources. Engineering is consulted often to ensure that each feature definition is well understood.

Interpreting customer input can be hard work, as customers are mostly interested in what they want right now and not what they would like to have a year from now.

It is important to discover what they need, not what they say they want. A common mistake is to present customers with a questionnaire based on everything that the engineering team can think of adding to the product. Question: 'Dolby and Tweeters?' Answer: 'Yes please, we want that.' The thought has now been seeded in their minds. When subsequently asked what they need from the product they helpfully suggest 'Dolby and Tweeters?'^[1]

It can be worse when the idea comes from the data sheet of a competing product. A product I worked on many years ago had some features in this category. 'Check box' features they were called. Two years after we implemented a particular feature a journalist tried it out for a product review article. He complained that he couldn't get it working. 'Simple-minded journo' we muttered to ourselves as we investigated the problem. It didn't work. We started hunting down the bugs. And, looking back through the source code repository, we found they'd always been there. The feature had never worked. Customers wanted it, but didn't need it, so never used it.

Writing a PRD for a 1.0 product is even harder than writing one for an established product. There are no existing customers to consult. Prospective customers have to be identified, which involves both a marketing and sales activity.

Part of the 1.0 product release has to include feedback mechanisms for the customer to talk back to the development team. Communication channels are established from the customer to product management and engineering via sales, support and professional services. Companies are now also creating communities of customers around their products, typically through a mailing list or newsgroup. The product development team usually lurks in these places picking up on complaints and comments, and sometimes dipping in to get more detail, or to explain a solution to a newly discovered problem.

The PRD has to be signed off by all senior management. The PRD serves as a contract between product management and engineering. Product management promises not to fiddle with the feature set, and engineering promises to implement no more and no less.

The danger of not signing off on the PRD is feature creep, or feature leak. People slowly add new features to the list to be implemented, or people decide that they don't believe in a feature and put it off until it's never implemented. Often this is not malicious intent. Poor documentation, faulty memories, long project cycles, and staff turnover all contribute.

The engineering and quality assurance schedules are drawn up from the PRD. Senior management is presented with the PRD and the schedules for a project review cycle. Decisions are made about the relative importance of quality, schedule, and features within the project, and how that project inter-relates with other projects, and the needs of the business as a whole. These three aspects; quality, schedule, and features, are each be traded off against the other to find a satisfactory balance.

Often time-to-market pressures will dictate that the schedule must be shortened. Management must decide if the priority for the release is quality or features. Often the feature set will be reduced to bring the schedule back to the desired release date. A line is drawn between those features deemed 'in' and those 'out'. The feature prioritization process ensures that all the 'in' features are more important than the 'out' features.

It is important that the 'out' features remain in the document. It must be clear to readers of the PRD that a favorite feature has not been forgotten, just deferred. And, as the project progresses scheduling feedback might allow 'out' features to be moved 'in', and more commonly 'in' features to be moved 'out'.

Of course requirements do change during a project, and a strong PRD actually facilitates the renegotiation process, as much of the determination of relative feature value has already been done. A scaled down project review cycle is undertaken to ensure that the schedules are features are properly balanced.

My solution to the 1.0 product definition problem is to just get something out there and create a community around it. The community will serve as a marketplace from which I can learn the value of the features I am and could be offering.

Thaddaeus Frogley has been programming professionally for eight years, seven of which in the games industry, five of which in (mostly) C++. He has written articles published online, here in Overload, and over-there in CVu. Despite being dyslexic, all this apparently qualifies him to be on the editorial team, a responsibility he has wisely taken on at the same time as becoming a father. His website of fun programming stuff is here: http://thad.notagoth.org/