• Skip to primary navigation
  • Skip to main content
Rethink Your Understanding

Rethink Your Understanding

Transforming Software Delivery

  • Home
  • Practices and Mission
  • Collaboration
  • AI
  • Posts
  • Podcast
  • Endorsements
  • Resources
  • Contact

Metrics

Avoiding Flow Metric Confusion: Aligning Agile Work Hierarchy to Flow Items

February 17, 2025 by philc

10 min read

Adopting Flow Metrics without understanding Value Stream Management, Flow Items, and the Agile Work Hierarchy can create confusion and misalignment. Connecting Agile work to Flow Items becomes challenging without this foundation, making it harder to measure and improve value flow. This article simplifies these concepts to help teams and leaders align Agile work with Flow Metrics, enabling better visibility and greater efficiency.

A common issue I’ve noticed is misinterpreting Agile work elements when modeling Flow Items. Many organizations don’t fully understand or follow the standard Agile Work Hierarchy.

This article aims to guide leaders in understanding and applying a framework to align Flow Items while exploring essential Value Stream concepts. Drawing from my experience, I’ve crafted this guide to simplify and make these topics more accessible. I hope it will provide valuable insights and practical tools for others navigating similar challenges.

Misunderstanding Resulting in Confusion

Recently, I observed a Technology division new to Flow Metrics trying to map their Jira Issue types to Flow Items. It was clear they didn’t have a solid understanding of the scope and context of a Flow Item. On top of that, multiple product and platform teams had the freedom to structure and manage their Jira instances however they wanted, with no effort to follow even basic industry guidelines. The teams had so many custom types that some members even argued tasks were deliverables, causing confusion between hierarchy levels and Flow Items.

Clearing the Murky Waters

I created the following Agile Work Hierarchy model to help teams standardize their project tracking tools, have a common language, and better align with Flow Items:

The Agile Work Hierarchy as commonly defined by industry standards

  1. Theme: At the top of the hierarchy, themes represent broad organizational goals or focus areas. They align teams and ensure all work supports overall business objectives.
  2. Initiative: A business objective made up of multiple epics working together to achieve a broader organizational goal or outcome.
  3. Epic: A large body of work that support the initiative and that can be divided into multiple features or user stories.
  4. Feature: A product function or characteristic that delivers value to the user. It typically originates from an epic and is further broken down into user stories.
  5. User Story: A simple, user-centric description of a requirement or request that explains a specific feature or function needed by the user.
  6. Task: A granular unit of work necessary to complete a user story. These are actionable steps assigned to team members.

“”Theme” isn’t an official Scrum term but is commonly used in Agile practices. Whether you view Themes and Initiatives as the same or different doesn’t impact the focus of this discussion. The key is to identify the right level of work items for Flow Metrics and Flow Items, regardless of naming conventions, to effectively map core work items in your practice.

The names used for work types in delivery tracking can vary depending on the platform or tools. For example, our teams have worked with two popular tools: Jira and Rally. Rally and Jira use different terms and structures for Agile work items and workflows, particularly in their terminology and hierarchy.

Rally

  • Initiatives/Epics: Rally uses Portfolio Items to represent high-level work, such as initiatives or epics, that align with strategic goals.
  • Features: These are essentially lower-level Portfolio Items used to group related user stories.
  • User Stories: Rally uses user stories as a key work item, aligned with Agile principles.
  • Tasks: These are smaller parts of user stories, breaking the work into more manageable steps.

Jira

  • Initiatives/Epics: Jira uses Epics for large bodies of work and supports an additional layer (e.g., Initiatives) with advanced roadmaps in premium plans.
  • Features: Jira doesn’t specifically label items as “features.” Instead, it often uses Epics or custom issue types to serve a similar purpose.
  • User Stories: User stories are tracked as Issues and can be customized with different fields and workflows.
  • Tasks: Tasks are a basic issue type in Jira, with sub-tasks available for more detailed tracking.

This post isn’t about recommending a specific labeling structure. It’s about understanding your work hierarchy to align your flow items with the smallest deliverable unit that adds value to your customer or organization.

We use an initiative-epic-user story-task hierarchy to structure work. Teams organize epics, which break down into smaller user stories. These stories are the main work items, mapped to flow items and represent the smallest units of value delivered to production and customers. Our process doesn’t include a feature layer.

Addressing Release Misconceptions

Another common misunderstanding I encountered in a different division was how Product Managers using Aha! defined their work hierarchy. They categorized the highest-level program element as a “Release.” However, a release is not a work item in the industry-standard hierarchy. It is a scheduled deployment of a set of features or functionalities to the customer. A release can include multiple features, which in turn contain user stories and tasks. Misusing this term can lead to confusion in workflow tracking and alignment across teams. You don’t need to change how you and your teams label your levels, but it’s important to have clear, aligned definitions to help identify Flow Items.

Flow Items in Flow Metrics

Flow Items In Project to Product, Dr. Mik Kersten defines Flow Items as the primary units of work that move through a software value stream. These items fall into four categories:

  • Features: New functionality delivering business value to the customer.
  • Defects: Work items addressing quality issues impacting the user experience.
  • Risks: Tasks focused on mitigating security, compliance, or governance concerns.
  • Debts: Efforts improving system health, such as code refactoring or infrastructure updates.

These categories ensure that all work flowing through a value stream is accounted for and measured effectively.1

Clarifying Flow Items in the Agile Work Hierarchy

In Agile methodologies, it’s common practice to decompose Epics, Features, and User Stories into the smallest units of work that can deliver value independently. For instance, teams often aim to deliver User Stories sized at three to five story points, ensuring each piece is manageable and valuable.

Drawing insights from Mik Kersten’s Project to Product and the concept of Flow Metrics, I define a Flow Item is the smallest unit of work that delivers meaningful value to the user or the business. Even if all other work stops, delivering this item will still result in a clear benefit. Whether your organization calls them Features or User Stories, the key is that each Flow Item must deliver value on its own.

An anti-pattern to be cautious of involves breaking down work into segments that when delivered individually, don’t provide standalone value. For example, delivering only the URL endpoint for an API without its functional components doesn’t offer immediate value to the customer. Such practices can lead to misleading metrics, suggesting progress where the end-user perceives none.

To align Flow Items correctly with Agile work elements, I created a version of the Agile Work Hierarchy that follows the industry naming guidelines and highlights Features as the Flow Items (or User Stories depending on your context). Remember Flow Items should be the smallest units of work that deliver value to customers.

In the Agile hierarchy I’ve outlined, a Flow Item most closely aligns with a Feature. While User Stories are smaller, detailed requirements that contribute to a Feature, the Flow Framework operates at a higher level, focusing on the delivery of Features as complete units of value. 1

or depending on your context

or how we manage work

The goal is to choose one approach and stick with it. The key is to have a clear, standardized unit of work. It’s crucial to ensure that teams fully understand your definitions and how your work items align with Flow Items.

Clarifying Value Streams, Stages, and Mapping

