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
Leon@kotovich.net

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
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 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
problem?
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 1Are aligned
with
Solution 2
Solution 3
P
R
D
#
1
Platform
Services
P
R
D
#
2
P
R
D
#
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 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:
notify them).

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:
notify them).

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
Features
c
Functions
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
Functions
Products
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
Functions
Products
c
Components
c
Features

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
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
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
FeaturesComponent
• 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
FeaturesComponent
• 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
How PDS is used
Product User Guide
• Audience: actual users of the product
• Descriptions of functionality
• Common business scenarios
• Instructions
How PDS is used

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
How PDS is used
Product Deployment Guide
• Audience: adoption consultants
• Summarizes new features and functionality
• Content spec. changes & migration options
• Initial setup requirements
How PDS is used
Product Marketing Collateral
• Descriptions of functionality
• Competitive analysis
How PDS is used

Fundamentals of Product Definition Process - MRD PRD FRD

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Fundamentals of Product Definition Process - MRD PRD FRD

Ähnlich wie Fundamentals of Product Definition Process - MRD PRD FRD (20)

Fundamentals of Product Definition Process - MRD PRD FRD