This document provides an overview of best practices for managing a product throughout its lifecycle. It outlines the key stages in a product lifecycle from concept through launch and into ongoing support. For each stage, it describes the important documents required and who is responsible for them, such as requirement documents, test plans, business cases and more. The document aims to provide guidance on applying a standardized product lifecycle process across an organization.

1. © CONCEP 2013
#1 BEST PRACTICE OVERVIEW
…THROUGHOUT PRODUCT LIFE CYCLE
February 2013
Becky Yelland, Freelance Product Consultant, London
PRODUCT MANAGEMENT:

2. +
Contents
1. Overview of the Product Life Cycle
2. Detailed Documentation Descriptions and Purpose
3. Review & Approval Process
4. Summary of stages and documents required and by whom
5. Overview of each stage in cycle

3. +
Output: Future
Product roadmap
• Future Product
Roadmap
considered and
defined
• Phased rollout
proposed &
Validated
Output: BAU
Support & Analytics
• Monitor In Life
• Analysis of
performance
• Client support In Life
• Product Improvement
program in place
• KB updated and BAU
support launched
Product Lifecycle Overview
Output: Approved
for launch
• Test scripts and
automated testing
run and validated
• Launch & Comms
plan compiled
• Marketing collateral
updated if req
• KB and BAU support
defined
Phases/Activities/Outputs
Gate 1
Approval to
resource planning
Approval to
Resource dev and
in life
Ready for Testing &
Test Scripts created
Release candidate
approved & in life
support in place
New version, evolved
version, integrated version
etc…
Product
Strategy
Product
Management
Product Marketing Strategy:
Pricing and Proposition
Business Case & Product strategy
Market/Competitor Analysis
Product Features Analysis
Tech/Platform Alignment analysis
Functional
Spec/NFR
Program of Work
Project Plan
High Level
Architecture
KDD/
Feature List
Wireframes/
Prototype
Strategy Execution IN LIFE / Evolution
Launch Plan
Marketing Execution
Operational Readiness In Life Analytics
Product Roadmap
Business
Case
Output : First
Iteration
• Prototype/Proof Of
concept built &
validated
• Full In flight
development
• Test Script defined
and Collateral
created
• Create Product
delivery roadmap &
strategy
• Validate business
case against planned
delivery
• Define Costs
Output : Final
Documentation
• Generate & Prioritise
Ideas
• Validate Concepts
against roadmap and
market & Business needs
Output: Draft
Documentation
Comms Plan
Gate 2Gate 1
Pricing Execution
Business Impact
Analysis
Marketing Plan
Pricing Plan
Comms Execution
Marketing
Maintenance
Comms Maintenance
Sprint Planning
Sales Collateral and
Demos Created
Sprint Planning
Conception Spec & Plan Development Test & Ramp Up Launch In Life
User Guides
Admin Set up
Guides
Gate 2Gate 2
Gate 3

4. + Document Definitions: Business Case
Document Purpose Description
BUSINESS CASE:
Overall Purpose is to Evaluate Market & Business
Opportunity, validate any assumptions made: to ensure
board buy & comfort
Includes: P&L, Market Opportunity, Competitor Analysis,
Market Size, Pricing, Product Definition, Project Plan,
Rollout Plan, Marketing Strategy.
Market Opportunity
Considers incumbent providers, as well as client and
prospect need & potential Competitors
Description of the market opportunity, analysis of where
there is a gap and defining the resulting market need
Competitor Analysis
To highlight where there are gaps in current providers
offerings, and identity your USPs
Word Doc descriptive approach is appropriate but a crib
sheet/competitor comparison spreadsheet is required as
well.
Market Size
To put sales forecasts into context, and enable us to
identify what % of the market we are aiming for. Needs
updating for any new product not yet considered
Using a pre defined framework listing all hypotheses and
data points this will be a global analysis across all
verticals: Legal, Financial, Property and Consulting.
Pricing
To enable product and sales to align all knowledge on
both market/client and costs to ensure pricing of product is
spot on
Pricing Sheet in word that could be sent to a
client/prospect and where necessary a calculator in excel
where numerous choices/volume mean a variety of pricing
outcomes.
Product Definition
To quickly explain the context/background and journey a
product, it’s market potential and target user base, as well
as any future roadmap considerations
Word Doc with easily digestible content meant for exec
summary viewership
Project Plan
As part of business case a thought through delivery
schedule enables resource and cost impact to be
evaluated
In Project or online: Smartsheet detailed list items with
resource, start date and length as well as dependencies to
enable updating and keep fresh (Excel is not able to do
this)
Roll Out Plan*
To ensure thought is given to how we will approach this
product with clients/prospects: i.e. trial free or otherwise or
a Proof of Concept phase is required
Memo style or slide deck to list out options if required to
enable collaborative analysis and agreement of approach
between sales/product/business
Marketing Strategy Determine how to take product to market
Market strategy and long term objectives, positioning and
how to sell and who to.

