Product Development Lifecycle

This describes the collective processes that are commonly involved in bringing a digital product from an idea to reality and then continuing its evolution with new or modified features. It may look differently within different organizations and for different products, but most often includes the same processes, albeit with some modifications or under alternative names. These processes might be performed in a linear fashion or iteratively, occurring concurrently with varying degrees of effort and collaboration.

A similar term to the product development lifecycle (PDLC) is the software development lifecycle (SDLC), though it only refers to the scope of the development process of software products, which is a subset of the product development lifecycle. And note that the product lifecycle refers to the entire lifespan of a product from its initial conception through its development, market entry, growth, maturity, and eventual decline or discontinuation (a superset of the product development and SDLC).

Note that the lifecycle described here excludes a product’s end of life (AKA retirement or sunsetting). That is on the list of topics to be covered in a future article.

Definitions:

Stakeholders: Any role, team or group in any part of the business (e.g. Sales, Marketing, Legal), engineering or a vendor/partner that are in some ways responsible for, accountable for or impacted by product management decisions.

Deliverable: A new product, a feature being added to a product, or a changed feature.

The Overall Objective of PDLC:

No matter how the product development lifecycle is implemented, the ultimate outcome should always be a deliverable that is:

• Valuable to the Customer: It is something that a customer will use.
• Usable by the Customer: It provides an optimal user experience.
• Technically Feasible: The technology exists to build it that is within time and cost constraints.
• Viable for the Business: It aligns with the business strategy and model (including operational impacts).

Stakeholder Input:

Similar and Related Names: Intakes, Requirement Gathering, Product Planning, Needs Assessment, Feature Request

Stakeholders play a critical role in the digital product lifecycle and can be seen as ‘internal customers,’ whose needs must be prioritized alongside those of the end users or ‘external customers.’ These needs can range from strategic requirements to operational or technical specifications. For example, a Sales leader may require analytics capabilities within the product to identify potential leads, ensuring that sales teams can optimize their outreach. Similarly, an engineering lead may need to implement changes to comply with security policies, potentially affecting the login experience or other product features. Additionally, stakeholders often gather valuable feedback from customers or prospects, highlighting pain points or new opportunities that may influence future iterations of the product. Incorporating stakeholder input into the development process ensures a more comprehensive, user-centric product that aligns with both business goals and technical constraints.

Vision and Strategy:

Similar and Related Names: Strategic Planning, Vision & Strategy Development, Product Strategy Definition, Goal Setting & Strategy Refinement

While related and often referred to interchangeably, the product vision and strategy need to be considered and utilized differently. The product strategy, although separate, aligns with other strategies like business and technology strategies to the extent they relate to the product. Both the product vision and strategy are typically defined by product leaders, such as the Head of Product.

A product strategy is essential, while a vision is optimal. The product vision defines a long-term, aspirational future that describes the product’s aspirational direction, which may extend beyond current technical capabilities. The product strategy acts as a guiding principle, informing decisions made during the discovery process for all intakes, and ensuring alignment with broader business goals while working toward the vision.

The primary purpose of a product vision is to inspire and evangelize a future state of a product that are often more revolutionary than evolutionary in nature – in ways that would yield significant benefits. A vision can help motivate product teams and assist with recruiting talent.

There is no hard and fast definition or set of rules for defining a product strategy other than having one and ensuring it is kept relevant and adopted. Below are some general considerations:

• Aligns with Business Objectives: Consistent with business, technology, and related strategies and goals.
• Incorporates the Target Market and Customer: Tailored to the relevant segments and personas.
• States the Value Proposition: Clearly articulates the unique benefits of the product, including competitive differentiators.
• Identifies Key Objectives: Defines measurable goals, such as the impact on key performance indicators (KPIs).

A product strategy might also incorporate technology, such as the platform or type of application (e.g., web, mobile, or both).

Evaluation:

Similar and Related Names: Post-Launch Review, Analysis, Impact Assessment, Monitoring and Feedback

The only way to know if a product or its features yielded the expected outcome is to evaluate the results. And ongoing evaluation, encompassing both metrics and external factors such as market trends, customer behavior shifts, and competitive landscape changes, can offer invaluable insight that becomes a continuous feedback loop into the discovery process.

