Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle. To do this, they collaborate with a wide range of people to identify and define customer needs, understand the Solution Context, and develop the Program Vision, Roadmap, and Features required to meet these needs. Then, they support the Agile Release Trains (ARTs) in delivering value through the Program Kanban and Continuous Delivery Pipeline. This article describes the roles that Product Management play in SAFe. The role scales in relation to the complexity of a solution: some solutions may only need a single Product Manager while others will need a team.
Details Effective product management is driven by a customer-centric mindset in which the customer is placed at the center of every decision. Supported by the tools and techniques of Design Thinking, this mindset focuses the entire organization on creating desirable, viable, feasible, and sustainable solutions. Internal vs. External Customers Product management begins with a clear definition of the customer. Customers are the ultimate buyer of every Solution. They are an integral part of the Lean-Agile development process, heavily influence both the Operational Value Streams and Development Value Streams, and have specific responsibilities in SAFe. SAFe defines two kinds of customers: Internal and External. Each is described next. Internal customers are part of the enterprise. An example would be the manager of a bank’s credit underwriting function who uses an internal credit scoring solution created by the internal IT department. Because internal solutions often support many operational value streams, there may be several internal product managers (Figure 1). Figure 1. Internal Product Managers External customers are outside the enterprise. The relationship between the enterprise and external customers takes many forms: Business-to-Business (B2B), such as an enterprise software vendor providing a payroll solution Business-to-Professional (B2P), such as a software vendor who sells graphic design tools to marketing professionals Business-to-Consumer (B2C), such as a software vendor that sells home design tools to homeowners As illustrated in Figure 2,the relationships of product managers to their customers vary based on the structure of the operational and development value streams. It is common for internal and external product managers to work together in developing the total solution. As described in the customer-centricity article, market research informs the customer relationship. Figure 2. Teams of Product Managers working together to create a solution Some Product Managers are responsible for solutions in which the customer is the direct buyer of the solution, as Figure 3 illustrates. In this case, the development value stream and the operational value stream are one and the same. The solution can be a final product that’s sold or deployed directly. In other cases, the solution may need to be embedded into a broader solution context, such as a system of systems. Figure 3.External customers who are direct buyers of a solution Responsibilities of Product Management The primary responsibilities of product management fall into four main areas (Figure 4): Meet business goals – Products and solutions must meet the economic business goals established by the portfolio Get it built – Product Managers collaborate with Agile Release Trains (ARTs) and Solution Trains to build the required functionality Get it off the shelf – Internally, Product Managers collaborate with IT to ensure solutions are deployed to internal customers and users; externally, Product Managers collaborate with an even larger set of business stakeholders to deliver products to the market Leverage support – Product Managers ensure their offerings are supported and enhanced to create a continuous flow of value Figure 4.Product management responsibilities Each of these is described further below. Extended responsibilities associated with external product managers and Solution Trains are described later. Meet Business Goals An economically sustainable product creates more value than it costs. However, although costs are relatively straightforward to measure, there’s more variation in how an enterprise assesses value. Consider: A for-profit enterprise might focus on revenue, market share, or profit A government might evaluate how well it services citizens, such as providing clean water or functional roads A nonprofit may assess how many people are served when providing disaster relief or other humanitarian services Product management is responsible for ensuring that development value streams are creating feasible and sustainable products and solutions.This encompasses: Developing a clear model of how the solution provides value to customers Understanding the cost structure and in-license models of all components and suppliers Creating any necessary pricing or revenue-generating elements and out-licensing models Developing customer-centric ROI models that align with the value provided Product management maintains and updates these models over the product-market lifecycle and in response to changing portfolio demands. For example, product management is responsible for managing changes to the product vision or roadmap based on the portfolio’s Strategic Themes. Product management is also responsible for maintaining alignment with the portfolio canvas, Lean Budgets, and Guardrails. Product managers, who often play the role of an Epic Owner,will develop and manage the Lean Business Case for Epics that affect their ART. Get it Built The bulk of product management responsibilities support the ARTs in delivering value to customers. These include: Understand customer needs – As the internal representative of the customer, product management leverages market research and Continuous Exploration to continually understand customer and market needs. Design thinking tools, ranging from personas, empathy maps, journey maps, and story maps are used to communicate these to the ARTs. Ensure product completeness – Product management is responsible for ensuring the product is considered ‘whole and complete’ from a defined customer’s perspective. Products that serve multiple market segments may have different considerations of ‘whole and complete’.Develop and communicate the program vision and roadmap – Product management continuously develops and communicates the vision to the Agile Teams, while defining the features of the system. Collaborating with System Architect/Engineering, they also define and maintain the Nonfunctional Requirements (NFRs) to ensure that the solution meets relevant standards and other system quality requirements. They are responsible for the roadmap, which illustrates how features are intended to be implemented over time. Manage and prioritize the flow of work – Product management supports the flow of work through the program Kanban and into the program backlog, responsible for ensuring enough features are ready in the backlog at all times. Because judicious selection and sequencing of features is a key economic driver for each ART,the backlog is reprioritized with Weighted Short Job First (WSJF) before each Program Increment (PI) Planning session. Participate in PI planning – During each PI planning session, Product Management presents the vision, which highlights the proposed features of the solution, along with any relevant upcoming Milestones. Typically, they also participate as the train’s Business Owners, responsible for approving PI Objectives and establishing business value. Define releases and program increments – Owning the ‘what’ means that product management is primarily responsible for release definition as well, including new features, architecture, and allocations for technical debt. This is accomplished through a series of Program Increments and releases, whose definition and business objectives are also determined by product management.Work with System Architect/Engineering to understand Enabler work – While Product Management is not expected to drive technological decisions, they are expected to understand the scope of upcoming enabler work. They collaborate with System and Solution Architect/Engineering to jointly sequence the Architectural Runway that will host new business functionality. This is typically done by establishing a capacity allocation, as described in the Guardrails article. Participate in demos and Inspect and Adapt (I&A) – Product Management is an active participant in biweekly System Demos, including the aggregate one at the end of the PI. They also participate in assessing metrics, including the evaluation of business value achieved versus planned, and are active participants in the Inspect and Adapt workshop.Get it off the Shelf Product management leverages the Continuous Delivery Pipeline to deliver value far more frequently than with traditional processes. Depending on the customer, this can range from releasing new functionality multiple times per day, weekly, monthly, or any time frame that balances market demands with the goals of the enterprise One tension that exists in releasing value more frequently is ensuring that all internal and external stakeholders are prepared to receive and utilize this value. To ensure that customers receive the full value of the release, product management must also provide: Marketing and sales enablement – External product managers ensure that marketing and sales have the information they need to communicate value and execute against the sales objectives.This includes regular meetings with marketing and sales to help them understand the magnitude of the value being released and how it may impact their activities. Note that at times external product releases may be coordinated with marketing and sales milestones (such as a conference) to maximize sales. Channel enablement – Complex solutions often have similarly complex distribution models. These can range from Original Equipment Manufacturers (OEMs), Value-Added Resellers (VARs), and Managed Service Providers (MSPs), to other forms of distribution partners. Product Management is responsible for ensuring that the full distribution channel is enabled in every release. Service Partner enablement – Service partners are a unique channel that contributes to the creation of a complete solution for a target customer. For example,service partners often install, configure, and train customers on behalf of independent software vendors (ISVs). Customer-centric practices helps product management determine the right distribution of responsibilities between service partners and the ISV. Leverage Support Product management ensures that products and solutions are supported through their operational lifecycle. This includes: Collaborating with customer experience and support – While customer-centric enterprises seek to create positive customer experiences, the implementation of customer experience and product support practices varies considerably based on the product. A B2C offering may only provide email support, while a B2B offering may provide a wide range of dedicated support options.Product management is responsible for working with customer experience and support professionals to design the right offerings. Once designed, product management is responsible for helping customer experience and support manage these offerings, including creating features designed to improve support functions. Manage supported versions – Customers of complex solutions have a right to know how long they will be supported once deployed in production. Therefore, product management is responsible for defining support policies, including End-of-Life (EOL). Manage legal and compliance – Product management is responsible for working with legal and compliance professionals to ensure the product meets all necessary requirements. Managing the Product Lifecycle and Technology Adoption Curve Every product progresses through predictable stages:introduction to growth, growth to maturity, and maturity to decline. This sequence is known as the product lifecycle (Figure 5): Figure 5. Product lifecycle Product management is responsible for guiding their product through each of these stages. Note that different products can be in different stages for quite different durations. Consider, for example, the credit scoring solution described earlier in Figure 1. Once introduced, the growth (adoption) of the credit scoring solution might be extremely rapid. The mature stage might last for more than a decade, with the bank continuing to enhance the solution to maintain a unique competitive advantage. These enhancements, such as new features or capabilities, follow a similar S-shaped curve know as the technology adoption curve. This curve explains how specific features,capabilities and products are adopted in a given market. The adoption is predictable and can be described by psychographic attributes of customers (Figure 6): Innovators embrace new and novel technologies. They represent the smallest portion of the total market. Early Adopters are quick to understand the benefits of new technology and gain value by moving more quickly than the rest of the market. Early Majority are more practically minded, often waiting until products are more proven. Late Majority wait for a product to become well established, often delaying their purchase until established enterprises with whom they already have a relationship offer a version of the product. Laggards represent the tail end of the adoption curve. Note that these profiles do not apply to every product:a customer facing an urgent problem may be an early adopter of one product while acting as a laggard for less urgent problems. In Crossing the Chasm, technology pioneer Geoffrey Moore observed that many technology products face a “chasm” between the expectations of early adopters and the rest of the market. Accordingly, product management is responsible for understanding where each product may exist on the adoption curve and for adjusting the mix of Features accordingly. For example, a product that is in the Early Adopters stage may place greater emphasis on Features that promote continued growth, while a product in the Laggards stage may place greater emphasis on Features that lower operational costs. Figure 6.Patterns of technology adoption Product Management’s Participation in Solution Trains For teams building large solutions that require multiple ARTs, Product Management has additional responsibilities participating with Solution Management as part of the Solution Train: Collaborate with Solution Management – Solution Management focuses on capabilities, and product managers focus on features. Because refining and splitting capabilities into features, managing Nonfunctional Requirements (NFRs), and creating the Architectural Runway are collaborative activities, they must be done as a group. Participate in Pre- and Post-PI Planning – Product Management also participates in the Pre-PI planning event, working with the Solution Train stakeholders to define the inputs, milestones, and high-level objectives for the upcoming PI planning session.In the Post-PI planning session, Product Management helps summarize findings into an agreed-to set of solution PI objectives. Participate in the Solution Demo – Product Management participates in the solution demo, often demonstrating the capabilities that their ART has contributed and reviewing the contributions of the other ARTs, always with a systems view and always with an eye toward fitness of purpose.
Credit: © Scaled Agile, Inc.
What is DevOps?
DevOps definition
A compound of development (Dev) and operations (Ops), DevOps is the union of people, process, and technology to continually provide value to customers.
What does DevOps mean for teams? DevOps enables formerly siloed roles—development, IT operations, quality engineering, and security—to coordinate and collaborate to produce better, more reliable products. By adopting a DevOps culture along with DevOps practices and tools, teams gain the ability to better respond to customer needs, increase confidence in the applications they build, and achieve business goals faster.
The benefits of DevOps
Teams that adopt DevOps culture, practices, and tools become high-performing, building better products faster for greater customer satisfaction. This improved collaboration and productivity is also integral to achieving business goals like these:
DevOps and the application lifecycle
DevOps influences the application lifecycle throughout its plan, develop, deliver, and operate phases. Each phase relies on the others, and the phases are not role-specific. In a true DevOps culture, each role is involved in each phase to some extent.

