More Related Content
Similar to Fundamentals of Product Definition Process - MRD PRD FRD
Similar to Fundamentals of Product Definition Process - MRD PRD FRD (20)
Fundamentals of Product Definition Process - MRD PRD FRD
- 1. © agileSEQUENT, Inc – All rights reserved
Fundamentals of Software Product
Definition Process
MRD > PRD > FRD
Leon Kotovich
CEO
www.agilesequent.com
Leon@kotovich.net
- 2. © agileSEQUENT, Inc – All rights reserved
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
- 3. © agileSEQUENT, Inc – All rights reserved
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
- 4. © agileSEQUENT, Inc – All rights reserved
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
- 5. © agileSEQUENT, Inc – All rights reserved
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?
- 6. © agileSEQUENT, Inc – All rights reserved
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
- 7. © agileSEQUENT, Inc – All rights reserved
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
- 8. © agileSEQUENT, Inc – All rights reserved
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 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
- 9. © agileSEQUENT, Inc – All rights reserved
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 …
- 10. © agileSEQUENT, Inc – All rights reserved
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
- 11. © agileSEQUENT, Inc – All rights reserved
Introducing another areas of focus (but beyond the scope of
this presentation)
Additional areas of focus
Product Platform as a deliberate concept
- 12. © agileSEQUENT, Inc – All rights reserved
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!
- 13. © agileSEQUENT, Inc – All rights reserved
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
- 14. © agileSEQUENT, Inc – All rights reserved
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
- 15. © agileSEQUENT, Inc – All rights reserved
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:
”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).
- 16. © agileSEQUENT, Inc – All rights reserved
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:
”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).
- 17. © agileSEQUENT, Inc – All rights reserved
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
- 18. © agileSEQUENT, Inc – All rights reserved
Features represent aggregated functionality required to
manage related activities
Defining building blocks
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
- 19. © agileSEQUENT, Inc – All rights reserved
Functions represent very granular tasks required to
enable each feature
Defining building blocks
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
Functions
• Consist of Use Cases
Products
• Consist of Components
c
Components
• Consist of Features
c
- 20. © agileSEQUENT, Inc – All rights reserved
Use Cases describe a sequence of steps (combined
functionality) to accomplish a chosen task
Defining building blocks
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
• Consist of Use Cases
Products
• Consist of Components
c
Components
• Consist of Features
c
Features
• Consist of Functions
- 21. © agileSEQUENT, Inc – All rights reserved
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
- 22. © agileSEQUENT, Inc – All rights reserved
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
- 23. © agileSEQUENT, Inc – All rights reserved
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
- 24. © agileSEQUENT, Inc – All rights reserved
… 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
- 25. © agileSEQUENT, Inc – All rights reserved
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
- 26. © agileSEQUENT, Inc – All rights reserved
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
- 27. © agileSEQUENT, Inc – All rights reserved
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
• Functional reference
Product User Guide
• Audience: actual users of the product
• Descriptions of functionality
• Common business scenarios
• Instructions
How PDS is used
• Functional reference
- 28. © agileSEQUENT, Inc – All rights reserved
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
• Functional reference
Product Deployment Guide
• Audience: adoption consultants
• Summarizes new features and functionality
• Content spec. changes & migration options
• Initial setup requirements
How PDS is used
• Functional reference
Product Marketing Collateral
• Descriptions of functionality
• Competitive analysis
How PDS is used
• Functional reference