When first building a product, instrumentation for evaluations is a foundational feature. And a best practice of product management that is rooted in a data-driven decision-making is to use metrics to justify and prioritize their work on all features. That requires that with each change to a product there are clearly defined metrics for measuring outcomes and the instrumentation needed to capture and analyze that data.

Metrics used for evaluation can be categorized as follows:

• Basic Analytics: Data obtained passively, such as page view counts, which provide insights into user engagement without active interaction. (e.g. the number of times a web page is viewed)
• Event Metrics: Information captured for a specific event related to a product’s use (e.g. adding an item to a shopping cart)
• Transactional Data: Records that are inherently created as the result of certain types of interactions with the product (e.g. the average amount of credit card purchases)
• Customer Feedback: Direct insights from users obtained through surveys, field studies, polls, and submissions, offering qualitative feedback on user satisfaction and areas for improvement.

External factors such as shifts in market dynamics, changes in customer behavior, and the evolution of competitive products also must be continuously monitored alongside internal performance metrics. Market disruptions, emerging technologies, regulatory changes, and competitor innovations can all impact the relevance and effectiveness of a product. By integrating this external awareness into the evaluation process, product teams can proactively adapt strategies, refine their roadmap, and ensure their product remains valuable to users while maintaining a competitive edge.

Discovery:

Similar and Related Names: Ideation, Research, Visioning, Planning

This is where the product manager plays a critical role by managing a wide range of possibilities, from what could potentially be built as a product or feature to what should be built, and then shepherding the process forward. Discovery often demands the most effort from the product manager and requires active collaboration with various teams and roles. The outcome of discovery is the clear definition of a deliverable, whether it’s a new product, a new feature, or a change to an existing one.

The catalyst for this process can include several types of intakes, which may originate from stakeholder input, evaluation processes, or the product manager:

• Problem or Opportunity: Identified by the product manager, stakeholders, customers, or others.
• Feature Request: Asking for a new or modified feature from customers, stakeholders, or others.
• Idea: An innovative concept for a feature from any source.

Ideally, the process starts with a well-defined problem or opportunity for improvement. If a specific solution is requested, the product manager must take a step back to understand why that feature was proposed, specifically, the problem it aims to solve or the benefit it intends to deliver. Additionally, some ideas might require research to validate their potential.

It is important to distill all intakes for discovery into a clearly defined problem or opportunity. This ensures that any proposed solution addresses the root cause, aligns with the vision and strategy, and facilitates impact assessment. Removing any bias toward any prescribed solution can foster greater creativity and innovation, potentially leading to a superior outcome.

At the heart of discovery is roadmap management—a core responsibility of the product manager. They must track all intakes and related information, which is why using a tool designed for roadmap management is beneficial. Roadmaps also provide transparency to stakeholders about what could eventually become a deliverable as it progresses through the discovery process:

1. Vetting of Intakes: An initial review to ensure that submissions meet the minimum criteria for further consideration.
2. Assessing Potential Solutions: Researching the technical feasibility, usability, and business viability of potential deliverables.
3. Planning for Delivery: Preparing the work required to transform a validated intake into a deliverable.

Each of these stages may require varying degrees of effort and collaboration with other roles and cross-functional teams—and they are often executed in parallel workstreams.

Vetting of Intakes:

Initial reviews ensure that each intake is worthy of further consideration. At a high level, intakes must align with the product strategy while also offering or improving the product’s value and usability, all while being both feasible and viable. Some product managers even develop a framework, such as a rubric, to objectively evaluate these intakes.

Assessing Potential Solutions:

During this phase, research is conducted to evaluate the technical feasibility, usability, and business viability of potential solutions.

During discovery, it is essential to first understand the user journey, which is a visual representation or “map” of the user experience with the product and its related interactions, often referred to as the user story. For a new product, mapping this journey can be a substantial undertaking that lays the groundwork for subsequent product development. Similarly, when exploring a new or modified feature, it is important to understand its story and how it fits into the larger picture. Various techniques, such as user story mapping, customer journey mapping, or empathy mapping, can be used for this part of the discovery process.

Regardless of the method chosen, the product manager must ensure that the user journey is thoroughly defined, documented, and integrated into the discovery process. This feeds into the exploration of potential solutions using one or more of the following:

