Fundamentals of Product Definition Process - MRD PRD FRD

© agileSEQUENT, Inc – All rights reserved

Fundamentals of Software Product Definition Process

MRD > PRD > FRD

Leon Kotovich CEO

www.agilesequent.com

[email protected]


Part 1 - Agenda

  Why software business is a good business – but not without risks   Goals of this presentation: how to define a software product   What makes software companies successful   Three steps of product management process   Closer look at the product management process   How to create building blocks of a product   Additional areas of focus

  Importance of Product Platform as a deliberate concept

NOTE: Part 2 will be a working exercise, where a simple requirement will be traced through the product management process, creating a building blocks for a product datasheet

Topics


Part 2 - Agenda

  Select a simple requirement (is it really simple?)   Revise it and detect components, features, and functions   Create a consolidated view of the initial product definition   Create a product datasheet!

Topics


Why software business is a good business – but not without risks   Relentless pressure in all industries / segments to automate, improve

information flow, reduce cycle time …   Relentless search for competitive differentiation   Hence - industry-specific software solutions are easier to sell   Prohibitively high costs of conversion once adopted   “Golden goose”: software which enables and embeds a critical process   Much easier to build a loyal customer base (unhappy customers can be

loyal too)   Financial gains can be significant   The marginal cost of next multi-million dollar sale is largely equal to the

cost of pressing a new CD (or sending a new executable file)   Risks - the competition is fierce, unforgiving, and ruthless

Why “everyone” wants to be a software company


That’s why your software product …

  Has to be clearly better in every way than your competition   Must solve the business problem with sustainable economic benefits   Can easily show cost / benefit even to those that will not use it   Should engage the end user in a delightful manner   Should also evoke an emotional response …

  Ease of use: is it still only a promise?   User interface: is it ‘blah’ or ‘brilliant’?

Is your product management process and organization behind it great enough to be the driver of great

products?

Are you great enough to create great products?


Goals

  Introduce product management process   Selected areas of focus

- Define products - Identify building blocks - Create product definition collateral - Establish “binary clarity” and traceability

  Learn how to identify and structure building blocks   Trace a simple requirement through the process   Practice … practice … and then practice again

Goals of this presentation: how to define a software product


Unconditional adherence to fundamentals of product management process

What makes software companies successful?

  Another term for product management: “relentless championship”   Overarching attribute of successful software companies: “binary

clarity” in all activities (not an exhaustive list):

What’s the problem?

•  Market & segments •  Known problems •  Cost of problems •  Range of solutions •  Cost of solutions

What’s the solution?

•  Better process •  Better information •  More actions •  New needs •  Lower costs

How does it look?

•  Product portfolio •  Product platform •  Components •  Features / functions •  Collateral

Product Management & Definition Process Low

complexity High

complexity

How do we do it?

•  Use cases •  Release plans •  Release schedules •  Integrated Product Development Plan

Medium complexity

The most difficult and critical step: converting solutions into products


Fundamentals of product management: MRD, PRD and FRD


•  Market & segments •  Known problems •  Cost of problems •  Range of solutions •  Cost of solutions

What’s the solution?

•  Better process •  Better information •  More actions •  New needs •  Lower costs

How does it look?

•  Product portfolio •  Product platform •  Components •  Features / functions •  Collateral

Product Management & Definition Process Low

complexity High

complexity

How do we do?

•  Use cases •  Functional flows •  UI elements •  Integrated Product Development Plan

Medium complexity

MRD: Marketing Requirements Definition

PRD: Product Requirements Definition

FRD: Functional Requirements Definition

Three steps of product management process: MRD, PRD, and FRD

Focus of this presentation


Overview of MRD, PRD, and FRD steps, activities, and building blocks


What’s the solution? How does it look? How do we do it?

MRD: Marketing Requirements Definition

PRD: Product Requirements Definition

FRD: Functional Requirements Definition

Closer look at the product management process

Problems Solution 1 Are aligned with

Solution 2

Solution 3

P RD #1

Platform Services

P RD #2

P RD #3

Are translated

into

  Must be unique   Business rules known   Needs/competition known   Critical voids known

  Solutions must have “borders”   Relationships identified   Vision statements declared   Compelling features identified

  Solutions -> Products   Products -> Components   Components -> Features   Features -> functions

  Functions -> Use cases   Technical architecture

Are decomposed

into

Are decomposed

into

Technical Architecture

•  Components •  Features •  Functions •  Use Cases

Activities

Building Blocks

Steps

Enabled by …


Follow MRD, PRD, FRD process … and product building blocks will emerge

How to create building blocks of a product

Step MRD

Activity •  Define solution vision statements •  Translate: solution visions into products •  Identify: business rules

PRD •  Create: relationship diagrams from business rules •  Translate: products into components •  Translate: components into features •  Translate: features into functions

