How to manage a program in a product-mode organization

Programs in Product-Mode: A Cautionary Tale

Product-mode organizations excel at building durable, autonomous teams that continuously deliver value. But when a genuinely cross-cutting opportunity emerges — one that requires coordinated work across several product streams — these same organizations often stumble. We call these cross-team initiatives programs, and they present a distinct set of management challenges that differ from running a single product team.

To illustrate what goes wrong, we’ll walk through a fictionalized example inspired by real-world engagements: a South American digital-first bank attempting to launch a business banking product. The scenario and its lessons are instructive for any product-mode organization facing a similar program.

Why programs break product-mode assumptions

Product-mode organizations tend to structure themselves to minimize cross-team coordination, often mirroring their internal microservices architecture with small, independent teams. Each team owns its own backlog and operates with a high degree of autonomy. This is great for steady-state value delivery, but it creates friction when a single initiative requires alignment across multiple of those teams.

The structural friction shows up in a few predictable places:

• The existing operating model rarely fits a program's needs, which require a different kind of flow across team boundaries.
• Programs benefit from standardized delivery practices across streams, but autonomous product teams typically have diverged in their own preferred processes.
• Leadership styles that work for a single, cohesive product team do not automatically translate to leading a set of teams with potentially competing local priorities.

A working example: a new customer segment goes sideways

Our fictional fintech company grew from a startup into a ~200-person product division organized along squad and tribe lines, closely mapped to its product architecture. After research, they saw a strong opportunity to move into business banking, and set an aggressive few-months deadline for an MVP.

Three leaders from existing product teams — a design lead, a technical lead, and a product manager — were tapped to run the effort. They spent time on discovery and produced a clear MVP scope: a new business account product, business customer login, and transaction viewing. The work clearly spanned multiple existing teams that owned the web frontend, customer CRM, transactions API, auth platform, and product catalog.

Each of these teams was accustomed to running its own self-directed delivery process. Some used structured agile with epics and estimates; others preferred loosely-defined goals broken down into small tasks. In an effort to preserve the autonomy that had served them well so far, the trio of program leads chose to present the vision to each team separately and let them figure out the necessary changes on their own.

The approach backfired. The separate pitches combined with heterogeneous processes meant the program leads had no clear line of sight to the dependencies embedded in each team’s interpretation of the high-level story map. When they ran a retrospective at the end of the fiasco, the root causes surfaced clearly.

What actually went wrong

The retrospective pointed to several compounding failures — none of which were about the intrinsic difficulty of the product itself:

• The operating model didn't change. Due to a desire to protect team autonomy, the program leaders didn't adjust how the value stream flowed, so teams optimized their local delivery rather than the holistic goal of customer value.
• Leaders weren't empowered. Organizational leadership couldn't effectively influence outcomes because status information about the program was nearly impossible to obtain.
• Updates measured the wrong thing. Progress was reported per delivery team, not as one coherent, working solution addressing the customer need. Teams never understood how their individual work contributed to the broader program.
• Risk was treated as an aside. There was no explicit, program-level risk management — it was assumed each team handled it internally. The inevitable surprises kept pushing out the delivery date.
• Dependencies went underground. Without managed cross-team dependencies or an incentive to collaborate across those boundaries, tensions flared, degrading the team environment and morale.
• Leadership communication failed to adapt. The trio's communication style never changed to fit the context of a multi-team program, leaving a false sense of alignment based on the incorrect assumption that everyone possessed the necessary information.

The result was predictable and painful: missed deadlines, frustrated customers, wasted capacity across all the involved teams, and a demoralized workforce. The root problem wasn't the ambition of the business goal, but the failure to treat the program as a genuinely new mode of working that demanded new behaviors from its leadership.

Setting programs up for success in product-mode organizations

Product-mode organizations often struggle when initiatives require cross-team coordination. The discipline needed for program delivery can clash with the autonomy that product teams are used to. Below are practices we've used successfully to navigate these challenges.

Invest upfront in kickoff workshops

The beginning of a program offers a natural pause point to run workshops that set teams up for success. By the end of the kickoff, business stakeholders and team members should understand the initiative's significance, their role in it, how it will be delivered, and the high-level scope of the first release. This upfront investment is proper risk mitigation against a multi-month missed delivery date. Kickoff workshops should aim to:

• Align all stakeholders on what needs to be done and why, including any changes to the operating model.
• Define consistent ways of working, ceremonies, and best practices.
• Socialize the business, technical, and customer context with all teams involved.
• Build trust by making explicit the roles, responsibilities, and motivations of individuals.
• Lay a foundation for empathy and understanding within the team.
• Surface risks, dependencies, assumptions, and complexity in the delivery.

An example kickoff schedule designed to address these outcomes might look like this:

Adapt leadership style to the program's demands

The culture in a product division may not be receptive to the urgency and process standardization that program delivery requires. Program leaders, acting as solution champions, often need to adapt their leadership style to the situation.

The situational leadership model offers a useful description of communication styles across leadership states. In the ideal state, leaders of self-organizing product teams involve and empower their teams. However, when a program requires an operating-model change that challenges the teams' self-organizing nature, leaders may need to spend more time clarifying and defining than they're used to.

Beyond changing communication style, program leaders must keep teams accountable for upholding the new operating model. A responsibility assignment matrix (RACI matrix) is a commonly used tool for this: it helps team members understand what's expected of them regarding process standards and attendance at critical program meetings.

Manage dependencies and risks diligently

Dependencies between teams (known as backlog coupling) are common in program delivery, since multiple teams own different pieces of the solution. A good practice is to frontload the program with activities that decouple team backlogs, enabling teams to deliver more autonomously.

In our example, the program team might spend its first few iterations swarming around building a walking-skeleton. Assuming a mature continuous delivery setup, the walking-skeleton can be deployed to production behind feature flags, so future progress updates focus on its evolution as product teams add fidelity and scope. Here's an example release plan showing where the walking-skeleton swarm team fits into the product roadmap.

In the example above, the walking-skeleton would have consisted of the entire MVP user journey but with little time invested in UI fidelity. All API integrations would be stubbed, and data mocked and hard-coded. The walking-skeleton isn't intended for customer use; rather, the goal is to resolve much of the work that couples product teams to each other before they proceed with their own backlogs. Once built, it also lets all teams continuously integrate their code, mitigating the risk of late integration.

Active risk management as part of the normal iteration cycle is imperative, but it isn't always part of standard product delivery. The leadership team may need discipline to keep the momentum going throughout delivery.

Develop a strong communication strategy

A large part of program coordination effort is communication. Its purposes are to:

• Keep all relevant stakeholders informed and give them a chance to raise issues and ask questions.
• Facilitate cross-team communication to relieve delivery bottlenecks.
• Surface blockers to the program leadership team so they can help alleviate them.

Given this overhead, program leadership should create a communication strategy with touch points that satisfy each stakeholder group's needs. An example strategy might look like this:

Use visual artifacts for information radiation

Visual artifacts like a physical program wall can be excellent information radiators, benefiting key stakeholders and the entire company.

A program wall may start as an isolated initiative, but keeping it up to date and forcing conversations around it can create new organizational habits and disciplines. Physical walls can additionally promote collaboration and accountability among teams. They can prompt questions from others in the company, who can consume information quickly without scheduling time with anyone.

An ideal program wall contains just enough information for a status update at a glance. In the example above, the swarm team has completed its work and disbanded, and delivery teams are working through their deliverables — with one team needing assistance to remove a future blocker.

Embrace a defined program management role

Program management discipline is crucial when an initiative requires orchestrating and coordinating multiple teams to deliver value. The actual role definition and responsibilities depend on organizational context and program complexity, so we prefer the term “solution champion” over “program manager.” Fundamentally, someone must own the overall health of the initiative, focusing on these strategic elements:

• Continually ensuring alignment between teams.
• Ensuring smooth communication between teams and external stakeholders.
• Keeping relevant and critical information fresh.
• Managing program dependencies and risks.

Make the role's responsibilities explicit to everyone involved, preferably at the program kickoff. A risk we've observed is that product team members and the solution champion end up with overlapping responsibilities, making both roles less effective. Solution champions should focus on strategic aspects, not tactical product delivery tasks. The RACI matrix below shows the separation of responsibilities:

Note the separation of accountability between the solution champion and product delivery leadership and team.

Conclusion

Once a program has been identified, a change in operating model is required to deliver value to the customer. The practices above can put the program on a path to success, but there's no silver bullet. Whatever mechanisms you choose, put in place a feedback loop with program constituents so you can learn and adapt whenever necessary.