Plan
In the plan phase, DevOps teams ideate, define, and describe features and capabilities of the applications and systems they are building. They track progress at low and high levels of granularity—from single-product tasks to tasks that span portfolios of multiple products. Creating backlogs, tracking bugs, managing agile software development with Scrum, using Kanban boards, and visualizing progress with dashboards are some of the ways DevOps teams plan with agility and visibility.
Develop
The develop phase includes all aspects of coding—writing, testing, reviewing, and the integration of code by team members—as well as building that code into build artifacts that can be deployed into various environments. DevOps teams seek to innovate rapidly without sacrificing quality, stability, and productivity. To do that, they use highly productive tools, automate mundane and manual steps, and iterate in small increments through automated testing and continuous integration.
Deliver
Delivery is the process of deploying applications into production environments in a consistent and reliable way. The deliver phase also includes deploying and configuring the fully governed foundational infrastructure that makes up those environments.
In the deliver phase, teams define a release management process with clear manual approval stages. They also set automated gates that move applications between stages until they’re made available to customers. Automating these processes makes them scalable, repeatable, controlled. This way, teams who practice DevOps can deliver frequently with ease, confidence, and peace of mind.
Operate
The operate phase involves maintaining, monitoring, and troubleshooting applications in production environments. In adopting DevOps practices, teams work to ensure system reliability, high availability, and aim for zero downtime while reinforcing security and governance. DevOps teams seek to identify issues before they affect the customer experience and mitigate issues quickly when they do occur. Maintaining this vigilance requires rich telemetry, actionable alerting, and full visibility into applications and the underlying system.
DevOps culture
While adopting DevOps practices automates and optimizes processes through technology, it all starts with the culture inside the organization—and the people who play a part in it. The challenge of cultivating a DevOps culture requires deep changes in the way people work and collaborate. But when organizations commit to a DevOps culture, they can create the environment for high-performing teams to develop.
DevOps culture
While adopting DevOps practices automates and optimizes processes through technology, it all starts with the culture inside the organization—and the people who play a part in it. The challenge of cultivating a DevOps culture requires deep changes in the way people work and collaborate. But when organizations commit to a DevOps culture, they can create the environment for high-performing teams to develop.
Collaboration, visibility, and alignment
One hallmark of a healthy DevOps culture is collaboration between teams, which starts with visibility. Different teams such as development and IT operations must share their DevOps processes, priorities, and concerns with each other. These teams must also plan work together as well as align on goals and measures of success as they relate to the business.
Shifts in scope and accountability
As teams align, they take ownership and become involved in additional lifecycle phases—not just the ones central to their roles. For example, developers become accountable not only to the innovation and quality established in the develop phase, but also to the performance and stability their changes bring in the operate phase. At the same time, IT operators are sure to include governance, security, and compliance in the plan and develop phase.
Shorter release cycles
DevOps teams remain agile by releasing software in short cycles. Shorter release cycles make planning and risk management easier since progress is incremental, which also reduces the impact on system stability. Shortening the release cycle also allows organizations to adapt and react to evolving customer needs and competitive pressure.
Continuous learning
High-performing DevOps teams establish a growth mindset. They fail fast and incorporate learnings into their processes, continually improving, increasing customer satisfaction, and accelerating innovation and market adaptability. DevOps is a journey, so there is always room to grow.
DevOps practices
Beyond establishing a DevOps culture, teams bring DevOps to life by implementing certain practices throughout the application lifecycle. Some of these practices help accelerate, automate, and improve a specific phase. Others span several phases, helping teams create seamless processes that help improve productivity.
- Continuous integration and continuous delivery (CI/CD)
- Version Control
- Agile software development
- Infrastructure as code
- Configuration management
- Continuous monitoring
Continuous integration and continuous delivery (CI/CD)
Configuration management refers to managing the state of resources in a system including servers, virtual machines, and databases. Using configuration management tools, teams can roll out changes in a controlled, systematic way, reducing the risks of modifying system configuration. Teams use configuration management tools to track system state and help avoid configuration drift, which is how a system resource’s configuration deviates over time from the desired state defined for it.
Practiced in conjunction with infrastructure as code, both system definition and configuration are easy to templatize and automate, helping teams operate complex environments at scale.