This article does not aim to provide an in-depth education on Value Streams, as there are many excellent resources available to help you and your teams explore Value Streams and Value Stream Mapping. However, adopting Flow Metrics without first investing in this foundational knowledge can lead to significant challenges. Organizations often struggle to define a Value Stream, understand its components, and connect these elements to mapping efforts. Common difficulties tend to arise in four key areas:

  1. The Scope or Definition of a Value Stream
    • A Value Stream represents the entire end-to-end process from concept to cash (or value realization) of a Product.
    • A Value Stream should cover the entire product or product portfolio, including all teams and team members involved.
  2. The Stages or Phases of a Value Stream
    • Many teams confuse operational execution tasks with high-level Value Stream stages.
    • The Value Stream Model is typically presented as a series of distinct stages: Discovery, Delivery, Operation, and Support. Each stage represents a critical phase in the process of creating and delivering value.
  3. The Steps That Are Used to Create a Value Stream Map
    • Value Stream Mapping involves breaking down high-level stages into steps that contribute to the flow of value.
    • Steps such as Backlog, Planning, Development, Testing, Deployment, and Verification help identify where value is added and where inefficiencies occur.
    • These steps are different from granular tasks, which are the specific processes carried out within each step.
  4. The Confusion Between a Value Stream Mapping Step and a Process Mapping
    • One of the most common mistakes teams make is treating process mapping as value stream mapping.
    • Value Stream Mapping involves outlining the steps within a stage or phase of the Value Stream to identify delays, bottlenecks, and inefficiencies.
    • Process Mapping, on the other hand, is about detailing the specific activities within each step, such as coding, pull requests, code review, CI build, etc.

By addressing these four areas of confusion, teams can better align their understanding of Value Streams, ensuring Flow Metrics are applied correctly and effectively measured.

Value Stream Model

Value Stream Mapping

Process Mapping

Conclusion

When Agile work structures and Flow Items aren’t aligned, inefficiencies make measuring and improving value delivery with Flow Metrics harder. Linking Flow Items to the correct agile work item improves data quality and decision-making. Using a structured approach and best practices helps businesses maximize Flow Metrics and deliver results.

Bonus: Team Level OKRs

(Excerpt from Breaking Free from the Build Trap, Dec 25, 2024.)

OKRs align the team’s work with customer needs and organizational objectives. This alignment transforms sprints, epics, and initiatives from mere tasks into measurable milestones that drive meaningful business results.

OKRs bridge the gap between your team’s efforts and the outcomes that truly matter, encouraging a focus on value rather than speed. This mindset shift fosters intentional work and delivers impactful results.

Team Level OKRs tend to be either Initiatives or Epics.

Teams should define sprint goals based on outcomes, not tasks. Example: “Enhance system performance by improving response times by 5%” (outcome) versus “Complete three refactoring tickets” (task).

To develop a team-level OKR from a parent key result, you can use a method known as explicit alignment or cascading. This process transforms a higher-level key result into a focused objective for your team, ensuring clear alignment and purpose. Here’s an effective way to approach it:

  1. Define your desired outcome and ensure it aligns with a relevant Parent Key Result:
    Begin by reviewing the overarching OKRs at the company or department level. Identify a key result that aligns with your team’s responsibilities and can be directly influenced within your team’s scope.
  2. Transform the Key Result into an Objective:
    Reframe the parent key result as a clear objective for your team (the expected outcome). This objective will serve as the central focus of their efforts.
  3. Develop Supporting Key Results:
    Create 3-5 key results to help your team achieve this new objective. These should be specific, measurable, and aligned with the overall goal or outcome.
  4. Ensure Alignment:
    Make sure your team’s OKRs align with and support the higher-level objective they are based on. Set clear targets for each key result by defining what success looks like for your team about the parent key result. This will help keep your team focused and guide their efforts toward achieving the desired outcome.

References

  1. Project to Product: What Flows Through a Software Value Stream?, November 9, 2018 By Mik Kersten, https://blog.planview.com/what-flows-through-a-software-value-stream/

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Filed Under: Agile, DevOps, Engineering, Leadership, Lean, Metrics, Product Delivery, Value Stream Management

Decoding the Metrics Maze: How Platform Marketing Fuels Confusion Between SEI, VSM, and Metrics

February 15, 2025 by philc

9 min read

A Landscape of Confusion

By 2025, the tech industry will be more data-driven than ever, with engineering teams and leaders relying on metrics-driven insights to improve software delivery performance. However, the rise of Software Engineering Intelligence (SEI) platforms, existing Value Stream Management (VSM) platforms, and engineering metrics solutions have created a new challenge: marketing confusion.

Platform vendors, eager to differentiate their offerings, often blur the lines between these categories, making it increasingly difficult for technology leaders to distinguish between tools designed for engineering visibility versus those aimed at full-value stream optimization. This confusion leads to misaligned expectations, ineffective investments, and ultimately, frustration when organizations realize they’ve purchased a solution that doesn’t align with their needs.

This article serves as a follow-up to my August 2024 article:

  • Navigating the Digital Product Workflow Metrics Landscape: From DORA to Comprehensive Value Stream Management Platform Solutions

Since that article, the landscape has continued to evolve. SEI platforms have gained significant momentum, the DX Core 4 framework has been introduced, and VSM platforms are still in the conversation but with a shifting narrative.

Derek Holt, CEO of Digital.ai, has observed what he believes to be a major industry shift:

“While Value Stream Management continued to lose steam in 2024, we also saw the fast emergence of Software Engineering Intelligence (SEI) to take its place.” – Derek Holt, CEO of Digital.ai (SD Times)

However, other experts argue that VSM remains critical for aligning technology with business outcomes. Heather Spring, a senior Product Marketing expert, highlights the enduring value of VSM:

“VSM is more than a process improvement tool. It’s a framework for achieving measurable business outcomes.” – Heather Spring, Broadcom ValueOps (Broadcom Academy)

These contrasting viewpoints contribute to a growing problem:

  • Senior leaders struggle to distinguish between practices and platforms.
  • Different tools claim to offer “the future of software measurement,” but many serve only a narrow scope.
  • Organizations risk making misinformed investments based on incomplete narratives.

My Perspective as of February 2025

This article represents my point of view, given the current state of these technologies in early 2025. Over the past few years, I’ve observed significant shifts in how software measurement platforms are marketed, adopted, and integrated into organizations.

Importantly, this article does not dive into specific frameworks such as DORA, SPACE, Flow Metrics, or team sentiment and developer experience qualitative metrics. Instead, it focuses on the platforms that integrate these various metrics and how their marketing narratives have confused senior leaders unfamiliar with this space.

The Growing Demand for Data-Driven Insights

A few years back, DORA metrics gained much attention, and early tools focused on providing dashboards to track them. Over time, these tools evolved and rebranded as Software Engineering Intelligence (SEI) solutions.

SEI platforms have gained significant traction recently as organizations recognize the importance of developer efficiency, software delivery performance, and engineering operational health. These platforms provide granular insights into pull request cycle times, deployment frequencies, mean time to recovery (MTTR), and engineering throughput, giving leaders a clear picture of how efficiently software is being built and delivered.

At their core, SEI platforms are designed to improve engineering operations, helping teams identify delivery bottlenecks, optimize workflow efficiency, and measure team health. For organizations still struggling to improve operational efficiency within delivery, SEI platforms make perfect sense and provide immediate feedback on a team’s ability to consistently ship high-quality software.

However, SEI is not the same as Value Stream Management.

Understanding the Misconceptions Around SEI and VSM