5. + Document Definitions
Document Purpose Description
High Level Architecture Outline overall technical approach and integration requirements
Analysis of functional spec/business requirements –
outlining high level tech approach and alignment to
existing systems and processes
Functional Spec
Expands on the full requirements on what needs to be built and
enables TPM and Dev to create HLA and Platform approach
etc
A feature level description of the entire deliverable,
it’s intended use and purpose
NFR
List of all required elements of product that are not functional
such as performance and reliability.
Often part of Functional Spec the Non Functional
Requirements are a high level requirements
description of what and how the product should be
delivered outside of features and functionality.
Prioritised Feature List
Lifted directly from Requirements document: Listing all
features/functionality required and then prioritised to feed into
Sprint planning
Headline feature list of all functionality required,
Prioritised and weighted per delivery/phase.
Product/Module Impact
Analysis
TPM and Tech Architect analysis of all Products/Modules and
their components to ensure early thought is given to expedite
delivery and future proof all work
Detailed overview and planning upfront (before dev)
for all upcoming Product/Module development to
ensure best approach for dev is used in the correct
order
Platform Definition
To ensure internal education on platform approach is always up
to date and external buy is made easier with all USPs derived
from this understood and sold effectively
Non Technical description of al products and
modules with their component for a non technical
audience: Internal – Slide deck with descriptions
and interrelations between elements with diagrams
where helpful. External: Platform Sheet with FAB
bullets and diagrams
Test Scripts
To ensure testing covers off all aspects of a product leaving
little to no room for manual error and ensuring a release
candidate is as robust and market ready as it can be. To
include: functional testing, destructive testing, cross platform
testing and UAT testing.
Ideally written by QA but in conjunction with
Product Manager a detailed approach to testing to
indicate all expected outcomes and areas to focus
and analyse (list all potential points of failure)

6. + Document Definitions
Document Purpose Description
Acceptance Criteria
To elevate the essential elements of a product that are both
required and need full validated testing against to ensure a
valid release candidate is taken to market
All elements of a product that need to be completed
and fully tested before a release candidate is
approved.
Launch BAU Support plan
To ensure all resource impacts and in life support elements are
in place before go Live – that all KBs are written, all user
guides and training approaches are agreed as well as any new
or updated SLAs are written
Detailed list of items to be created/updated with
resource allocated, timings for each – can be a
project plan or a spreadsheet – ideally at this stage
the timelines will be fixed…
Business Impact analysis
To identify the impact of a new product on existing resource
both in Product/Dev/Support and in sales – and identify if
additional resource is required to ensure the success of the
product
Each line item should list through all elements of a
product that need to be managed in life and the job
role this needs to be done by with an indicator if
that role/department is already at or over capacity
Internal Comms plan
To ensure all internal staff are made aware of the upcoming
release/impact and knowledge base they are required to make
Client Training packs: User
Guides/Admin Guides
To ensure all new users of the product/system have a step by
step guide they can dip into or read through to better
understand all the features available to them.
A Word document for User Guides/Admin Guides
and a training plan for how to do online and F2F
training with clients where necessary
Business Intelligence Report
To ensure all aspects of a product in life are analysed and
understood to better know when a product is running as
expected but also to give insight to end user experience/points
of failure and better monitor and plan for potential
downtime/issues or fixes to be made
Daily, Weekly or Monthly analytics to detail data
gathered on usage of product and issues with
product and to be able to compare these
MonMonth, YearonYear to analyse common
themes, seasonal issues, adoption curves etc

7. + Review & Approval Process
First Gate to
approve
resource to
scope and plan
development
as well as draft
business case
Second Gate to
request full
development/te
st and launch
readiness
resource and
approve Final
business case
Post Development
review to analyse
lessons learnt and
re assess in life
impact and
resource
requirements if
needed
• Draft Business Case:
• Market Opportunity
• Competitor Analysis
• Indicative pricing
• Product Definition
• Marketing Strategy
• Delivery plan for S&P
phase
• Final Business
case, Final version
of draft plus:
• Market Sizing
update
• Rollout Plan
• Full Project
plan to launch
• Client training
• KB articles
• Support process
& SLA
• In Life Analytics
on stability of
product
• BAU handover
review
Gate 1 Gate 2
Post Review
ReviewCriteria
SnrMgtBoard&
strategicBoardReview
Concept Spec & Plan Development Test &
Ramp Up
Launch In Life
• Sprint Review
• Sprint Planning
updates
• Test Script
• Acceptance
criteria
• BAU In Life
planning
• BAU and in Life
support
approach review
• BI/Analytics
Requirements
review
• Continual in life
product
performance
review
• Continual in life
resource and
business
impact
review
Gate 3
Optional: 3rd
Gate to
evaluate
continuation of
development
based on sales
success and
board approval

