Successfully reported this slideshow.
© CONCEP 2013#1 BEST PRACTICE OVERVIEW…THROUGHOUT PRODUCT LIFE CYCLEFebruary 2013Becky Yelland, Freelance Product Consulta...
+Contents1. Overview of the Product Life Cycle2. Detailed Documentation Descriptions and Purpose3. Review & Approval Proce...
+Output: FutureProduct roadmap• Future ProductRoadmapconsidered anddefined• Phased rolloutproposed &ValidatedOutput: BAUSu...
+ Document Definitions: Business CaseDocument Purpose DescriptionBUSINESS CASE:Overall Purpose is to Evaluate Market & Bus...
+ Document DefinitionsDocument Purpose DescriptionHigh Level Architecture Outline overall technical approach and integrati...
+ Document DefinitionsDocument Purpose DescriptionAcceptance CriteriaTo elevate the essential elements of a product that a...
+ Review & Approval ProcessFirst Gate toapproveresource toscope and plandevelopmentas well as draftbusiness caseSecond Gat...
+ Product Life Cycle Doc Requirement/R&RProductManager:DocsRequiredConcept Planning Development Test & Ramp Up Launch In L...
+ Applying Life Cycle to existing andplanned products Even though we have in theory retained development resource to enab...
+ Phase Overview: Concept This phase is based around idea generation and idea gathering. Feature prioritisation andinitia...
+ Phase Overview: Spec & Planning Assumption: You have been given approval at Gate 1 The purpose of this phase is to get...
+ Phase Overview: Dev/Test & Ramp up Assumption: You have been given approval at Gate 2 Lumping these two phases togethe...
+ Phase Overview: Launch Assumption: The product has passed testing, and adheres to all acceptance criteria The purpose ...
+ Phase Overview: In Life Assumption: The product is in life, adopted by one or several clients as a minimum The purpose...
Upcoming SlideShare
Loading in …5
×

Best practiceoverview productlifecycle_b_yelland

626 views

Published on

Becky Yelland's Best Practice guide on product life cycle product management.

Published in: Business
  • Be the first to comment

