fundamentals of product definition process - mrd prd frd
TRANSCRIPT
© agileSEQUENT, Inc – All rights reserved
Fundamentals of Software Product Definition Process
MRD > PRD > FRD
Leon Kotovich CEO
www.agilesequent.com
© 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
© 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
© 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
© 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?
© 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
© 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
© 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
© 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 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 …
© 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
© 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
© 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!
© 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
© 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
© 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).
© 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).
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
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
© 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
© agileSEQUENT, Inc – All rights reserved
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
© 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
© 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