The key difference between these platforms lies in their scope. While SEI focuses on engineering processes, VSM platforms aim to provide end-to-end visibility across the entire software development lifecycle—from ideation and discovery to delivery and operation. The challenge is that many platform vendors position SEI as interchangeable with VSM, when in reality, the two serve different yet complementary purposes.

This overlap often leads to misaligned expectations for companies adopting these tools. Organizations seeking deep engineering intelligence might mistakenly invest in a VSM platform. VSM platforms can be more expensive because they can gather and present data from all stages of the digital product lifecycle, and most vendors target the larger enterprise market. However, they may lack detailed data from the engineering delivery stage, or your organization may not be ready to handle this scope. Companies looking for full end-to-end visibility might purchase an SEI platform focusing only on software delivery, preventing them from improving efficiency in the other value stream stages.

I recommend using metrics that cover the entire Value Stream, but this might not be cost-effective for many companies. To avoid choosing the wrong platform, technology leaders should start by identifying their organization’s bottlenecks:

  • An SEI platform is likely the best investment if engineering teams struggle with delivery performance.
  • If the challenge extends beyond engineering into product management, discovery, and business alignment, VSM will become a stronger choice.

VSM Only Works If Other Departments Are Engaged

One of the biggest mistakes companies make when adopting VSM platforms is assuming that technology alone can drive the initiative. The reality is that unless other departments, such as marketing, sales, or business leadership, see the value in tracking their processes, a VSM approach will not deliver full business impact.

VSM investment becomes effective when organizations use it to:  

  • Track and improve discovery workflows, such as how product teams validate ideas before passing them to engineering.  
  • Interest in capturing how the marketing and sales teams collaborate to support the discovery phase of the value stream by capturing these processes.
  • Provide visibility into how cross-functional collaboration impacts the creation and delivery of digital products.

If your leadership and other departments discuss process visibility and workflow optimization, a VSM solution can drive enterprise-wide improvements in parallel with software delivery improvements. However, if the initiative is primarily driven by engineering, then SEI is the better starting point, allowing teams to optimize delivery before expanding to broader value stream visibility.

My Journey Evaluating These Platforms in 2022

Between 2022 and 2023, before the term Software Engineering Intelligence (SEI) became widely known, I carried out a detailed evaluation of platforms for my organization including:

  • Digital.ai
  • ServiceNow
  • Planview (then Tasktop Viz)
  • Jellyfish
  • Broadcom
  • LinearB
  • Plutora
  • Pluralsight Flow
  • Sleuth

Most of these platforms have improved since I first evaluated them. At the time, to the best of my knowledge, tools like LinearB, Sleuth, and Jellyfish had not yet embraced the term SEI. They were engineering analytics tools focused on measuring software delivery performance. Meanwhile, Tasktop, Digital.ai, Broadcom, and ServiceNow identified their offerings as Value Stream Management (VSM) platforms.

Given our organization’s transformation stage, I narrowed the choices down to two platforms:

  1. Tasktop Viz (now Planview Viz) – A strong VSM platform offering broad value stream insights but lacking delivery-stage granularity.
  2. LinearB – A strong delivery-focused platform providing deep engineering analytics but lacked visibility for ideation-to-delivery.

At the time, I saw clear trade-offs:

  • VSM platforms were valuable for tracking end-to-end flow but lacked deep delivery insights.
  • Delivery-focused platforms had engineering visibility but provided no insight into ideation or operations and support stages of the Value Stream.

In 2024, my preferred VSM platform acquired an SEI platform, confirming my earlier belief that larger VSM platforms without detailed delivery integration would eventually seek to expand their capabilities through acquisitions.

The Emergence of DX Core 4

Contributing to the ever-changing landscape and array of choices, a significant development is DX Core 4, a framework designed to unify existing developer productivity models. DX Core 4 brings together principles from DORA, SPACE, and DevEx, focusing on four key dimensions:

  • Speed – How quickly software moves through the system.
  • Effectiveness – The ability to deliver software that meets requirements.
  • Quality – Ensuring software meets standards while minimizing defects.
  • Impact – Measuring the business and customer impact of software delivery.

The intent behind DX Core 4 is to balance these metrics, preventing over-optimization in one area at the cost of another. GetDX’s announcement provides more details.

Breaking Down Marketing Myths

Myth 1: AI is Exclusive to SEI

The SEI Claim: SEI platforms are the future because they use AI for deep analytics and decision support, while VSM platforms do not.

The Reality: This is completely false. Leading VSM platforms, including Planview Viz and ServiceNow, have invested heavily in AI and generative AI-driven insights for deep data analysis, decision-making, and flow optimization.

SEI vs. VSM AI Capabilities

AI is not an SEI-exclusive feature. Instead, SEI and VSM integrate AI-driven analytics, SEI for engineering delivery metrics, and VSM for end-to-end business value flow across the organization.

Additionally, Planview’s Viz (copilot), Broadcom’s ValueOps (The Future of Value Stream Management Will Be Powered by AI), and others have integrated AI-driven workflow automation, tool integration, and predictive analytics, further demonstrating that AI capabilities are not exclusive to SEI.

Myth 2: SEI Covers the Full Value Stream

The SEI Claim: SEI platforms provide comprehensive visibility into software engineering performance.

The Reality: SEI platforms focus on the delivery stage of digital product development. They analyze developer productivity, team and operational efficiency, and software engineering health, but they do not track the full lifecycle of a digital product from ideation to operation. The SEI platform might be just what your organization needs at its current stage or context.

Comparing Scope: SEI vs. VSM

The Main Takeaway

The key takeaway in the SEI vs. VSM discussion isn’t which toolset is gaining momentum; it’s about scope. Don’t let marketing hype or opinions mislead you. While they can guide your decision, it’s crucial to understand the framework or label: SEI focuses on software delivery performance metrics within the build and deployment pipeline, while VSM spans the entire digital product lifecycle, discovery, delivery, operations, and support.

SEI tools offer limited insights into how efficiently code moves through development and deployment, but VSM goes further by asking: Are we delivering the right value efficiently across the entire product journey? When evaluating a VSM platform, consider both the quality of development and deployment metrics and the broader data they use to provide visibility across the value stream and organizational impact.

Rather than viewing SEI as a competitor to VSM, see it as a specialized tool for the delivery stage, while VSM ensures visibility, optimization, and continuous improvement across the entire value stream.

Choose the Right Metrics for Your Needs

Instead of asking, “Which platform is winning?” the better question is:

Which platform works best for your needs and provides the best visibility, whether for a specific part of your value stream or the entire one?

Organization and Engineering leaders should focus on what matters: selecting the right tools to address the correct problems. The question isn’t just about SEI vs. VSM. It’s about clearly understanding:

  • Where your organization’s bottlenecks exist
  • Who is driving the initiative
  • What level of visibility will drive the most impact

A few years ago, I started working with modern metrics like DORA. Since then, I’ve become a board member of the Value Stream Management Consortium, a champion for VSM implementation at my current organization, and an advocate for aligning software delivery metrics with business outcomes. This has given me the chance to explore the growing world of value stream management (VSM) and software engineering intelligence (SEI) platforms. Interestingly, a former colleague of mine is now a co-founder of one of these emerging platforms.