• Wireframes: Renderings of screens that illustrate how the user experience might work. Higher-fidelity versions, often called visual designs, may be shared with the engineering team if the solution is to be built.
• Prototypes: Typically clickable mockups that simulate the functionality of a product or feature. Like wireframes, these can be included as part of the deliverable’s definition.
• Proofs of Concept (POCs): Functional prototypes used to evaluate a solution’s technical feasibility and usability. POCs are particularly valuable when a new technical implementation is being considered, as they can also help estimate development effort and costs (e.g. hosting, licensing).

Usability studies may be conducted using mockups or prototypes to refine the design and ensure the best possible user experience. This proactive approach can help avoid costly usability issues during development, thereby speeding up time to market.

Note that the usability studies described above differ from those conducted through production environment experimentation. That is a topic to be covered in a future article.

Planning for Delivery:

Upon deciding what should get delivered, the product manager prepares to move it into the delivery phase. Depending on the organization’s practices, this may take the form of a Product Requirements Document (PRD), or stories/epics within an Agile Scrum framework. At a minimum, the necessary requirements for building the solution are documented by the Product Manager. Additionally, stakeholders may be informed about the planning and start to involve those that are impacted or will play a part in the eventual launch.

Delivery:

Similar and Related Names: Development, Build and Deployment, Engineering and Release, “Build, Test & Launch”

Having worked through the discovery process, the product manager will partner closely with the engineering team to build and deploy the deliverable that involves the following steps:

• Building: Engineering designs and builds the product or feature changes with support from the product manager to answer questions and provide feedback as needed.
• Acceptance and Testing: Deliverables are thoroughly reviewed by the product manager along with testing and quality assurance.
• Launch: Final preparations and deployment of a product or changes to production.

Building:

During the building phase, the engineering team takes the lead in designing and developing the deliverable consistent with the methodology of their choosing – most often agile Scrum. Initially, the engineering team may require that the product manager provide clarifications about the needed deliverable. Then starting with design, they will leverage the findings or assets from discovery (such as wireframes, visual designs, and prototypes), to decide on the way to architect and build the deliverable, and address any technical dependencies (such as integrating with other systems).

Note that in agile Scrum, there is a role of the Product Owner, for which the responsibilities are a subset of those of a Product Manager. It is very common for a Product Manager to also be a Product Owner (as a combined role), but may be separate roles for which the reciprocal would not apply.

Acceptance and Testing:

Upon completing the work to build a deliverable, it will be thoroughly reviewed by the product manager to ensure it satisfies all of the requirements. Stakeholders and other impacted parties may become involved for awareness and a final opportunity to address anything prior to the launch. Sometimes, there may need to be rework on the deliverable or even a decision to not launch a deliverable – a situation that can be handled in a variety of ways that need to be led by the product manager working in close collaboration with the appropriate parties.

Throughout the process of building, deliverables will be periodically tested according to the engineering team’s established practices, including automated unit tests and code reviews. Prior to launch, all deliverables will undergo more comprehensive testing to meet the highest standards of reliability, scalability, and performance:

• Progression Tests: To verify the correct implementation of new or changed feature(s).
• Regression Tests: To identify any problems introduced by the new deliverable on other features.
• Stress Tests: To evaluate system performance under extreme conditions, such as high traffic.

Launch:

After a deliverable is accepted and tested, it is ready to be deployed into production. The engineering team is responsible for deployments, which may also be referred to as release management. A release involves pushing one or more deliverables (sometimes collectively called a “package”) into production, making them “live.” There are various models for release management that determine the timing and frequency of releases. The contents of a release and its deployment schedule will be openly shared by the engineering team and will involve the product owner to make adjustments as needed.

In advance of the launch, any related preparations should be made, which may need to start long before the launch, depending on their scope and impact. For example, if the release is tied to changes in product pricing, Marketing and Sales would need to be involved in planning soon after the deliverable is defined, if not sooner. Similarly, if a new or changed feature affects certain business operations, the affected organizations and leaders should participate in planning for the launch and any post-launch efforts. For this reason, the role of the Delivery Manager is critical in launches. Additionally, standard procedures, such as creating and communicating release notes, will involve the Product Manager.

After a launch, the engineering team typically has a process for ensuring its success. For certain releases, additional post-launch activities may be necessary, such as providing extra support or monitoring to more quickly identify and address any problems. After all launches, metrics related to the expected outcomes should be measured and incorporated into the ongoing evaluation process.