8. + Product Life Cycle Doc Requirement/R&R
ProductManager:
DocsRequired
Concept Planning Development Test & Ramp Up Launch In Life
Product
Definition/Overview
Project Plan to Dev
Phase
Dev:
Docs
TPM:
Docs
Required
ProdDir:Docs
Required
Business Impact
Analysis
Platform Impact
Analysis:
Requirements
Platform Impact
Analysis: HLA
Business Case:
Cost/Resource Req for
planning
Business Case:
DRAFT for Gate 1
Platform Module
Requirements
Functional Spec/NFR
To Market Project Plan
Business Case: FINAL
for Gate 2: Marketing
Strategy/Plan &
indicative Pricing
On Boarding
Requirements
Technical
Spec/Platform Module
Definition
Platform Module
definitions
Prioritised Feature
List: Draft Sprint Plan
Pre Sales Collateral:
Defined per product
Finalised Sprint Plan
Product: Test Script
Platform Module: Test
Script
Product & Platform
Module Test Script
Final Pricing Docs
Product Collateral: On
Boarding Pack
Design/U
X
Concept Look & Feel Wireframe/Prototype Design Assets
Final Look & Feel &
Collateral Designs
Acceptance Criteria
Launch & BAU
Support Plan
In Life BAU Business
Impact Analysis
Updated
Platform Acceptance
Criteria
Dev/Platform
Acceptance Criteria
Marketing & Collateral
Updates
KB Articles /Help Desk
Hand Over
User Guides/Admin
Guides/ Training plan
Pricing/Marketing Plan
Updated – Calculator
if required
Internal Comms
Plan/Marketing Plan
Product Mgt Best
Practice Guidelines
and Product
Templates updated if
necessary
Platform Definition
updated if necessary
Tech Approach and
Platform Definition
Document/Architecture
Updated if necessary
Product Design
Guidelines updated if
necessary
In Life Analytics &
Business Intelligence
Requirements
Finalised User Guides
Client Training Packs
Post Mortem Delivery
Report
RACI/Working Group
Defined
Stakeholder/Commercial
Working Group agreed
Product Strategy and
Roadmap Analysis
Product & Platform
Components Strategy
Product Business
Intelligence Report:
Template and
Maintenance
Product & Platform
Components Strategy
Final Product
Collateral

9. + Applying Life Cycle to existing and
planned products
 Even though we have in theory retained development resource to enable
us to deliver the product roadmap as defined it is still imperative we follow
this process to ensure we secure that resource
 Present your draft business case at Gate 1 and final business case at
Gate 2 to ensure your product is given priority and/or retains it’s slot in the
development plan.
 For example following Touch V1 Folio and Meet should both have their
business cases presented and evaluated and the one deemed to have the
most positive impact to an agreed criteria: i.e. Revenue, Client retention
and Acquisition will be given precedence.

10. + Phase Overview: Concept
 This phase is based around idea generation and idea gathering. Feature prioritisation and
initial market/competitor analysis.
 All features and products considered need to be somewhat equally evaluated using the
following criteria:
• Technology Requirement
• Market Impact/Competitor offerings
• Business Impact (bottom line)
• Client Value
 Output: – Draft Business Case for Gate 1 Approval: Initial versions of: Market Opportunity, Competitor
Analysis, Indicative pricing, Product Definition, Marketing Strategy, Delivery plan for S&P phase (resource
requirements to get to Gate 2).
Client feedback (following demo or use of product)
Market Landscape: Market Size what portion of that is relevant to us
Competitor Offerings: What do alternative providers offer:
Price/Features
Technical Impact: what technologies make possible and how those
dictate timeframes
Business Impact: the cost involved to deploy, resource needed and the
context of this product un relation to the rest of the business priorities
Business Requirements: Revenue potential, impact to retention and
acquisition – what are your clients asking for?
Concept Analysis Guide:
Specification
&Planning

11. + Phase Overview: Spec & Planning
 Assumption: You have been given approval at Gate 1
 The purpose of this phase is to get into the detail, ensure you know exactly what you want
