Part I: What is a Product Lifecycle Process?

Part I in a 5-part series about the process of implementing a new product lifecycle process within a high technology company.

A Great Product Life Cycle Process is the Framework of a Great Company

If you work in high tech, then chances are you follow some sort of product life cycle process — it’s the structure imposed on the development of a software product from the moment the idea materializes until the product must be retired. The question is: how good is the product life cycle process that your company uses? Should you optimize your product life cycle process to be more effective?

  • Do your company’s departments all work in silos, handing off work via Project Managers?
  • Do cross-departmental deliverables arrive late, incorrect, or insufficient?
  • Is company awareness of what major projects are being worked on very low?
  • Do your products or features have a tendency to fail in the market?
  • Is there little to no project transparency for major projects?
  • Is there a lack of individual accountability?
  • Do you often have to complete tasks that are not part of your job description?
  • Does your company suffer from project bottlenecks?
  • Are critical or late-stage resources constantly stressed and overworked due to receiving dependency materials too late?
  • Is your product bloated with features guided by the HIPPO (HIghest Paid Person’s Opinion) in the room?
  • Do products get released and then get abandoned?
  • Do projects get going and forget to include the right people until it’s too late?
  • Do you find yourself with questions about the project and not knowing who to ask?
  • Does your company seem to have arbitrary release dates and budgetary planning?

If you answered ‘Yes’ to any of those questions, it sounds like your product lifecycle could use an update.

What is a Product Life Cycle Process?

A product life cycle’s (or PLC for short) main goal is to ensure that the right people are working on the right projects at the right time. It identifies what tasks need to be completed in order to bring a product to market, as well as who is accountable for each task, who is responsible for approving each task/deliverable, at what point in the cycle each tasks needs to be completed, and so on. You can think of each product as having a point of conception (defining the idea of the product), then moving through an elaboration period (defining the specifics of the product) before going through the actual construction of the product (development), and then being released. And it doesn’t end there — a good product life cycle also accounts for the maintenance of that product (refining and adding additional features), measuring its success or failure, and eventually determining an “end of life” plan for it when it becomes technologically unsustainable, or irrelevant to the market or business.

While there are a plethora of process styles to choose from (each with their own varied approaches and timelines to essentially the same set of tasks or activities that need to take place), the two basic frameworks are Waterfall and Iterative (most commonly referred to as “Agile”).

Waterfall Product Lifecycle Process

Requirements > Design > Implementation > Quality Assurance > Maintenance

An illustration of the Waterfall model (source: http://blog.hydro4ge.com/waterfall-to-boehm/)

According to Wikipedia, “the waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, AnalysisDesign, Construction, TestingProduction/Implementation, and Maintenance.” I couldn’t have said it better myself :). Basically, the Waterfall model’s aim is to plan a product 100% before handing over a “how to” guide of fully completed functional specifications to Development to build it. The spirit of this concept is to crystalize each team member’s efforts within a phase — the Business folk huddle up from Conception to Analysis, then hand it over to the Design team who create the mockups per their requirements, then they hand everything over the fence to Development for Construction, Testing, and Implementation. Waterfall models generally work best for cultures that demand order and structure.

Pros and Cons of Waterfall Model

Pros:

  • Predictive model front-loads risk to planning phases
  • Departments stay focused on specific tasks
  • Emphasis on planning and research
  • Staged approach enforces discipline
  • Roles + tasks are well-defined
  • Progress is easy to define through Waterfall’s use of milestones
  • Use of full functional specifications make it easier to work with remote developers

Cons:

  • Stifles collaborative creativity
  • Difficult to anticipate and plan for all customer requirements
  • Does not adapt to change well
  • Does not fold in all departmental feedback during the planning process
  • Takes a long time for something to be built
  • Designs often need substantial rework once they get to development

Iterative or “Agile” Product Lifecycle Process

Planning > Implementation > Testing > Feedback > Project Standups + Sprints throughout

