Digital product management and the product and service lifecycle

Lesson 1 argued that digital products are never finished. This lesson looks at how organizations manage them: who owns a product, how decisions about it are made, how it moves through its life from an idea to retirement, and how it is funded. It uses the eight-activity product and service lifecycle described in published summaries of ITIL (Version 5) and connects it to the value chain from ITIL-130.

The running example is Larchmont Connect, the new booking and tracking offering. In January Larchmont created a product team for it, led by Amara Okoye, the new head of digital products, with a product manager, a designer, six engineers, a data analyst and a service owner from LTS operations. Their brief is to raise online bookings from 38 % to 75 % within three years.

What product management is

Product management is the discipline of deciding what a product should do and why, and of guiding it through its life so that it keeps delivering value. A product manager is accountable for the product's outcomes: who it serves, what problems it solves, how success is measured and what gets built next. Product management sits between three areas: the customer and the market (what is needed and valued), technology (what is feasible) and the business (what is viable and fits the strategy).

Product management differs from project management. A project manager delivers a defined scope within time and budget and then closes the project. A product manager has no end date; the job is to keep making the product more valuable. In practice the two often coexist: a product team may run a time-boxed project to integrate a new partner, inside a product that continues indefinitely.

The service owner role deserves attention. In some digital organizations, operations are an afterthought and the product team discovers support needs only after launch. Larchmont put a service owner inside the team from day one, so that support, monitoring, continuity and supplier contracts are designed alongside features. This is the practical meaning of 'you build it, you run it' combined with service management discipline.

The product and service lifecycle

ITIL (Version 5) describes a product and service lifecycle with eight activities: discover, design, acquire, build, transition, operate, deliver and support. The activities are not strict phases; a mature product team performs all of them continuously, for different features at the same time. They are a checklist of the kinds of work a product needs over its life.

In Version 5 the lifecycle is the value chain. It replaces the six ITIL 4 value chain activities from ITIL-130 (plan, improve, engage, design and transition, obtain/build, deliver and support), and its eight activities combine into value streams in the same way. Plan moves up into governance and direction setting, and improve moves into the continual improvement component, so neither appears in the lifecycle. Engage is spread across discover, deliver and support. The other three ITIL 4 activities split: design and transition into design and transition, obtain/build into acquire and build, and deliver and support into operate, deliver and support, with operate as a new activity for running live services. The table shows where each lifecycle activity's work sat in ITIL 4, which helps when moving between materials written for the two editions.

The joins between activities matter most. Handoffs from build to transition, or from transition to operate, are where defects, misunderstandings and delays concentrate. Persistent product teams reduce handoffs because the same people carry a feature from discovery to support, and they learn directly from what happens in operation.

Discovery: finding problems worth solving

Discovery is where many digital products succeed or fail. Teams that skip it build features nobody needs; teams that do it well find the few changes that move outcomes. Discovery methods include customer interviews, observation of users at work, analysis of support tickets and usage data, journey mapping, competitor analysis and quick experiments such as prototypes and 'fake door' tests that measure interest before building.

A useful frame is to test four risks before building: value risk (will customers use it or pay for it?), usability risk (can they figure out how to use it?), feasibility risk (can we build and run it with our technology and skills?) and viability risk (does it work for the business, including legal, financial and operational constraints?). Service management contributes heavily to feasibility and viability: support costs, continuity, security, supplier dependencies and regulatory obligations are all part of whether an idea is viable.

Support data is one of the richest and most neglected discovery sources. Larchmont's service desk logged 4,300 contacts about bookings last year. When the product team grouped them, 38 % were customers phoning to confirm that an online booking had actually been received, a problem invisible in the portal's own analytics. A simple confirmation message with a pickup window became the team's first release.

Roadmaps, backlogs and outcomes

A product roadmap communicates direction: the outcomes the team is pursuing over the next quarters and the broad themes of work. Good roadmaps are organized around problems and outcomes ('make booking a repeat shipment take under a minute') rather than a fixed list of features with dates, because discovery will change the features. A product backlog is the ordered list of work the team will do next, kept detailed at the top and rough further down.

Outcomes are expressed with measures that matter to customers and the business. Many product teams use objectives and key results (OKRs), which ITIL-120 introduced. For Larchmont Connect, one quarter's objective was 'make repeat booking effortless', with key results of raising the share of repeat bookings made online from 41 % to 55 %, cutting median repeat-booking time from 9 to 3 minutes, and keeping the booking-related contact rate below 4 % of bookings.