FRD •  Translate: functions into use cases •  Translate: use cases into detailed elements (workflow, error processing, dialog steps, parameters, expected results, user experience, other functions/services invoked, etc.)

Building blocks •  Product portfolio •  Product Platform •  Business rules

•  Relationship diagrams •  Component models •  Feature list •  Functional inventory

•  Use cases •  Use Case packages •  Or – User Stories


Introducing another areas of focus (but beyond the scope of this presentation)

Additional areas of focus

  Product Platform as a deliberate concept


Product Platform enables early recognition of shared capabilities common to all products

Product Platform as a deliberate concept

  Managing shared, internal, or common services as a Product Platform creates multiple benefits:

Product Platform

  Registration   Search capabilities   Content management   Dashboard   Scalability / Performance

  Allows to market capabilities not easily marketed (performance, content management)

  Creates additional points of differentiation   Creates “yet another” slide why “we are

better”   Ensures discipline in delivering shared

capabilities across multiple products   Accelerates product development, “done

once, available to all”

Product #1

Product #2

Product #3

  Platform is a PRODUCT!


Part 2 – Are you ready to define a product?

  Select a simple requirement (is it really simple?)   Revise it and detect components, features, and functions   Create a consolidated view of the initial product definition


Let’s review a (seemingly?) simple requirement: Administrator registers a new company as a customer

Selected example

”Administrator can establish a company hierarchy by creating X sub-levels under the top level unit. If a sub-level unit within the company holds a unique contract, the administrator has to locate the unit and update it with contract-specific information. (Email notification will be sent to sub-level owner to notify them).

Goals of this exercise:   Re-write the requirement to pass “binary clarity” tests   Detect and identify components   For each component, identify features   For each feature, identify functions   For each function, assign a use case for further decomposition   Detect the need for business relationship diagrams

Assumptions:   Product vision statement already exists


Requirement statements must be “binary”: one noun, one verb, one or more conditions (ideally – one)

Selected example

Revised language:

  Company hierarchy will support unlimited number of levels (can be done by the Administrator only).

  Administrator can define a contract at any level within the company hierarchy. For relationship between contracts and company hierarchy, see Diagram 1.1.

•  Detected component: Manage Companies •  Also detected a business rule (only Administrator can create companies and hierarchies) •  Detected function: Specify # of organizational levels •  Detected component: Manage Contracts •  Identified a diagram which needs to explain how contracts relate to organizational hierarchy

Notes:



Components, features, and functions must be easily detected from requirements statements

Components, features, functions – should be detectable

Revised language (continued):

  Administrator can display all contracts that may exist at any level within a company

  Administrator can search through all contracts

  Owner of organizational unit can subscribe to and receive events when contracts are updated

•  Detected feature in Manage Contracts Component: Display Contracts •  Detected feature in Manage Contracts Component: Search Contracts •  Identified new component: Manage Notifications •  Identified new implications: how to notify (direct e-Mail, Dashboard, or both)

Notes:



All building blocks (components, features, and functions) have unique attributes … beginning w/components

Defining building blocks

  Components own business rules and business relationships

  For example: Manage Companies, Manage Users, Manage Contracts, Manage Viewing Rights

  Components are derived from business requirements

Product •  Consists of Components

c Components

•  Consist of Features

c Features

•  Consist of Functions

Functions •  Consist of Use Cases


Features represent aggregated functionality required to manage related activities


  Feature decomposition is frequently based on “life cycle” technique

  “Create new, add, enhance, maintain, reduce in scope, retire, archive, and delete”

  For example: the first feature in Manage Companies component is Create Company

  The second feature is Update Company   The third feature is Deactivate Company   … and so on …

Components •  Consist of Features

Features •  Consist of Functions

c Functions

•  Consist of Use Cases

Products •  Consist of Components

c


Functions represent very granular tasks required to enable each feature


  Functional decomposition is frequently based on “domain identification” technique

  “What are the elements which make the company (domain)?”

  Elements: name, legal address, number of org. levels, names of each business unit, distribution locations, etc.

  Functions are tasks required to obtain/define each elements. For example:

  Create Legal Name, Create Address, Specify Number of Levels, Assign Business Unit Names, Specify Distribution Locations

Features •  Consist of Functions



c Components


c


Use Cases describe a sequence of steps (combined functionality) to accomplish a chosen task


  Uses Cases can be presented in three major forms: - Narrative - Scenario - Conversation

  Use Cases describe “what happens” from an “external perspective”

  Use Cases can be organized based on relevance, frequency of use, value to the users

  Impact of adding/removing features or functions can be analyzed

  Uses Cases do NOT describe: - User interfaces - Performance goals / application architecture - Non-functional requirements



c Components


c Features

•  Consist of Functions