Vendors often use persuasive marketing to grab your attention and budget, but it’s important not to get caught up in the hype. Focus on your organization’s specific needs and the scope of the solutions offered. VSM and SEI platforms can differ greatly in features and cost, so finding the right fit means balancing your budget with your business priorities. Take the time to assess what truly matches your goals before making a decision.


Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Filed Under: Agile, DevOps, Engineering, Leadership, Lean, Metrics, Product Delivery, Software Engineering, Value Stream Management

Beyond outcome-focused metrics: Connecting Work to Outcomes

February 4, 2025 by philc

5 min read

In her recent article, Measuring What Matters: Using Outcome-Focused Metrics to Build High-Performing Teams in 2025 1, Leah Brown from IT Revolution, an industry-leading resource on digital transformation strategies, emphasizes prioritizing real business value over purely technical outputs. She highlights that truly effective value measurement requires:

  • Clear alignment on strategic direction and goals
  • Regular communication of value across stakeholders
  • Built-in feedback loops to validate assumptions
  • Focus on outcomes over outputs
  • Willingness to adjust based on learning

This approach aligns with IT Revolution’s research, which has been instrumental in shaping modern software delivery practices. These principles align closely with my mission to bridge the gap between technology investments and business outcomes through better flow, business alignment, and leadership accountability.

A key challenge in many organizations is that software development and platform investments are often seen as black boxes, necessary costs disconnected from measurable business value. By structuring measurement around value streams and outcome-driven metrics, we can connect technology investments directly to business results and make the value of software delivery transparent.

Applying Value Stream Thinking to a Culture of Value Measurement

Shifting the organization’s focus to customer value streams is a key way to reinforce strategic alignment, feedback loops, and outcome-driven measurement.

When value streams are the core management approach:

  • Customers get the immediate benefit of priority at the organizational level – In addition to internal teams optimizing for efficiency, the entire organization prioritizes work that directly improves customer outcomes.
  • The organization becomes more responsive to customer needs and value creation, aligning outcomes over outputs. A value-driven operating model ensures that teams measure success not by what they produce but by how it improves customer experience, revenue, or retention.
  • Problems surface earlier, and solutions are faster and more sustainable. Value streams highlight bottlenecks and inefficiencies in delivering customer value while supporting built-in feedback loops, ensuring that delays, hand-offs, and friction points are made visible before they become significant issues.
  • Collaboration, continuous improvement, and problem-solving become natural outcomes – Instead of forcing teams into siloed KPIs, a value stream focus encourages alignment across departments, reducing hand-offs and friction, enabling faster decision-making, more iterative feedback, and fewer artificial constraints.
  • There is a clear and transparent connection between work and value – In many organizations, software teams are seen as cost centers rather than strategic enablers. When work is structured around value streams, there is greater transparency into how investments in software development and platforms contribute to business goals. This alignment reinforces regular communication of value across stakeholders.
  • All initiatives must be tied back to a customer or business metric. This principle directly supports outcome-driven measurement. By tying all work to business metrics, organizations avoid point optimizations (improving one team’s efficiency at the expense of customer value) and instead focus on work that improves a few critical metrics.
  • Cross-company cultural initiatives become easier to implement – Many organizations struggle with broad transformation efforts because they are optimized for vertical silos, not horizontal value delivery. Value stream management connects teams across functions, making it easier to align priorities, drive enterprise-wide change, and improve strategic execution.
  • Bureaucracy and process inefficiencies become visible – One of the most significant benefits of value stream-based measurement is that it exposes where excessive approvals, dependencies, and misaligned goals slow delivery. By tracking work across the value stream, organizations can see where bureaucracy blocks flow and make data-driven improvements.

Value Streams & Flow Metrics: Unclogging the Arteries of an Organization

In Value Stream Management conversations, the highway analogy regarding the greater volume on a highway, the more restricted cars travel (referring to work in progress or WIP), or if roadwork is slowing the flow is common (friction). Recently, I came across an analogy comparing Value Stream Management to clogged arteries. Most organizations operate like clogged arteries. Excessive hand-offs, approval processes, and misaligned priorities block value streams. Instead of measuring and improving flow, they optimize for vertical efficiency in isolated teams, much like focusing on individual organs rather than blood circulation.

  • The heart keeps blood flowing freely in a healthy body, ensuring oxygen and nutrients reach every part of the system.
  • Value Stream Management keeps work flowing freely in a healthy organization, ensuring value reaches customers and reducing delays.

However, many organizations suffer from congested workflows, unnecessary approvals, long hand-offs, and fragmented ownership, like arteries clogged with plaque leading to:

  • Work stalling in queues instead of moving efficiently.
  • Teams focus on local optimizations rather than system-wide flow.
  • Decision-making being slowed by too much bureaucracy.
  • Business leaders are unable to see where the real problems are.

Instead of waiting for a heart attack (a major failure or missed market opportunity), organizations should treat flow efficiency as a leading indicator of business health. Just as doctors track blood pressure and cholesterol to prevent heart disease, organizations should track Flow Metrics to avoid workflow breakdowns.

Value Streams as the Foundation of a Culture of Value Measurement

Building a true culture of value measurement requires structuring the entire organization around outcomes and customer value streams, not internal projects or siloed optimizations. Organizations can reinforce a culture of Outcome focus and Value Measurement using Value Stream Management.

  • Start with Clear Alignment on Strategic Direction – Each value stream team should define or be clear on the expected outcomes before starting work.
  • Regularly Communicate Value Across Stakeholders – Track progress using OKRs and periodic metric reports. Consistently evaluate performance to highlight progress, small achievements, or course corrections.
  • Implement Feedback Loops to Validate Assumptions – Capture and reflect on Flow, DORA, and related Metrics across the entire value stream, not just engineering velocity.
  • Focus on Outcomes, Not Just Outputs – Use Value Stream Thinking to ensure teams optimize for business results rather than just completing tasks.
  • Be Willing to Adjust Based on Learning – If a team’s work isn’t improving a key customer metric, be willing to pivot and shift priorities based on real-world feedback.
  • Make Technology Value Visible – Stop treating software and platform engineering as an invisible backend function. Instead, connect technology investments directly to business goals like revenue, customer retention, and agility.

Want to Go Deeper?

For further reading, check out these articles:

  • From Good to Great: Shifting to Outcomes in 2025
  • Why Value Stream Management and the Product Operating Model Matter
  • Profitable Engineering: Linking Software Engineering to Business Results

Metrics

  • Navigating the Digital Product Workflow Metrics Landscape: From DORA to Comprehensive Value Stream Management
  • Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks

Let’s continue the conversation: how is your organization shifting from output tracking to actual business impact using value streams?

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

References

  1. Measuring What Matters: Using Outcome-Focused Metrics to Build High-Performing Teams in 2025, Leah Brown, IT Revolution, https://itrevolution.com/articles/measuring-what-matters-using-outcome-focused-metrics-to-build-high-performing-teams-in-2025/

Filed Under: Agile, DevOps, Engineering, Leadership, Metrics, Product Delivery, Software Engineering, Value Stream Management

Why Value Stream Management and the Product Operating Model Matter

January 5, 2025 by philc

5 min read

In 2021, as an evolution in our agile transformation efforts, I introduced Value Stream Management (VSM) to my organization and later advocated for the Product Operating Model (POM), but I never clearly explained why I believe these practices are so important. While I’ve shared their benefits in various writings and conversations with industry leaders, I failed to deliver a cohesive message to my department. This lack of clarity has sometimes created a misalignment between the technology and product teams, hindering our ability to adopt these practices fully.

