Back to Blog List

Leading with Evidence: Navigating Complexity through APOM - Your Questions Answered

Dave West
(United States)
March 9, 2026
Subscribe
Unlocking the Agile Product Operating Model (APOM): Addressing the Core Barriers to Value Delivery

This blog is co-authored with Darrell Fernandes, Executive Advisor at Scrum.org

Last month, we ran a webinar titled ‘Leading with Evidence:  Navigating Complexity through the Agile Product Operating Model’. The webinar focused on what we had learned from a recent survey and highlighted some of the challenges that organizations faced with moving to a product operating model. This blog provides answers to some audience questions that we did not have time to address in the webinar. Some of the questions are a combination of multiple similar questions and are paraphrased. 
 

Our org, like many, is managed by the PMO. Software development is seen as working in a unique operating model that needs to adapt and align with traditional PMO project management. Can Agile succeed with this approach?

Agile, specifically Professional Scrum, can absolutely succeed in this environment. There are many paths to success here, but some foundational steps would be to build a strong partnership with the PMO based on evidence, evaluate the portfolio for the most appropriate initiatives to leverage iterative development, drive full transparency across the investment pool, and engage with business partners to build a product delivery team. We have observed that as organizations adopt a product operating model, PMOs evolve alongside that change. They change from output to outcome-oriented approaches and stop managing projects to enable teams to deliver against goals. This change is often a key to organizations who are really moving to a product approach.   


Additional resources:

 

Regarding incentives, where is the best place to find advice, and who leads the change on incentives?
To move toward an Agile Product Operating Model, organizations must address the "Consistency Crisis" in how they motivate teams. Realigning incentives isn't a solo mission; it requires two parallel tracks running simultaneously.

Formal track: HR and leadership must partner. Changes to performance reviews and compensation require executive sponsorship and HR. The critical shift is moving from measuring individual output to measuring team outcomes. No Scrum Master or Product Owner (PO) can do this alone.

Informal track: Leaders, Scrum Masters, and POs can start today. Public recognition, innovation events, speaking opportunities, and celebrating intelligent failures cost nothing and don't require HR approval.
 

There is an underlying principle for both tracks: people are motivated by things money can't buy — the freedom to choose how they work (autonomy), the desire to improve (mastery), and the need to contribute to something bigger (purpose). MIT research found that higher monetary rewards actually decreased performance in tasks requiring creativity. Before adding new incentives, organizations should audit whether existing ones are quietly undermining collaboration.
 

Additional resources:

 

What if your software has multiple modules? Does it make sense to have POs focusing on delivering value for those specific modules?

Before deciding on PO structure, answer a more fundamental question: are your modules separate products, or parts of one product? A product is defined by the value it delivers to known stakeholders and well-defined end users, not by the technology used to build it. 

If modules serve different user groups and are released independently, separate POs may be appropriate. If they're interdependent components of a single user experience, Scrum is clear: multiple Scrum Teams should share a single Product Owner to maintain a unified customer voice and avoid conflicting goals. 


A useful test to leverage; is each module a genuine business differentiator or a commodity? Differentiators deserve dedicated ownership. Commodities are often better served as shared platforms. When in doubt, start with one PO and delegate refinement responsibilities as the product scales.
 

Additional resources:


How can the Agile Product Operating Model succeed in enterprises reliant on 'body-shop' outsourcing? When time-and-materials contracts incentivize vendors to bill hours rather than deliver outcomes, how do we reconcile product thinking with a model where no one is accountable for value?

To reconcile product thinking with the reality of traditional outsourcing, organizations must move away from "buying hours" and toward purchasing capacity and outcomes. Advocate for shared-risk contracts where both parties divide expenses and share rewards, motivating collaboration toward common goals..Misaligned incentives cost both sides money through waste and rework.


Something you can do now would be to shift to "selling Sprints" with a fixed price per Sprint and customer termination rights. Embed OKRs targeting business outcomes and flow metrics (cycle time, throughput) in Sprint Reviews. Clarify budget, benefits, and scope at regular intervals to maintain shared understanding and focus on business outcomes rather than hours consumed. The uncomfortable truth is that these are workarounds for a fundamentally broken model. Product thinking requires outcome accountability. If your contract prevents that, you're optimizing a body shop, not building products.


Additional resources:

 

Very interesting session, and I recognize myself in your findings. The challenges I see based on my experience are how to change the organization's and management expectations in the right direction. How to avoid ending up in this situation repeatedly?

Start with their language, transition to empiricism. If your organization makes decisions via business cases, build one but structure it around Evidence-Based Management (EBM) principles.

For example, the business case could:

  • Define strategic goals using EBM's Key Value Areas (Current Value, Time-to-Market, Ability to Innovate, Unrealized Value)
  • Propose a 3-month pilot with one product team
  • Specify outcome metrics (customer retention, time-to-market, defect rates) not output metrics (story points, velocity)
  • Include decision criteria: "We'll measure results empirically and decide next steps based on evidence"


