Product Management: Another Look at Requirements 

What do product managers do in your organization? Probably a whole range of things, but having to choose just one most people would say “Requirements”. It is widely accepted that product requirements are the core function of product management and that Product Managers (PMs) are solely responsible for collecting, processing and communicating them, just as developers are responsible for producing the product. Is there more to it? 

Well, in actuality things are rarely that simple. Firstly the notion of what constitutes a requirement is seldom well-defined and understood, commonly leading to confusion with regard to ownership, to inefficiency and to friction. Some types of requirements often get informally defined by non-product managers: top-management, marketing, development and others. Is this a bad thing? As I’ll try to show not all requirements have to be “owned” by product managers, but it’s crucially important to be explicit and methodical about those.
 
Other types of requirements “fall between the cracks” and never get articulated, leading to end products that are less competitive. The working assumption that PMs will just do whatever it takes to generate requirements often fails. A common complaint heard at project debriefings is that requirement specs were missing, partial or late. On the other hand, having a holistic (and realistic) approach to requirements can greatly enhance the chance of generating successful projects and winning products. 

What is a Requirement? / The Rational Unified Process (RUP)

The Rational Unified Process (RUP) proposes a tiered requirement model, the so-called Requirements Pyramid. It defines three types of requirements: 




Requirement: Needs – Needs talk of users (AKA stakeholders), their pains and their wishes. Here are a few examples: 
System administrators often have to connect to the system while away from their desk. They require a secure and easy way to use the system from any computer station in the organization. 
37% of the target market use iPhone as their primary mobile phone, therefore the application must be iPhone-compatible. 
Our study shows that users rarely visit any page that is more than 2 mouse-clicks away from the main site page. Therefore the “Purchase” page must be within 2 mouse clicks from the main pages. 

Such statements while fairly high-level and not directly actionable by dev and test, are a good way to explain what issues the product needs to address in order to be considered valuable by users. This is known as The Problem Space. Often those people who are in frequent touch with customers – marketing, sales, business-development and CxO, are in the best position to collect and define Needs, and they fit nicely in a Marketing Requirements Document (MRD) for example. Alas, most projects don’t bother with formally specifying needs and instead skip directly to the next tier. 

Requirement: Features – features typically define discreet units of functionality: 

Secure remote web logon – administrators will be able to access the system using a web browser. All communication will be carried out over SSL. All transactions will be authenticated. The system log will record remote transactions. 

iPhone compatibility - the application will run on the iPhone platform. The following parts of the UI will be adapted to iPhone-style gesture input... The following product features will not be available on iPhone in this version… 

As you see features are ideally derived from needs. It’s not always a one-to-one relationship, though. A single need can turn into multiple features and a single feature may address multiple needs (although this is rare). Features already define the Solution-Space, but they are often too high-level to serve as development or test guidelines. They fit well in a Product Requirements Document (PRD) or similar doc and are a good way to explain the scope of the product and serve as basis for internal and external discussion. Contrary to Needs which are rarely defined, features are often over-defined, with many people (including customers) trying to weigh-in and influence what goes into them. 

Detailed Requirements – these are the product specs that most people associate with PM work. They define product behavior at low-level. Examples below: 

Secure Remote web logon #1 – Supported browsers: IE7, IE8, and Mozzila 3.x 
Secure Remote web logon #2 – Connection will be carried over SSL3.0 or TLS1.0 with server certificates. 
Secure Remote web logon #3 – The user logon sequence is: 1) User open the Secure Logon page 2) The user enters username and password 3) … 

Detailed requirements are often housed in System Requirements Specs (SRS), use-cases, GUI specs or any other format. Still, not everything requires this level of specification nor is viable to define in fine detail every aspect of a rich product. In some cases feature-level definition is sufficient. In cases where the details are mostly to do with technicalities detailed requirements can be explicitly delegated to R&D. 

In conclusion, I like the pyramid model for three main reasons. Firstly it helps ensure that everything we do traces-back to some concrete business need of real stakeholders. This is a good way to stay market-focused. Second the pyramid shape, narrow at the top and wide at the bottom, serves to illustrate an important point that people who are not a part of dev-test-PM often miss. A small change at the top of the pyramid means substantial work in the middle and lots of work at the bottom. Adding a new need may take as little as a few hours, but may cause weeks of additional work for PMs and months of dev/test time, which is why it’s so crucial to nail the needs. Lastly it shows the true nature of requirements work – not just the sole domain of PMs, but rather a cross-company process which requires participation of all disciplines. 


Click here to read about 3Sixty's Product Marketing services

I am sure that at one time or another you have heard about the 4 P’s of marketing. The 4 P’s reflect company actions that influence the consumer decision to purchase goods or services. The 4 P’s or The Marketing Mix refer to: Product, Price, Place and Promotion.

Product:   What is your product offering, how does it relate to the needs of your potential customer?	Elements to be addressed include: Functionality, quality, appearance, packaging, brand, service, support and warranties.
Price: What is the price of your product or service, is it affordable, how will customers value your prices?	Elements to be addressed include: List price, discounts, financing, leasing, allowances etc.
Placement:   How does your product reach the customer, where is it distributed and how is it delivered?	Elements to be addressed include: Locations, logistics, channel members, channel motivation, partners, market coverage, service levels & internet.
Promotion: How do people know what you’re selling? How do you build market awareness?	Elements to be addressed include: Advertising, sales promotion, public relations, messaging, direct sales, branding, Marcom, media, & budget.