Looking back, I realized that even before formally identifying the Product Operating Model as a framework, our team—and I—were already heading in that direction. By setting up cross-functional teams aligned to specific products, we naturally moved toward a product-focused approach without defining it explicitly. However, many teams still juggled tasks across multiple products, which exposed inefficiencies and reinforced the need for a clear, intentional strategy.

This experience taught me a vital lesson: adopting and communicating frameworks like the Product Operating Model and Value Stream Management is critical for team alignment, operational efficiency, and sustainable delivery.

Why Adopt Value Stream Management and a Product Operating Model?

In almost every organization, there is more work than capacity. This reality underscores the need for prioritization and a focus on outcomes over outputs. I advocate for adopting VSM and the POM because they address this challenge head-on, providing a framework to align teams, optimize workflows, and deliver maximum value.

The 2024 Project to Product State of the Industry Report1 confirms this approach, showing that organizations that adopt these frameworks outperform their peers:

  • Elite organizations meet their quarterly objectives over 90% of the time, compared to less than 50% for low performers.
  • These elite organizations are 2x more likely to operate with a product-oriented approach, reducing wasted effort by 30%.
  • Yet, only 12% of organizations have fully operationalized the shift to a Product Operating Model, and most are still in the early stages of adoption.

These statistics highlight not only the opportunity but also the challenges organizations face when adopting these practices.

Aligning Teams to Deliver Maximum Value

A Product Operating Model allows teams to focus deeply on specific products, becoming subject matter experts while owning the product’s entire lifecycle. This ownership fosters alignment with business goals and eliminates inefficiencies caused by constant context switching.

The 2024 Project to Product State of the Industry Report reveals that in elite organizations:

  • Over 50% of work is product-oriented, while low performers remain stuck in project-based approaches.
  • Product-focused work leads to fewer canceled projects, less technical debt, and more business-aligned outcomes.

Value Stream Management complements the POM by making workflows visible, identifying bottlenecks, and optimizing delivery processes. Together, they enable teams to focus on what truly matters: delivering measurable value to the customer.

“Aligning teams to a product-focused approach ensures they not only deliver outputs but also realize outcomes, driving measurable impact for the business.”

Closing the Loop: Realization Matters

While flow ensures that work moves efficiently, realization connects delivery to outcomes. Realization is the critical second half of the equation: Did the work change customer behavior as intended? Was the desired outcome achieved?

The 2024 Project to Product State of the Industry Report highlights the gaps many organizations face:

  • Only 15% of organizations can incorporate customer feedback within weeks, meaning most teams lack the insights needed to close the loop.
  • 30% of work in low-performing organizations remains over 90 days old, contributing to waste and inefficiency.

“Flow transforms effort into movement, but realization transforms movement into impact. Without closing the loop, we risk delivering outputs instead of outcomes.”

By linking flow metrics to customer behavior and business results, teams can measure the true value of their work. This feedback empowers teams and fosters a culture of continuous learning and adaptability.

Why Context Matters

Adopting frameworks like Value Stream Management or the Product Operating Model as a checklist of best practices is tempting. However, organizations that treat these as cookie-cutter solutions often struggle to realize their full potential. Context matters—the success of these practices depends on how well they are adapted to the organization’s unique challenges, culture, and goals.

“There is no one-size-fits-all approach to transformation. The true power of frameworks like VSM and the Product Operating Model lies in their flexibility to serve as blueprints rather than rigid rules.”

The 2024 Project to Product State of the Industry Report reinforces this, showing that elite organizations don’t merely implement practices—they adapt them to align with their structure, strategy, and customer needs.

By focusing on the core principles—alignment, flow, and realization—organizations can customize these practices to suit their context while achieving their desired outcomes.

Empowering Cross-Functional Teams

Empowerment isn’t just for product managers—it’s for the entire cross-functional delivery team. While the 2024 Project to Product State of the Industry Report highlights the role of product managers in driving vision and outcomes, the real magic happens when teams collectively own their work, informed by flow metrics and realization feedback.

“When teams understand how their work impacts customer behavior, they can make informed decisions, prioritize effectively, and adapt quickly to feedback.”

This shared empowerment enables teams to:

  • Collaborate more effectively.
  • Deliver higher-quality outcomes faster.
  • Build trust and alignment across roles and departments.

The Road Ahead

For 2025, this will be one of my primary focuses within my organization. This renewed focus stems from the feedback I received in late 2024 during a leadership program. In an anonymous 360-degree assessment from my peers at the executive level, one comment stood out: “You should focus more on business results as a technology leader.” That feedback hit hard but was also eye-opening. It made me realize that while our 10-year transformation from a monolithic waterfall process to a world-class Agile, continuous delivery, and microservices-based cloud solution was remarkable, we failed to communicate how this transformation drove measurable business results.

In response to this feedback, I am creating new tools and communication strategies for 2025 to enhance our approach to Value Stream Management and Product Operating Models:

  • Value Stream Templates: Helping teams realign or re-identify value streams, ensuring our work directly connects to business objectives.
  • Initiative and Epic-Level Definitions: Providing a template for improved initiative and epic-level descriptions in Jira (or similar tools) that emphasize anticipated outcomes and dependencies.
  • Team-Level OKRs: Establishing Objectives and Key Results tied to outcomes, ensuring alignment with business priorities.
  • Division Wiki Updates: Updating our internal documentation to emphasize outcomes over outputs, recognize dependencies, and reinforce our mission.

These efforts aim to bridge the gap between technology initiatives and business value, ensuring we deliver features and demonstrate their impact on growth, profitability, and customer success.

Finally, I welcome your insights and ideas for those leading similar changes. Let’s learn from one another and work together to align our efforts with the outcomes that matter most.

“The time to act is now. Let’s lead purposefully, ensuring our teams deliver meaningful, measurable value in 2025 and beyond.”


Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]


References

  1. The 2024 Project to Product State of the Industry Report, Planview, https://info.planview.com/project-to-product-state-of-the-industry-_report_vsm_en_reg.html

Filed Under: Agile, DevOps, Leadership, Metrics, Product Delivery, Software Engineering, Value Stream Management

From Good to Great: Shifting to Outcomes in 2025

January 2, 2025 by philc

7 min read

Audience and Purpose

This post is both a reflection and a vision. It’s a message for my team—who have been with me through challenges and successes—and a blog for leaders, peers, and anyone interested in the lessons we’ve learned and where we’re going next.

I chose to share this message as a blog post to reach my team and other leaders or organizations facing similar challenges. These insights encourage collaboration, spark new ideas, and help others navigate organizational transformation.

From Good to Great: Shifting to Outcomes in 2025

Today is January 1, 2025—a fresh start and a chance to reflect on the past year and plan for what’s ahead. During Thanksgiving, I shared my gratitude with my division and team for their hard work and achievements during a challenging time. However, I haven’t yet fully shared my vision for the future. As this new year begins, I’m reflecting on the significant changes ahead and our unique opportunities.

Our parent organization, which acquired us last year, is undergoing its transformative journey, driven by new investors and ambitious strategic plans. As they prepare to begin January with an inspiring company-wide message, it is equally important to focus on our division and the brand we have built together. This message is directed to our team as we navigate this period of change and improve the foundation for the future.