Use Cases can be presented in three major forms

Use Case forms

•  Free form paragraph(s) •  Describes the intent of actor performing Use Case •  Describes high level actions of the user during the Use Case •  Refer to key concepts (business rules, relationship diagrams) from the MRD, PRD, and FRD documents

Narrative •  Description of a specific path (driven by intent) – written from an actor’s point of view •  List of steps required to accomplish Use Case •  Each step – simple declarative statement •  Describes intent, actions, expected parameters, expected results, responsibilities of platform and other products’ components

Scenario •  Description which emphasizes interactions between an actor and the system •  Shows optional and repeated actions •  Each action can be decomposed into sub-actions •  Describes intent, actions, expected parameters, expected results, responsibilities of platform and other products’ components

Conversation

Required Elements   Actors   Intent (could be multiple)

Supporting Elements   Key concepts and relationships   Known constraints


Each Use Cases can further described in four levels of detail

Use Case forms

•  Description of a specific path (driven by intent) – written from an actor’s point of view •  List of steps required to accomplish Use Case •  Each step – simple declarative statement •  Describes intent, actions, expected parameters, expected results, responsibilities of platform and other products’ components

Scenario   Summary (required) - General descriptions and overviews of system functionality and/or business processes

  Core (required) - Descriptions of users and tasks, how they interact with the system - Descriptions of specific workflows

  Supporting - Descriptions of lower-level activities used to complete parts of the Use Case

  Internal - Descriptions of behaviors and interactions between internal system components


Let’s summarize all the building blocks …. Building initial product definition

  The Registration process (new company / customer setup) might be better managed as a part of Product Platform – shared capability

  Two major components have been identified:   Manage Companies, Manage Contracts

  Manage Companies component has these features:   Create New Company, Update Company, Deactivate Company,

Delete Company   Create New Company feature has these functions:

  Specify Name, Specify # of Org Levels   Manage Contracts component has these features:

  Define Licensing Models, Select Licensing Model


… and build initial Registration product definition Building initial product definition

Product Platform

  Registration

Registration

Manage Companies

Manage Contracts

Manage Notifications

Manage Users

Authenticate Users Log Activity

Component Model

Manage Companies

Features Component

•  Create new Company

•  Update Company

•  Deactivate Company •  Delete Company

Functions

•  Specify name •  Specify # of org. levels •  Display all “children” units •  Specify names for all units •  Specify legal addresses •  Specify contact information •  Define contracts (passed to Manage Contracts)

•  Update addresses •  Update contacts

Manage Contracts

•  Define licensing models

•  Define contracts

•  Specify licensing attributes •  Name / save licensing model

•  Select licensing model •  Modify licensing attributes


Once functional decomposition is complete, dependency assessments (between functions) must be performed

Functional dependency assessment

1.  Dependencies between different components in the same product 2.  Dependencies between different components in different products 3.  Dependencies between product components and platform

components

1 2 3


Product Description Datasheet is the most critical document created during early product definition activities

Critical Collateral created

Manage Companies

Features Component

•  Create new Company

•  Update Company

•  Deactivate Company •  Delete Company

Functions

•  Specify name •  Specify # of org. levels •  Display all “children” units •  Specify names for all units •  Specify legal addresses •  Specify contact information •  Define contracts (passed to Manage Contracts)

•  Update addresses •  Update contacts

Company Registration – Release 1.0

•  NEW: Support for licensing models •  NEW: Support for distribution locations •  NEW: Support for contracts at any organizational level

Notes

  Component / Feature / Function decomposition process creates foundation for the Product Description Datasheet (PDS)

  PDS is used to create other product launch collateral:   Competitive analysis briefs   User Guide changes   Training Guides   Deployment Guide


Product Definition Datasheet is used to create other, critical product collateral …

Additional collateral created during product management

PDS Product

Definition Datasheet

Product Release Notes •  Audience: internal only •  Built incrementally during development •  Functionality delivered and NOT delivered •  Known workarounds

How PDS is used •  Functional reference

Product Technical Guide •  Audience: product architects & customer support •  Overview of product architecture •  Internal workflows •  Functional dependencies


Product User Guide •  Audience: actual users of the product •  Descriptions of functionality •  Common business scenarios •  Instructions



Product Definition Datasheet is used to create other, critical product collateral …

Additional collateral created during product management

PDS Product

Definition Datasheet

Product Trainer Notes •  Audience: trainers •  Summarizes new features & demonstrations •  Functionality delivered and NOT delivered •  Instructions how to explain new features


Product Deployment Guide •  Audience: adoption consultants •  Summarizes new features and functionality •  Content spec. changes & migration options •  Initial setup requirements


Product Marketing Collateral •  Descriptions of functionality •  Competitive analysis


Documents

Fundamentals of Product Definition Process - MRD PRD FRD