From Project to Product: Reflections on Value Stream Management and Agile Challenges

Background

In August 2022, after two years at a manufacturing company, the author introduced Scrum for agile project management and achieved some success, but soon faced a series of problems: project managers lacked end‑to‑end process monitoring tools, product management could not clearly assess value or calculate ROI, developers spent excessive time on self‑testing, issue fixing and releases, testing remained manual and inefficient, and it was hard to distinguish valuable requirements from pseudo‑requirements.

The author now oversees ten project managers, ten project teams, and more than ten software products within a near‑hundred‑person organization still operating under Scrum, which feels like a shell without true agility.

Seeking a breakthrough, the author turned to DevOps and read the book Project to Product , which deepened the understanding of management and value flow.

Key Insights from the Book

The book presents a single case study of a BMW factory visit, using it to contrast project‑based and product‑based thinking and to define the concept of a value stream framework.

Three disruptive trends of digital transformation are identified:

Infrastructure disruption – changing how customers obtain products or services.

Operating‑model disruption – using software to reshape the relationship between consumers and enterprises.

Business‑model disruption – leveraging software and technology for fundamental business changes.

From these trends, three realizations about software emerge:

When software architecture is detached from the value stream, productivity declines as scale grows, leading to waste.

Misaligned value streams become bottlenecks, often caused by misusing project‑management models.

Software value streams are complex collaborative networks that must align with the product.

The author relates these realizations to the current challenges, recognizing that the organization is stuck in all three.

Value Stream Framework

The framework consists of four layers:

Tool network – connects design, creation, release, and operations; measured by a “connection index”.

Artifact network – links activities to build an activity model; measured by a “traceability index”.

Value‑stream network – connects value to build a product model; measured by an “alignment index”.

Value‑stream metrics – eight metrics covering flow (speed, efficiency, time, load) and business outcomes (value, cost, quality, happiness), with sub‑distributions for features, defects, risks, and technical debt.

Four types of flow items are defined, each representing a unit of value pulled by stakeholders.

Flow indicators measure each value stream, linking software production metrics to business results.

Business‑outcome metrics are illustrated as follows:

The framework promises four main benefits:

Real‑time visibility of end‑to‑end business value flow.

Immediate identification of bottlenecks to prioritize investment.

Data‑driven validation of hypotheses for each value stream.

Organizational redesign to maximize value‑stream efficiency.

While traditional frameworks like Waterfall, Scrum, SAFe, and DevOps focus heavily on technology, the value‑stream framework bridges business language and technical execution, extending DevOps principles of flow, feedback, and continuous learning across the entire organization.

Personal Reflections

The author compares project‑centric and product‑centric modes, noting that pure project management often leads to scope creep, uncontrolled costs, and a lack of measurable outcomes. A hybrid approach—using PMP‑style project governance combined with iterative product‑focused delivery—can align milestones with product value while still handling non‑core requests.

Business‑IT misalignment is highlighted as a major obstacle; the author describes two real‑world models: (A) business designs the product and hands it to IT, and (B) embedding dedicated IT staff within business units. Both have trade‑offs, especially in a complex, non‑standard manufacturing environment.

To improve transparency, the author proposes tracking key flow items such as feature waiting time, design time, development time, and delivery time, arguing that without such metrics, management lacks confidence and cannot drive effective digital transformation.

In summary, the book and the author’s experience suggest that moving from a project‑based to a product‑based mindset, supported by a value‑stream framework and concrete flow metrics, is essential for achieving high‑performance, business‑aligned software delivery.