Evidence-Based Change allows organizations to iteratively invest in change, measure return on investment, and select the next changes to implement. Partner with the PMO. Frame APOM as enhancing portfolio effectiveness. The first step requires communicating the urgency for change to the CEO. Simply receiving numbers doesn't cause inspect-and-adapt; empirical process control must be established. The business case is the entry point, not the end state. Use it to earn permission for empiricism.
 

Additional resources:

Regarding middle management, we are trying to explain to our director and CEO that Scrum and Agile require consistency, especially around how decisions flow and how stakeholders provide input. When we bring this up, they sometimes feel we are trying to take away their authority, even though that's not the intention.

The real issue is that Product Owners don't fully run the development teams. Higher leadership often steps in mid-Sprint with new directions, and it's unclear which stakeholders we should rely on. Sometimes we are told to follow clients, other times leadership overrides those decisions without being available to act as stakeholders themselves. This makes it difficult to maintain stable priorities or deliver predictable outcomes.

We want to propose a consistent system for stakeholder communication and decision-making that still keeps leadership fully in control, while giving the team a clear and reliable process to follow.

Do you have any advice on how to communicate this effectively to them or how?

The real problem isn't who has authority; it's creating predictability while preserving your control. Currently, competing directions mid-Sprint make outcomes unpredictable for everyone. The solution isn't restricting leadership input; it's clarifying when and how that input shapes the work.

Start with a visual RACI with Sprint swimlanes:

For example:

Outside of a Sprint.

  • Leadership = Accountable for strategic priorities, 
  • PO = Responsible for translating to backlog

Inside a Sprint.

  • PO = Accountable for scope decisions, 
  • Leadership = Consulted for clarifications, Informed via Sprint Review


The Product Owner is accountable for maximizing product value. For Product Owners to succeed, the entire organization must respect their decisions, visible in the Product Backlog content and ordering. The Sprint container enables the transparency required for empirical process control.  Stability within the Sprint enables predictable delivery and faster feedback through working software.
 

Additional resources:

 

2026 biotech is defined by 'multi-modal' complexity (combining AI, biology, and hardware). How do you use the Product Backlog to force-rank these competing technical priorities when every lead scientist thinks their domain is the most critical?

You can't out-expert your experts, don't try. The Product Owner is accountable for maximizing product value and ordering the Product Backlog. The Product Owner may delegate responsibility to others but remains accountable. I recommend facilitating evidence-based prioritization against the Product Goal using these questions:
 

  • Which hypothesis has the highest uncertainty? Prioritize learning what we don't know over optimizing what we do.
  • Which integration point is the current bottleneck? In multi-modal systems, the constraint is often at domain boundaries (AI-biology interface, biology-hardware integration).
  • What's the minimum viable experiment? Can we test this AI assumption with synthetic data before building the full biology pipeline?


Run decision workshops where scientists present evidence for their priority claims, then collaboratively order the backlog. For change to happen, empirical process control must be established; simply receiving opinions doesn't cause inspect-and-adapt. You facilitate; the Product Goal and evidence decide.
 

Some resources you might find useful.

 

I've noticed that in the Biotech sector, the feedback loop is often much longer than a software Sprint. How would you advise a Product Manager to structure their Product Backlog to ensure we remain 'Leading with Evidence' when lab results take six weeks to return?

This tension between empiricism and domain physics exists across regulated industries, such as pharma, aerospace, and medical devices. The key is structuring work for continuous learning despite unavoidable delays. Structure your backlog to create multiple learning cycles, not just one. The experiment loop consists of forming a hypothesis for improvement, running experiments, inspecting results, and adapting based on what you learned. The entire feature need not be built to determine whether it's valuable—build enough to validate critical assumptions. 

Here is an example for biotech:

Decompose experiments into testable assumptions - Don't wait 6 weeks idle. What can you validate at week 1 (experimental design quality), week 3 (early indicators like cell viability), and week 6 (final results)?
 

Run parallel experiments - Test multiple hypotheses simultaneously with staggered timelines

Use intermediate measures - Leading indicators that predict outcomes (e.g., protein expression levels at day 7 may predict efficacy at day 42)
 

In the Biotech sector, if a biological experiment requires a 6-week lead time for results, the team still concludes their Sprints at the 4-week mark. They inspect the progress of the experiment (e.g., 'Was the sample contaminated?' or 'Is the equipment calibrated?') and adapt the Product Backlog. When the 6-week scientific feedback arrives mid-Sprint, it is treated as new evidence to be inspected at the very next Sprint Review to inform the next Strategic Goal or pivot."  This allows for a more strategic application of Evidence-Based Management in the product delivery process, while still working with the Professional Scrum framework.
 

Additional resources:

 

What did you think about this post?

Share with your network

Comments (0)

Be the first to comment!
Log in to comment