As we continue to grow and integrate, it is essential to maintain a long-term perspective. By 2026, we aim to become a stronger, unified organization with aligned practices, cohesive team structures, and a clear strategic direction. This year represents a pivotal phase in that process—a time to refine our identity, enhance our impact, and position ourselves for sustained success.

The perspectives and recommendations outlined here are based on my personal reflections and my understanding of where we currently stand and the potential paths forward. While I believe these steps represent meaningful progress, I want to stress that they are not the only way forward. If you have alternative ideas or cannot align with this vision, I encourage you to share your input. Collectively, our contributions will help shape the most effective path ahead.

A Journey of Growth and Transformation

Over the past decade, our team has faced its share of challenges—personality conflicts, shifting priorities, and growing pains—but we’ve also achieved remarkable transformations. Together, we’ve evolved from an unstable monolithic platform to a modern, scalable system powered by a culture of investment, innovation, and learning.

Ten years ago, we were constantly rebooting systems hosting a fragile monolithic solution. Back then, our releases were massive undertakings—twice a year, requiring months of preparation and leaving us with long downtimes and high risk. Today, we operate a cloud-based, microservices architecture, built on the principles of Agile, Lean, and DevOps. Our team has embraced automation, continuous delivery, and scalable design, enabling us to release updates 5 to 20 times a day with confidence and speed.

Additionally, 2024 marked yet another year of 99.99% system and platform uptime, a testament to the incredible work of our production engineering and platform teams. They’ve created a robust system that not only serves our customers seamlessly but also provides developers with a reliable, scalable foundation for innovation.

This transformation was about more than just technical changes. It required us to redefine our culture, leadership style, and design principles while investing in our people and processes. Along the way, I’ve realized that my passion as a leader hasn’t always been perfect—whether through my soapbox moments or the well-known “Phil Fridays,” where I’ve shared thoughts and emotions built up over the week (not to be confused with “50 Fridays,” which focuses on innovation). These moments, while not always polished, came from a genuine desire to see us succeed and continuously improve.

While we’ve said goodbye to a few team members who helped us kickstart this transformation, their contributions were vital in laying the groundwork for our progress. The baton has been passed, and the team has carried it forward, driving meaningful change and continuing to make strides. What inspires me most is that many of the people who helped lead this journey are still here, pushing us to new heights. Our success is not just about technological evolution—it’s also a testament to the strength of our culture and the dedication of our team.

The Challenges of Commitment: Moving to a Product Operating Model

Over the past few years, we’ve attempted to transition to a product operating model and embrace practices like value stream management. While the technology team introduced these concepts and championed them, my perception is that we’ve struggled to fully commit because product and technology have not been fully aligned.

Without full commitment from the product side, we’ve continued to treat teams like projects, prioritizing capacity demands across all products rather than focusing on the holistic value streams that underpin the product operating model. This fragmented approach has created inefficiencies and diluted the impact of our efforts.

In 2025, this must change. Both product and technology must align and fully commit to the product operating model. We need to reintroduce the reasons we’re practicing value stream management: to improve flow, align work to customer and business outcomes, and eliminate the inefficiencies of project-driven thinking. By embracing this approach together, we can build a stronger foundation for delivering value.

Again, this is my recommendation for moving forward. If you believe there’s a better way or cannot align with this vision, I encourage you to share your thoughts. Collaboration will help us shape the best possible future.

The Shift: Focusing on Outcomes

This year, our focus is on outcomes over outputs. It’s a simple but powerful shift: instead of measuring success by the features we deliver or the tasks we complete, we’ll measure it by the impact we create for our customers and the business.

This outcomes-first approach will give teams clarity and purpose, ensuring that every initiative has a measurable goal tied to a business or customer result. Importantly, this applies to both features and technical debt. Each type of work should have an anticipated outcome and clearly articulate the value it will bring to the customer and the results it will deliver for the organization. Here’s how we’re implementing this shift:

  1. Anticipated Outcomes: Every epic will start with a clearly defined, measurable outcome, documented in our tools like Jira.
    • Example (Feature): Launch a new onboarding feature for learners.
    • Outcome: 80% of new users complete onboarding within 7 days, leading to a 25% increase in first-month retention by Q3 2025.
    • Example (Technical Debt): Refactor the search service to improve scalability.
    • Outcome: Search success rate increases from 70% to 90%, resulting in a 15% boost in user engagement by June 2025.
  2. Alignment Through OKRs: Teams will translate these anticipated outcomes into team-level OKRs (Objectives and Key Results) that align with broader organizational goals.
    • Example:
      • Division Objective: Expand access to dual enrollment opportunities.
        • Key Result: 10,000 learners use the new onboarding feature by August 2025.
        • Team Objective: Improve onboarding for new learners.
          • Key Result: 80% of new users complete onboarding within 7 days, increasing retention by 25%.
  3. Closing the Loop: Measuring outcomes doesn’t end at delivery. Even if final metrics take a month, three months, or six months to materialize, we must go back and document the actual outcomes of our work. This step is critical for understanding whether our efforts moved the needle and for learning what adjustments might be needed in the future. Closing the loop ensures that we evolve based on data, not assumptions, and continuously improve how we deliver value.

By aligning outcomes with OKRs and closing the loop, we will create a system where every effort is purposeful, measurable, and connected to a larger vision. This approach will reduce chaos, improve clarity, and foster deeper engagement across teams, ensuring everyone understands not just what they are working on, but why it matters and how it contributes to our shared goals.

Balancing Progress with Organization Integration

While we focus on outcomes in 2025, we’re also navigating the complexities of post-acquisition integration. Aligning with our parent company and managing our brand presents its own challenges, but it also offers opportunities to grow and unify our practices.

In 2025, we’ll deepen our integration efforts while maintaining our commitment to improving how we work. This dual focus will prepare us for a seamless transition into a unified operating model in 2026 and beyond.

Key Takeaways for Leaders

Here are the key elements of our approach—ideas that I hope other leaders can use to improve alignment, engagement, and impact within their own teams:

  1. Start with Outcomes: Define measurable, customer-centric outcomes for every initiative before beginning work.
  2. Align with OKRs: Use team-level OKRs to connect outcomes with broader organizational goals.
  3. Empower Teams: Provide clarity and purpose to help teams prioritize work that drives real value.
  4. Close the Loop: Track and evaluate actual outcomes, learning from both successes and shortfalls.
  5. Commit to Product Thinking: Transition fully to a product operating model and align product and technology teams on shared goals.

Looking Ahead: Making 2025 Count

2025 is our opportunity to go from good to great. By shifting to outcomes, fully committing to the product operating model, and reintroducing value stream management, we’re not just improving how we measure success—we’re creating a stronger connection between our work, our customers, and our business goals.

To other leaders reading this: Software engineers and technical leaders who only focus on technical topics—like technical debt, infrastructure upgrades, code quality, and development processes—risk losing relevance. Why? Succeeding in today’s tech world requires more than technical skills. It requires understanding customer experiences, business goals, and the value of technical investments. Clear communication and alignment on shared goals are essential to achieving meaningful outcomes by connecting technical investments to business results.

The most successful engineering professionals and technical leaders will explain how technology investments can:  

  • Expand market opportunities through better performance and innovation  
  • Drive stronger customer impact  
  • Deliver measurable business results  
  • Create strategic advantages