An illustration of the Agile process (source: http://www.sohamgreens.com/process.html)

“Agile projects are paintings, not photographs.” – Unknown

“Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizingcross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change,” (thanks again, Wikipedia!). Basically, Agile methodologies are all about focusing on getting features out into the wild as quickly as possible, and then learning from metrics and customer feedback. It encourages internal feedback from all departments, embraces speed and change, and eschews thorough documentation. Agile methodologies work best in cultures that respond well to change.

Pros and Cons of Agile Methodologies

Pros:

  • Encourages collaboration throughout the entire process
  • Fast development cycles called “sprints”
  • Products receive real-world market feedback quickly
  • Adaptive model makes responding to change easier

Cons:

  • Development spends more time planning, less time coding
  • Risk of releasing unviable features is heightened
  • Less time for market research and planning
  • Lack of documentation can prove challenging
  • Dangerous for mission critical projects due to iterative nature

So Which Product Life Cycle Process is Best?

Which product life cycle process is “the best”? The question really should be, which product life cycle process is best for your company. My next post will address why a company should invest in implementing a tailor-made product lifecycle process; and future posts will detail how to determine which product life cycle process is right for your company (SPOILER ALERT: it’ll most likely be a mix of the frameworks above), and how to properly roll it out to the company.

Next up in the Product Life Cycle series:

Part II: The Benefits and Risks of Implementing a Product Lifecycle Process

Deep Dive: Product Management Responsibilities

The goal of my basics of product management post was to help inform those who are new to product management (on a high level) what a PM is expected to deliver. Upon reflection, I realized that I should further address the issue of other departments not knowing or understanding the role of product manager, as that can deeply affect your job satisfaction. Sadly, this often results in product management being treated as a “catch-all” or an intellectual janitor — when one department makes a mess or gets in over their heads, PM is expected to come in and clean it up. This is a terrible state for any company to be in, namely because it hinders Product’s ability to be forward-thinking, and thorough in its market research.

You see, PM needs to be forward-thinking at all times — even when analyzing past and current releases, PM must be doing so in the context of the greater product strategy. When PM becomes subjugated in this manner, everyone loses. The more time the product manager is bogged down with jobs that other departments should be handling, the more future product releases will suffer. It may not be evident in the next quarter, or even the one after that…but mismanaged products tend to have far-reaching and long lasting consequences.

IMPORTANT NOTE: If you are not leading Product Management, then DO NOT circumvent your manager! It is their responsibility to effect this change in the organization, and bypassing them will most likely cause you to end up in hot water — or worse.

Product Management (PM) – Those who listen to the market and articulate its problems and future needs in the form of requirements.

What does product management do?

Overview:

  • Researches customer need for the product.
  • Evaluates competitive situation.
  • Determines how product would be sold to customers, and develops a support plan to do so.
  • Sets prices for product.
  • Directs development process to ensure product will meet customer needs.
  • Works with sales, marketing, support, and engineering to ensure groups can meet customer needs.
  • Works with marketing on marketing plan; provides information and participates in discussions.
  • Post-launch, gathers intelligence about how product is being received by customers, continues to supply marketing with data, and conceptualizes new products to develop and sell.

Specific activities:

  • Listens to the market and creates roadmap and future product needs in the form of requirements.
  • Works hand-in-hand with product development to ensure product requirements are delivered to spec and on-time.
  • Communicates roadmap to customers/market.
  • Establishes overall product portfolio vision/direction, including Technology Assessment and Architecture.
  • Creates and maintains business case for each product and overall portfolio.
  • Initiates market research and sizes markets.
  • Specifies market requirements for current and future products by conducting market research supported by on-going visits to customers and non-customers.
  • Writes detailed product specifications for use by Product Development.
  • Prioritizes product requirements/specifications based on business case and PD capacity.
  • Maintains product family roadmap and monitors Product Development schedules.
  • Serves as solution/technical expert when dealing with thought leaders, analysts, and press.
  • Provides content/copy for promotional materials and sales training.
  • Provides competitive product analysis.
  • Monitors industry innovations and technology.
  • Analyzes product performance.
  • Documents product profitability and operational metrics by tracking Key Performance Indicators (KPIs).
  • Maintains key industry associations, preferably participating in relevant consortiums or standards committees (or by overseeing/coordinating other company personnel that participate).
  • Provides support in development of marketing communications, including sales collateral public relations, industry publications, customer correspondence, trade shows & analyst tours.
  • Writes white papers and technical communiqués as needed.
  • Provides content for product collateral and presentations.

Ownership:

Product Roadmap

  • Product portfolio vision/direction.
  • Roadmap defines:
    • What we build.
    • When we build it.
    • Why we are building it.
    • Who will be buying it.
    • Why they will buy it.

Operational Metrics (Key Performance Indicators)

  • Product financial performance
    • Product profitability.
    • Acceptance Testing
      • Are product requirements meeting goals?
      • Delivery
        • Is product available in a timely, high quality manner after release with availability well-communicated?
      • Support
        • Is Product Support meeting the needs of our customers?
        • Customer satisfaction (based on Net Promoter Score).
        • Not responsibility of PM, but should be asking for this info on a regular basis.

Thought Leadership

  • Product Management are the product champions.
    • Part of their responsibility is to be looking forward.
    • Out-of-the-box thinking
      • Thought leaders challenge the status quo.
      • Always looking for a better way.
      • Maybe disruptive.
      • New market opportunities
        • Discuss with analysts, editors, researchers.
        • Bring technical view to discussions with analysts, editors, researchers.

Technology Assessment

  • Technology Assessment is both responsibility of Product  Management and Product Development / Engineering
  • Product Management performs Technology Assessment in order to:
    • Evaluate potential acquisition.
    • Relevance to market acceptance/adoption.
    • New trends and opportunities.
    • Product Development / Engineering performs Technology  Assessment to deliver required functionality.