Best practiceoverview productlifecycle_b_yelland

  1. 1. © CONCEP 2013#1 BEST PRACTICE OVERVIEW…THROUGHOUT PRODUCT LIFE CYCLEFebruary 2013Becky Yelland, Freelance Product Consultant, LondonPRODUCT MANAGEMENT:
  2. 2. +Contents1. Overview of the Product Life Cycle2. Detailed Documentation Descriptions and Purpose3. Review & Approval Process4. Summary of stages and documents required and by whom5. Overview of each stage in cycle
  3. 3. +Output: FutureProduct roadmap• Future ProductRoadmapconsidered anddefined• Phased rolloutproposed &ValidatedOutput: BAUSupport & Analytics• Monitor In Life• Analysis ofperformance• Client support In Life• Product Improvementprogram in place• KB updated and BAUsupport launchedProduct Lifecycle OverviewOutput: Approvedfor launch• Test scripts andautomated testingrun and validated• Launch & Commsplan compiled• Marketing collateralupdated if req• KB and BAU supportdefinedPhases/Activities/OutputsGate 1Approval toresource planningApproval toResource dev andin lifeReady for Testing &Test Scripts createdRelease candidateapproved & in lifesupport in placeNew version, evolvedversion, integrated versionetc…ProductStrategyProductManagementProduct Marketing Strategy:Pricing and PropositionBusiness Case & Product strategyMarket/Competitor AnalysisProduct Features AnalysisTech/Platform Alignment analysisFunctionalSpec/NFRProgram of WorkProject PlanHigh LevelArchitectureKDD/Feature ListWireframes/PrototypeStrategy Execution IN LIFE / EvolutionLaunch PlanMarketing ExecutionOperational Readiness In Life AnalyticsProduct RoadmapBusinessCaseOutput : FirstIteration• Prototype/Proof Ofconcept built &validated• Full In flightdevelopment• Test Script definedand Collateralcreated• Create Productdelivery roadmap &strategy• Validate businesscase against planneddelivery• Define CostsOutput : FinalDocumentation• Generate & PrioritiseIdeas• Validate Conceptsagainst roadmap andmarket & Business needsOutput: DraftDocumentationComms PlanGate 2Gate 1Pricing ExecutionBusiness ImpactAnalysisMarketing PlanPricing PlanComms ExecutionMarketingMaintenanceComms MaintenanceSprint PlanningSales Collateral andDemos CreatedSprint PlanningConception Spec & Plan Development Test & Ramp Up Launch In LifeUser GuidesAdmin Set upGuidesGate 2Gate 2Gate 3
  4. 4. + Document Definitions: Business CaseDocument Purpose DescriptionBUSINESS CASE:Overall Purpose is to Evaluate Market & BusinessOpportunity, validate any assumptions made: to ensureboard buy & comfortIncludes: P&L, Market Opportunity, Competitor Analysis,Market Size, Pricing, Product Definition, Project Plan,Rollout Plan, Marketing Strategy.Market OpportunityConsiders incumbent providers, as well as client andprospect need & potential CompetitorsDescription of the market opportunity, analysis of wherethere is a gap and defining the resulting market needCompetitor AnalysisTo highlight where there are gaps in current providersofferings, and identity your USPsWord Doc descriptive approach is appropriate but a cribsheet/competitor comparison spreadsheet is required aswell.Market SizeTo put sales forecasts into context, and enable us toidentify what % of the market we are aiming for. Needsupdating for any new product not yet consideredUsing a pre defined framework listing all hypotheses anddata points this will be a global analysis across allverticals: Legal, Financial, Property and Consulting.PricingTo enable product and sales to align all knowledge onboth market/client and costs to ensure pricing of product isspot onPricing Sheet in word that could be sent to aclient/prospect and where necessary a calculator in excelwhere numerous choices/volume mean a variety of pricingoutcomes.Product DefinitionTo quickly explain the context/background and journey aproduct, it’s market potential and target user base, as wellas any future roadmap considerationsWord Doc with easily digestible content meant for execsummary viewershipProject PlanAs part of business case a thought through deliveryschedule enables resource and cost impact to beevaluatedIn Project or online: Smartsheet detailed list items withresource, start date and length as well as dependencies toenable updating and keep fresh (Excel is not able to dothis)Roll Out Plan*To ensure thought is given to how we will approach thisproduct with clients/prospects: i.e. trial free or otherwise ora Proof of Concept phase is requiredMemo style or slide deck to list out options if required toenable collaborative analysis and agreement of approachbetween sales/product/businessMarketing Strategy Determine how to take product to marketMarket strategy and long term objectives, positioning andhow to sell and who to.
  5. 5. + Document DefinitionsDocument Purpose DescriptionHigh Level Architecture Outline overall technical approach and integration requirementsAnalysis of functional spec/business requirements –outlining high level tech approach and alignment toexisting systems and processesFunctional SpecExpands on the full requirements on what needs to be built andenables TPM and Dev to create HLA and Platform approachetcA feature level description of the entire deliverable,it’s intended use and purposeNFRList of all required elements of product that are not functionalsuch as performance and reliability.Often part of Functional Spec the Non FunctionalRequirements are a high level requirementsdescription of what and how the product should bedelivered outside of features and functionality.Prioritised Feature ListLifted directly from Requirements document: Listing allfeatures/functionality required and then prioritised to feed intoSprint planningHeadline feature list of all functionality required,Prioritised and weighted per delivery/phase.Product/Module ImpactAnalysisTPM and Tech Architect analysis of all Products/Modules andtheir components to ensure early thought is given to expeditedelivery and future proof all workDetailed overview and planning upfront (before dev)for all upcoming Product/Module development toensure best approach for dev is used in the correctorderPlatform DefinitionTo ensure internal education on platform approach is always upto date and external buy is made easier with all USPs derivedfrom this understood and sold effectivelyNon Technical description of al products andmodules with their component for a non technicalaudience: Internal – Slide deck with descriptionsand interrelations between elements with diagramswhere helpful. External: Platform Sheet with FABbullets and diagramsTest ScriptsTo ensure testing covers off all aspects of a product leavinglittle to no room for manual error and ensuring a releasecandidate is as robust and market ready as it can be. Toinclude: functional testing, destructive testing, cross platformtesting and UAT testing.Ideally written by QA but in conjunction withProduct Manager a detailed approach to testing toindicate all expected outcomes and areas to focusand analyse (list all potential points of failure)
  6. 6. + Document DefinitionsDocument Purpose DescriptionAcceptance CriteriaTo elevate the essential elements of a product that are bothrequired and need full validated testing against to ensure avalid release candidate is taken to marketAll elements of a product that need to be completedand fully tested before a release candidate isapproved.Launch BAU Support planTo ensure all resource impacts and in life support elements arein place before go Live – that all KBs are written, all userguides and training approaches are agreed as well as any newor updated SLAs are writtenDetailed list of items to be created/updated withresource allocated, timings for each – can be aproject plan or a spreadsheet – ideally at this stagethe timelines will be fixed…Business Impact analysisTo identify the impact of a new product on existing resourceboth in Product/Dev/Support and in sales – and identify ifadditional resource is required to ensure the success of theproductEach line item should list through all elements of aproduct that need to be managed in life and the jobrole this needs to be done by with an indicator ifthat role/department is already at or over capacityInternal Comms planTo ensure all internal staff are made aware of the upcomingrelease/impact and knowledge base they are required to makeClient Training packs: UserGuides/Admin GuidesTo ensure all new users of the product/system have a step bystep guide they can dip into or read through to betterunderstand all the features available to them.A Word document for User Guides/Admin Guidesand a training plan for how to do online and F2Ftraining with clients where necessaryBusiness Intelligence ReportTo ensure all aspects of a product in life are analysed andunderstood to better know when a product is running asexpected but also to give insight to end user experience/pointsof failure and better monitor and plan for potentialdowntime/issues or fixes to be madeDaily, Weekly or Monthly analytics to detail datagathered on usage of product and issues withproduct and to be able to compare theseMonMonth, YearonYear to analyse commonthemes, seasonal issues, adoption curves etc
  7. 7. + Review & Approval ProcessFirst Gate toapproveresource toscope and plandevelopmentas well as draftbusiness caseSecond Gate torequest fulldevelopment/test and launchreadinessresource andapprove Finalbusiness casePost Developmentreview to analyselessons learnt andre assess in lifeimpact andresourcerequirements ifneeded• Draft Business Case:• Market Opportunity• Competitor Analysis• Indicative pricing• Product Definition• Marketing Strategy• Delivery plan for S&Pphase• Final Businesscase, Final versionof draft plus:• Market Sizingupdate• Rollout Plan• Full Projectplan to launch• Client training• KB articles• Support process& SLA• In Life Analyticson stability ofproduct• BAU handoverreviewGate 1 Gate 2Post ReviewReviewCriteriaSnrMgtBoard&strategicBoardReviewConcept Spec & Plan Development Test &Ramp UpLaunch In Life• Sprint Review• Sprint Planningupdates• Test Script• Acceptancecriteria• BAU In Lifeplanning• BAU and in Lifesupportapproach review• BI/AnalyticsRequirementsreview• Continual in lifeproductperformancereview• Continual in liferesource andbusinessimpactreviewGate 3Optional: 3rdGate toevaluatecontinuation ofdevelopmentbased on salessuccess andboard approval
  8. 8. + Product Life Cycle Doc Requirement/R&RProductManager:DocsRequiredConcept Planning Development Test & Ramp Up Launch In LifeProductDefinition/OverviewProject Plan to DevPhaseDev:DocsTPM:DocsRequiredProdDir:DocsRequiredBusiness ImpactAnalysisPlatform ImpactAnalysis:RequirementsPlatform ImpactAnalysis: HLABusiness Case:Cost/Resource Req forplanningBusiness Case:DRAFT for Gate 1Platform ModuleRequirementsFunctional Spec/NFRTo Market Project PlanBusiness Case: FINALfor Gate 2: MarketingStrategy/Plan &indicative PricingOn BoardingRequirementsTechnicalSpec/Platform ModuleDefinitionPlatform ModuledefinitionsPrioritised FeatureList: Draft Sprint PlanPre Sales Collateral:Defined per productFinalised Sprint PlanProduct: Test ScriptPlatform Module: TestScriptProduct & PlatformModule Test ScriptFinal Pricing DocsProduct Collateral: OnBoarding PackDesign/UXConcept Look & Feel Wireframe/Prototype Design AssetsFinal Look & Feel &Collateral DesignsAcceptance CriteriaLaunch & BAUSupport PlanIn Life BAU BusinessImpact AnalysisUpdatedPlatform AcceptanceCriteriaDev/PlatformAcceptance CriteriaMarketing & CollateralUpdatesKB Articles /Help DeskHand OverUser Guides/AdminGuides/ Training planPricing/Marketing PlanUpdated – Calculatorif requiredInternal CommsPlan/Marketing PlanProduct Mgt BestPractice Guidelinesand ProductTemplates updated ifnecessaryPlatform Definitionupdated if necessaryTech Approach andPlatform DefinitionDocument/ArchitectureUpdated if necessaryProduct DesignGuidelines updated ifnecessaryIn Life Analytics &Business IntelligenceRequirementsFinalised User GuidesClient Training PacksPost Mortem DeliveryReportRACI/Working GroupDefinedStakeholder/CommercialWorking Group agreedProduct Strategy andRoadmap AnalysisProduct & PlatformComponents StrategyProduct BusinessIntelligence Report:Template andMaintenanceProduct & PlatformComponents StrategyFinal ProductCollateral
  9. 9. + Applying Life Cycle to existing andplanned products Even though we have in theory retained development resource to enableus to deliver the product roadmap as defined it is still imperative we followthis process to ensure we secure that resource Present your draft business case at Gate 1 and final business case atGate 2 to ensure your product is given priority and/or retains it’s slot in thedevelopment plan. For example following Touch V1 Folio and Meet should both have theirbusiness cases presented and evaluated and the one deemed to have themost positive impact to an agreed criteria: i.e. Revenue, Client retentionand Acquisition will be given precedence.
  10. 10. + Phase Overview: Concept This phase is based around idea generation and idea gathering. Feature prioritisation andinitial market/competitor analysis. All features and products considered need to be somewhat equally evaluated using thefollowing 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, CompetitorAnalysis, Indicative pricing, Product Definition, Marketing Strategy, Delivery plan for S&P phase (resourcerequirements to get to Gate 2).Client feedback (following demo or use of product)Market Landscape: Market Size what portion of that is relevant to usCompetitor Offerings: What do alternative providers offer:Price/FeaturesTechnical Impact: what technologies make possible and how thosedictate timeframesBusiness Impact: the cost involved to deploy, resource needed and thecontext of this product un relation to the rest of the business prioritiesBusiness Requirements: Revenue potential, impact to retention andacquisition – what are your clients asking for?Concept Analysis Guide:Specification&Planning
  11. 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 wantto take to market, how this will be approached technically, the impact it will have onresource, whether more resource, or different resource is required and the cost to take thisto market – this will form your full and final business case. Which will also include fullMarket/Competitor analysis and ideally final pricing.NB: In some companies a phase is sometimes added before S&P, Feasibility, where more time and analysisis given to whether the concept is actually viable, both technically and commercially. If necessary this workshould be included in Spec & Plan phase to ensure you have considered all the risks involved in proceedinginto development.Output: – Final Business Case for Gate 2 ApprovalFull Technical Impact: Resource required, technical knowledge gapsidentified, equipment needed, services required.Platform Impact: Components and modules for product are analysed againstexisting platform elements.Specifications: Requirements document Feature list, Platform impact andsales 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 etcBusiness Impact: As part of the final business case you will build a view ofthe size of the user base =- resource impact in life should be evaluatedStakeholder Management: Ensure all stakeholders which by this stage mayinclude clients are kept in the loop and their expectations managedSpec & Plan Work Considerations:Development
  12. 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 scopeover both. The role of a product manager in this phase in the absence of a project manager is to beaccountable for delivery and continued stakeholder management, reporting on latestupdates 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 involvementmore towards the end of this phase and be bringing the rest of the organisation alongsideyou in preparation for Launch.Output: – Launch Ready: product/Collateral/Marketing plan and Support infrastructureDev/Test & Ramp up Work Considerations:LaunchClient feedback (Ensure all feedback from demos is logged and fed back into the product pipelineMarket Landscape: Continue to monitor this and apply learnings into feature prioritisation andcollateral workCompetitor Offerings: What are your USPs? This is your knowledge to own, you should by now bethe 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 androbustness of your product, ensure you define clearly what a launch candidate could beBusiness Impact: You will now be considering in intricate detail the impact to resource in life for thisproduct, both for sales and support as well as in Product and Technology.Stakeholder Management: Continue to ensure all stakeholders which by this stage may includeclients are kept in the loop and their expectations managed
  13. 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 preparedoperationally 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 andall resource impacted by the new product have all the tools and knowledge necessary todo their job..NB: In some companies a phase is sometimes added before Launch called Operational Readiness, wherepost development and test complete an allotted time is given (almost in limbo) to ensure everything requiredfor launch is in place, for Concep this operational readiness is both part of ramp up and launch, as of courseonce launched, we often have time for operational readiness as the adoption curve has a delay due to thelength of the sales cycle.Output: – Operationally ready for the product to be in lifeClient Need: Ensure all training considerations and user guides arecomplete and tested, as well as all sales material being fully up to dateMarket Update: To ensure collateral is up to date ensure latest knowledge isshared, USPs are defined and your strengths are promotedSpecifications: Ensure BAU in life is fully considered all documents andreference points are up to date and everything is stored in Trello or similarRisks: This should be a continual evaluation, what are the risks to thebusiness if this product fails//resource impact to support etcBusiness Intelligence: The required reports should be finalised and aplan to deliver them in placeProduct Roadmap: Analysis of the delivery to date and post mortem aswell as anything deprioritized for launch should go into the long term planLaunch Work Considerations:InLife
  14. 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 interms of:• Stability• Support• Analysis: Business Intelligence and reporting• Continual evolution/Feature RoadmapOutput: – All features and future phases go back into ConceptClient Need: All feedback from client sales and end users is captured andfed into the product roadmap – using same assessment criteriaMarket Update: Continually monitored, as product owner you areresponsible for this knowledge, shared into collateral and salesCompetitor Analysis: Constant monitoring of how your product stacks upagainst your competition, ensuring collateral and USP is always accurateProduct Stability: As part of in life monitoring any tweaks to ensurevolume and capacity are managed is criticalBusiness Intelligence: Product owner is responsible for collation anddissemination of this information – and analysis of data MoM, YoY etcProduct Roadmap: As product evolves and features are added – ensureyou use the concept assessment criteria to validate priorityIn Life Work Considerations:Concept

×