Those who don’t adapt to this change are falling behind. In the future, knowing how to build technology won’t be enough. The key will be understanding why it’s being built—and making sure every decision, feature, or technical investment adds value for both the customer and the business.

This journey is about creating a lasting impact—for our customers, business, and teams. Linking technical investments to business outcomes is the adjustment that will improve our team in 2025, but it is just a choice. I welcome you—and my own team—to bring forward alternatives if you cannot align with this approach or have a better one in mind.

For more on this topic, check out my three-part series, “Profitable Engineering: Connecting Software Development to Business Outcomes.”


Poking Holes

I invite your perspective on my posts. What are your thoughts?

Filed Under: Agile, DevOps, Engineering, Leadership, Lean, Metrics, Product Delivery, Software Engineering, Value Stream Management

Breaking Free from the Build Trap: Delivering Meaningful Outcomes

December 25, 2024 by philc

10 min read

This image has an empty alt attribute; its file name is FeatureFactory-1024x1015.jpg

This article is the final part of a series on linking software engineering to business success. If you missed the earlier articles, start here.

This Article at a Glance

This article explores how engineering teams can escape the “build trap” and move beyond a feature factory mindset by focusing on outcomes instead of outputs. It highlights the pitfalls of the build trap, the value of starting with outcomes, fostering accountability and alignment, and ensuring successful delivery. Aimed at technology leaders, Product Managers, and teams, it challenges them to adopt a mindset centered on meaningful outcomes—driving engagement, alignment, and impactful business results.

From Speed to Meaningful Value

Picture this: you’re leading a team of talented developers, launching features rapidly, but customer satisfaction isn’t improving, and the business impact is unclear. This happens when teams focus too much on output, a common issue in traditional project-based management. Switching to a product operating model and applying Value Stream Management can break this cycle. These approaches focus on outcomes instead of outputs, ensuring every effort is tied to measurable business value.

As a senior technology leader, I’ve been there. Early in my career, I focused on operational efficiency and rapid feedback, confident that speed and volume would drive success. But I learned the hard way: speed alone doesn’t guarantee value.

This realization highlighted a critical gap—the need for realization. Efficiently delivering work is only part of the puzzle; the priority must be ensuring that every effort contributes meaningful outcomes for both customers and the business.

To close this gap, I began asking:

  • What outcomes do we expect, how will we measure success, and what can we learn from the results?

By adopting value stream management (VSM) and objectives and key results (OKRs), we created a clear link between work and impact. VSM revealed how work flows through teams and where value is created, while OKRs provided a framework for aligning team goals with organizational priorities.

Escaping the build trap isn’t just about faster delivery—it’s about rethinking success. When efforts are tied to measurable results, teams and leaders work with clarity, purpose, and trust, transforming delivery into meaningful value for the business and its customers.

Defining Outcomes at Every Level

Anticipated Outcomes for Epics

In Agile software development, an initiative is a large, highest-level body of work representing a significant feature or functionality too extensive for a single sprint. Initiatives usually have Epics defined to support a piece of the Initiative. Defining anticipated outcomes for each Initiative or epic clarifies the value being delivered, the behavior being changed, and how success will be measured. This approach helps teams see their work’s purpose and anticipated impact and how it aligns with organizational goals, as well as create team-level OKRs within their focus areas.

Questions to define Initiative or Epic level outcomes:

  1. What problem are we solving, what behavior are we changing, or what opportunity are we addressing?
  2. What results do we expect, and how will we measure them?
  3. What metrics will define success?
  4. How will we close the loop by learning from actual outcomes?

Example: An initiative aimed at improving onboarding might define success metrics like:

  • Increasing customer retention by 10% within 30 days.
  • Reducing onboarding-related support tickets by 15%.
  • Receiving positive feedback from customer satisfaction surveys.

By defining these outcomes, teams can create Key Results that align with broader organizational objectives, ensuring their efforts directly support larger goals. These key results can become the objectives of supporting epics.

Outcomes-Driven Iterations

Initiatives or Epics provide the overarching product change or improvement, while sprints should center on value-driven outcomes, not merely task completion. Traditionally, sprints have prioritized finishing backlog tasks. However, by integrating Value Stream Management with a product operating model, the focus shifts toward delivering meaningful value. Instead of measuring success by completed tasks, sprints are now about achieving impactful results aligned with value streams. This approach ensures that every iteration targets tangible customer and business results.

Teams should define sprint goals based on outcomes, not tasks.

Example: “Enhance system performance by improving response times by 5%” (outcome) versus “Complete three refactoring tickets” (task).

This mindset shifts how teams view their work:

  1. Collaboration over individual output: Team members who finish early should check if the sprint goal has been met and help others achieve it.
  2. Focus on shared success: Success is measured by achieving the outcome, not individual task completion.

When iteration goals align with epic outcomes, teams focus on delivering meaningful value at every level of work.

OKRs, focus on organization alignment

OKRs are essential for helping teams break free from the build trap by connecting their efforts to impactful outcomes. By focusing on work (features, technical debt, defects, and risks) within the team’s scope or control, OKRs align the team’s work with customer needs and organizational objectives. This alignment transforms sprints, epics, and initiatives from mere tasks into measurable milestones that drive meaningful business results.

OKRs bridge the gap between your team’s efforts and the outcomes that truly matter, encouraging a focus on value rather than speed. This mindset shift fosters intentional work and delivers impactful results.

To develop a team-level OKR from a parent key result, you can use a method known as explicit alignment or cascading. This process transforms a higher-level key result into a focused objective for your team, ensuring clear alignment and purpose. Here’s an effective way to approach it:

  1. Define your desired outcome and ensure it aligns with a relevant Parent Key Result:
    Begin by reviewing the overarching OKRs at the company or department level. Identify a key result that aligns with your team’s responsibilities and can be directly influenced within your team’s scope.
  2. Transform the Key Result into an Objective:
    Reframe the parent key result as a clear objective for your team (the expected outcome). This objective will serve as the central focus of their efforts.
  3. Develop Supporting Key Results:
    Create 3-5 key results to help your team achieve this new objective. These should be specific, measurable, and aligned with the overall goal or outcome.
  4. Ensure Alignment:
    Make sure your team’s OKRs align with and support the higher-level objective they are based on. Set clear targets for each key result by defining what success looks like for your team about the parent key result. This will help keep your team focused and guide their efforts toward achieving the desired outcome.

Note: Escaping the build trap requires more than focusing on outcomes—it demands a structural shift to a product operating model. By aligning teams with specific products and value streams, organizations create an environment where teams are not just delivering features but owning the evolution of outcomes over time. This model encourages accountability and allows teams to iteratively refine their work, fostering alignment with customer needs and organizational goals. It also reduces handoffs and inefficiencies, enabling teams to focus on continuous delivery and improvement.

Accountability and Team Alignment

The Role of Product Managers

A strong product team is defined by the trust and partnership between engineers and their Product Manager—someone engineers would confidently “go to bat for.” To build this trust, Product Managers must prioritize technical debt, risks, and defects alongside new features, acknowledging their critical role in delivering a high-quality product.

Product Managers must also actively engage as part of the team. Their role involves:

  • Collaborating on priorities.
  • Participating in discussions.
  • Supporting the shared goal of delivering value to customers.