Outputs (features shipped) are still tracked, but they are not the goal. A team that ships ten features and moves no key results has not succeeded; a team that ships two small changes and doubles repeat bookings has. This shift in what counts as success is one of the hardest cultural changes for organizations used to project reporting.

Funding products instead of projects

Traditional IT funding approves projects one at a time: a business case, a fixed budget, a delivery team assembled for the duration, then closure. This works poorly for digital products. Each new idea waits for an annual budget cycle, teams are rebuilt repeatedly and lose knowledge, and nobody is funded to run and improve the product after launch.

Product-based funding allocates a budget to a persistent team or group of teams for a period, often a year, reviewed quarterly against outcomes. The team decides, within guardrails, which work delivers the most value. Some organizations call this lean portfolio management or capacity-based funding. Governance shifts from approving individual projects to setting strategy, allocating capacity among products and checking outcomes.

# Compare project funding and persistent-team funding over three years
# Invented figures for Larchmont Connect.
team_cost_per_year = 1_450_000          # 11 people plus tools
project_overhead = 0.18                # ramp-up, handover and re-staffing per project
projects = [("portal rebuild", 0.9), ("pickup windows", 0.4), ("payments", 0.5),
            ("API for large shippers", 0.6), ("mobile app", 0.7)]   # team-years of work

project_cost = sum(years * team_cost_per_year * (1 + project_overhead) for _, years in projects)
wait_days = 45 * (len(projects) - 1)    # assume a 45-day approval gap between projects
persistent_years = sum(y for _, y in projects)
persistent_cost = persistent_years * team_cost_per_year

print(f"work required: {persistent_years:.1f} team-years")
print(f"project model: ${project_cost:,.0f}, plus about {wait_days} days of approval gaps")
print(f"persistent team: ${persistent_cost:,.0f}, no approval gaps between pieces of work")
print(f"difference: ${project_cost - persistent_cost:,.0f} ({(project_cost / persistent_cost - 1) * 100:.0f} % more under projects)")

work required: 3.1 team-years
project model: $5,304,100, plus about 180 days of approval gaps
persistent team: $4,495,000, no approval gaps between pieces of work
difference: $809,100 (18 % more under projects)

The numbers are invented and the overhead assumption is a judgment, but the pattern is common: repeated ramp-up and handover cost real money, and gaps between approvals delay value. The trade-off is control. Persistent funding gives teams more autonomy, so leaders need good outcome measures and regular reviews to be confident the money is well spent.

Portfolios: many products, limited capacity

Larchmont will not have one product team; it will have several, for customer booking, warehouse operations, transport planning, finance systems and internal platforms. Portfolio management decides how capacity is split among them. ITIL-130 showed how to prioritize demand within capacity; at portfolio level, the same ideas apply to teams and budgets.

A practical portfolio view lists each product with its strategic objective, current outcome measures, funding, team size, technical health and risk. Leaders review it quarterly and shift capacity toward products with the most strategic value or the biggest problems. Products that no longer earn their keep are candidates for retirement, which brings us to the end of the lifecycle.

Retiring products

Every product eventually loses its value: customers move on, technology ages, or a better product replaces it. Retirement is part of the lifecycle and is often handled badly. Old systems linger because nobody owns the decision, they still have a few users, or data is trapped in them. Each lingering system costs licences, infrastructure, security patching and attention.

A deliberate retirement plan identifies remaining users and their needs, migrates or archives data in line with retention rules, updates the service catalogue and agreements, decommissions infrastructure and licences, and communicates clearly. Larchmont's 2019 portal will be retired twelve months after Larchmont Connect reaches feature parity, with customers moved in waves and old booking history archived for seven years.

Retention rules for Larchmont's Canadian records include tax and accounting records, which the Canada Revenue Agency generally expects to be kept for six years from the end of the last tax year they relate to, and personal information, which PIPEDA requires to be kept only as long as needed for the identified purposes and then destroyed or anonymized. Archiving booking history therefore needs both a minimum and a maximum.

Product management and ITIL practices

Several ITIL practices change shape inside a product model. Portfolio management becomes the allocation of capacity among products. Business analysis becomes continuous discovery inside teams. Service design becomes product and experience design that includes support. Service catalogue management describes products and offerings in customer language. Service financial management tracks the cost and value of products rather than projects. The practices still exist, but much of the work is done by product teams, with central functions setting standards and providing expertise.

This creates a design question every organization must answer: what stays central and what moves into teams? Larchmont's answer, for now, is that product teams own discovery, design, build, transition and day-to-day support of their products, while central LTS functions own enterprise architecture, security standards, major incident coordination, supplier contracts above a threshold, and the shared platforms described in lesson 5.