to take to market, how this will be approached technically, the impact it will have on
resource, whether more resource, or different resource is required and the cost to take this
to market – this will form your full and final business case. Which will also include full
Market/Competitor analysis and ideally final pricing.
NB: In some companies a phase is sometimes added before S&P, Feasibility, where more time and analysis
is given to whether the concept is actually viable, both technically and commercially. If necessary this work
should be included in Spec & Plan phase to ensure you have considered all the risks involved in proceeding
into development.
Output: – Final Business Case for Gate 2 Approval
Full Technical Impact: Resource required, technical knowledge gaps
identified, equipment needed, services required.
Platform Impact: Components and modules for product are analysed against
existing platform elements.
Specifications: Requirements document Feature list, Platform impact and
sales collateral all need completion before the end of this phase,
Risks: Look at all the risks, both of doing and NOT doing this work internally,
externally focused to market and client impact etc
Business Impact: As part of the final business case you will build a view of
the size of the user base =- resource impact in life should be evaluated
Stakeholder Management: Ensure all stakeholders which by this stage may
include clients are kept in the loop and their expectations managed
Spec & Plan Work Considerations:
Development

12. + Phase Overview: Dev/Test & Ramp up
 Assumption: You have been given approval at Gate 2
 Lumping these two phases together as the work for a product manager has equal scope
over both.
 The role of a product manager in this phase in the absence of a project manager is to be
accountable for delivery and continued stakeholder management, reporting on latest
updates as well as planning for and creating all documentation in readiness for Launch.
 The name Test and Ramp up indicates as a PM you will start to increase your involvement
more towards the end of this phase and be bringing the rest of the organisation alongside
you in preparation for Launch.
Output: – Launch Ready: product/Collateral/Marketing plan and Support infrastructure
Dev/Test & Ramp up Work Considerations:
Launch
Client feedback (Ensure all feedback from demos is logged and fed back into the product pipeline
Market Landscape: Continue to monitor this and apply learning's into feature prioritisation and
collateral work
Competitor Offerings: What are your USPs? This is your knowledge to own, you should by now be
the product expert and have attended competitor demos and know all there is to know….
Product Integrity: whilst you will not write the test scripts you are responsible for the quality, integrity and
robustness of your product, ensure you define clearly what a launch candidate could be
Business Impact: You will now be considering in intricate detail the impact to resource in life for this
product, both for sales and support as well as in Product and Technology.
Stakeholder Management: Continue to ensure all stakeholders which by this stage may include
clients are kept in the loop and their expectations managed

13. + Phase Overview: Launch
 Assumption: The product has passed testing, and adheres to all acceptance criteria
 The purpose of this phase is to ensure the product and the business are fully prepared
operationally for the product to be in life i.e. being used by clients.
 All work in this stage is to ensure that a BAU (Business as usual) process is created and
all resource impacted by the new product have all the tools and knowledge necessary to
do their job..
NB: In some companies a phase is sometimes added before Launch called Operational Readiness, where
post development and test complete an allotted time is given (almost in limbo) to ensure everything required
for launch is in place, for Concep this operational readiness is both part of ramp up and launch, as of course
once launched, we often have time for operational readiness as the adoption curve has a delay due to the
length of the sales cycle.
Output: – Operationally ready for the product to be in life
Client Need: Ensure all training considerations and user guides are
complete and tested, as well as all sales material being fully up to date
Market Update: To ensure collateral is up to date ensure latest knowledge is
shared, USPs are defined and your strengths are promoted
Specifications: Ensure BAU in life is fully considered all documents and
reference points are up to date and everything is stored in Trello or similar
Risks: This should be a continual evaluation, what are the risks to the
business if this product fails//resource impact to support etc
Business Intelligence: The required reports should be finalised and a
plan to deliver them in place
Product Roadmap: Analysis of the delivery to date and post mortem as
well as anything deprioritized for launch should go into the long term plan
Launch Work Considerations:
InLife

14. + Phase Overview: In Life
 Assumption: The product is in life, adopted by one or several clients as a minimum
 The purpose of this phase is to ensure the product team continue to own the product in
terms of:
• Stability
• Support
• Analysis: Business Intelligence and reporting
• Continual evolution/Feature Roadmap
Output: – All features and future phases go back into Concept
Client Need: All feedback from client sales and end users is captured and
fed into the product roadmap – using same assessment criteria
Market Update: Continually monitored, as product owner you are
responsible for this knowledge, shared into collateral and sales
Competitor Analysis: Constant monitoring of how your product stacks up
against your competition, ensuring collateral and USP is always accurate
Product Stability: As part of in life monitoring any tweaks to ensure
volume and capacity are managed is critical
Business Intelligence: Product owner is responsible for collation and
dissemination of this information – and analysis of data MoM, YoY etc
Product Roadmap: As product evolves and features are added – ensure
you use the concept assessment criteria to validate priority
In Life Work Considerations:
Concept