Ownership

Every outcome or team-level OKR needs a clear owner—someone who is accountable for defining, prioritizing, and ensuring its achievement. In Agile teams, this often means Product Managers own the outcomes tied to customer-facing features, while technical leads take responsibility for outcomes related to technical debt, scalability, or system performance. For example:

  • A Product Manager might own the outcome of increasing user retention by 10% through a new onboarding feature, ensuring the team understands the goal and tracks metrics like retention or onboarding completion rates.
  • A Technical Lead might own the outcome of reducing downtime by 15% by addressing key infrastructure improvements, ensuring technical debt is addressed in a way that aligns with broader organizational goals.

Ownership ensures clarity and accountability, preventing outcomes from falling through the cracks or becoming vague aspirations. The owner is also responsible for closing the loop—documenting the actual outcomes, sharing them with stakeholders, and reflecting on whether the actual outcomes were achieved.

Prioritizing by Anticipated Outcome or Impact

There’s always more work than resources. Your team is limited by the people you There’s always more work than resources. Your team is limited by the people you have and the time available. Capacity limits make it essential to prioritize based on outcomes. When new tasks arise, check if they align with your current objectives or OKRs. Don’t hesitate to push back if they don’t contribute to key objectives. Ask yourself:

  • Does this work align with our top priorities? If not, why should it take precedence?
  • What will we remove or deprioritize to maintain focus if we take on this work?
  • How does this impact our ability to achieve current targets and objectives?

When new work aligns with your objectives or introduces a higher-priority goal, something else must be deprioritized to make room. Collaborate as a team to identify and remove the lowest-priority work and communicate the updated goals or OKRs.

Prioritizing work based on anticipated return on investment (ROI) and anticipated outcomes ensures that engineering efforts focus on initiatives with the greatest potential for business impact. This approach balances short-term needs with long-term value creation, guiding teams to deliver meaningful results.

By recognizing capacity constraints and ensuring all stakeholders understand new requests’ significance and expected impact, teams can align their efforts with expected outcomes and ROI. This approach fosters collaboration, accountability, and a shared commitment to purposeful progress among Product Managers, engineers, and stakeholders.

Aligning Incentives

Teams must recognize the tensions created by differing role incentives:

  • Product Managers are often rewarded for growth and feature delivery.
  • Engineers focus on quality, performance, and resilience.

These priorities can clash, but alignment is achievable when both roles focus on shared outcomes. Product Managers who treat technical debt, quality, and security as essential aspects of the product—not competing concerns—foster trust and collaboration within their teams.

Great engineers go beyond technical skills—they understand the product and its goals. They ask thoughtful questions to ensure their work meets customer and business needs. This understanding helps them propose pragmatic solutions, such as quickly delivering 80% of the value while planning to address the remaining 20% later. By balancing speed and quality, engineers with a product mindset help their teams avoid becoming a “feature factory” that builds without considering impact or value.

When teams hold all members—particularly Product Managers responsible for features—accountable for defining outcomes, measuring success, and closing the feedback loop, they achieve greater clarity and alignment. This accountability drives purposeful work, encourages shared ownership, and links meaningful outcomes directly to business goals.es, measuring success, and closing the feedback loop, they achieve greater clarity and alignment. This accountability drives purposeful work, encourages shared ownership, and links meaningful outcomes directly to business goals.

Closing the Loop

I am a huge fan of “closing the loop” or sharing the outcome of the team’s efforts with the team and organization. Success isn’t just about finishing tasks; it’s about creating meaningful results. Instead of focusing on whether something is “done,” the impact measures real success: Did our work lead to an apparent, positive, and measurable change in customer behavior? Closing the loop is a key part of this process, and Product Managers and technical leads need to prioritize it to achieve lasting outcomes.

Although it may take weeks, months, or longer to receive the data or feedback, documenting the actual outcomes—whether in the Initiative, Epic, or both—is essential to show how the team performed. Metrics like customer engagement, retention, or efficiency gains help determine if the work delivered its intended value. For instance, if a new feature was meant to reduce churn, tracking churn rate, customer feedback, or increased product usage can confirm if the goal was met. Without this step, teams lose an essential chance to learn from their work. It shows how well the team met its objectives, helps improve future decisions, and ensures continuous growth.

Incorporating “closing the loop” into workflows helps Product Managers and technical leads gain actionable insights from every project. It ensures teams receive feedback on their work, promoting accountability, alignment, and constructive improvement. This approach keeps the focus on achieving clear outcomes and measurable success.

From Delivery to Realization

We’re enhancing team performance and operational efficiency by adopting a Product Operating Model and incorporating Value Stream Management (VSM) and Objectives and Key Results (OKRs) into our processes. Unlike projects with a defined end date, products follow a lifecycle—we’re not finished until the product is retired. This approach allows us to align teams to products and continuously deliver updates and improvements throughout a product’s lifecycle.

Value Stream Management (VSM) enables us to visualize the entire flow of value delivery, helping us identify and address bottlenecks and inefficiencies. Meanwhile, OKRs provide a structured framework for setting and tracking team goals, ensuring alignment with the organization’s broader strategic objectives. Together, these tools drive focus, clarity, and measurable progress in delivering value to our customers.

Integrating these practices is transforming our culture. Success is no longer measured by speed or output alone—it’s defined by the value delivered. These practices empower teams to recognize their impact, align with shared goals, and clearly demonstrate how their efforts drive business performance.

Lead With Outcomes

The time for teams to focus on both delivery and realization is now.

Steps to transform your teams:

  1. Define outcomes first: Start every epic, sprint, and initiative with clear, measurable outcomes.
  2. Hold teams accountable: Ensure product managers and engineers align with outcomes, not just output.
  3. Close the loop: Measure actual results, share insights with the team, and learn from every outcome through retrospectives.

When teams align on outcomes and focus on delivering impactful value, they move beyond simply following orders. They gain clarity on their purpose and unlock their full potential. We can create products that provide meaningful customer value while demonstrating clear contributions to organizational success.

Let’s lead with expected outcomes and break free from the build trap—together.

Series Summary

  1. Profitable Engineering: Linking Software Engineering to Business Results

Related Posts: Metrics and Team Efficiency

  • Navigating the Digital Product Workflow Metrics Landscape: From DORA to Comprehensive Value Stream Management Platform Solutions, August 31, 2024
  • A Balanced Approach to Agile Metrics: Empowering Teams and Mitigating Risks, March 02, 2024.
  • Mitigating Metric Misuse: Preventing the Misuse of Metrics and Prioritizing Outcomes Over Outputs, June 21, 2023.
  • Developer Experience: The Power of Sentiment Metrics in Building a TeamX Culture, June 18, 2023.
  • Outcome Metrics and the Difficulty of Reporting on Value, February 18, 2023.
  • Maximizing Technology Team Performance: Insights from a CEO Conversation, February 15, 2023.
  • Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks, December 29, 2022.

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Filed Under: Agile, DevOps, Leadership, Lean, Metrics, Product Delivery, Software Engineering, Value Stream Management

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to Next Page »

Copyright © 2025 · Rethink Your Understanding

  • Home
  • Practices and Mission
  • Collaboration
  • AI
  • Posts
  • Podcast
  • Endorsements
  • Resources
  • Contact