What is your “Product” Operating Model?

Analogy: Your Restaurant Experience

By way of analogy, imagine you come to a restaurant and willing to spend a lot of money on a bowl of an expensive and exotic soup. You sit at a table and wait for your dish to be delivered. When a waiter comes, you see that on his tray, there are raw ingredients that are used to prepare a soup, but there is no actual soup. You are puzzled. This is not what you are prepared to pay for. Each ingredient, although the required constituent of a final product, is not a product in itself. Even if a waiter, head chef and restaurant owner tried to explain to you that ingredients also cost money, and are [raw] products on their own, you still have a strong reason to be unhappy, as you were willing to pay your money for something that you could consume immediately upon delivery: a delicious, exotic soup. As a customer, if you do not receive what you paid for, you would be unhappy an, probably, ask for your money back, and not come to this restaurant ever again.

What Is Operating Model

What is an operating model? This is the term that companies use, to describe their internal ways of working. Essentially, instead of using a term that may suggest the adoption of a commercial, off-the-shelf solution, a.k.a. framework, companies prefer creating their own, language that creates an impression of a home-grown, unique, sophisticated and tailored approach. Thus, the term: OPERATING MODEL.

The reluctance to use a large, commercially widespread, populistic, “unpack & install” solutions is understandable, especially, given the historical “dark side of agile business” that involves a lot of relabeling and “terminology mapping“. But of course, it always begs the question: how unique is each company’s situation that it justifies spending time, money and energy on a custom special operating model (a.k.a. framework)?

What Is “Product” Operating Model

Following the same train of thought, a PRODUCT” OPERATING MODEL (quotes around the word product are intentional) implies that a company’s ways of working are optimized for product development and delivery (it also assumes customer/user centricity). This further assumes that a company’s* organizational design* is improved to support a product operating model. More specifically, instead of defining “products” around traditional volumes/scopes of work (portfolios, programs, teams’ capabilities, teams’ private technical backlogs), real products should become a leading factor that dictates how teams (also, the rest of an org, involved in product development) should be structured, what capabilities they should have and what information should be kept in product backlogs. Traditional ways of managing work (portfolios, programs and projects) should become trivial and, eventually, seize to exist. For majority of organizations, this means 180 degrees course correction to their agile transformation.

The analogy above (an exotic soup) is synonymous to a product development situation, when at the end of a sprint (sprint review) users are presented with multiple technical components that were built by a scrum team but not not fully integrated into complete features. This kind of a sprint review, very quickly, becomes a low-interest event for business people and they stop attending it.

Lack of product centricity in sprint-work is often caused by lack of teams’ capabilities, to deliver front-to-back product features, without external dependencies. This is the problem of organizational design. If a team is designed, as a component/delivery team, its end-of-sprint delivery is a technical component, not a product feature, and therefore, of low interest to business people.

This lack of product centricity in team design can be further traced to a weak (fake) product definition, with each team, adopting a belief that they develop a “mini-product” or a “sub-product”.

At scale, and especially in organizations that rush to make a political claim that they have become a true product organization (large banks is a good example), this leads to what is a.k.a. Productization Saga – each and every body of work becomes a product.

Today, for many organizations, an internal “product operating model” is just a part of a much bigger Agile Theater Chaos.

Unless we see deep systemic improvements that involve changes to a reporting structure (flattening), removal of boundaries between traditional vertical silos (departments, groups) and ownership-by-technology areas (platforms, shared services), reduction of local management, in favor of self-management,** these product operating models will remain being just a fancy term, without much meaning.** Because of that, over time, some roles, maybe, even entire job families, such as fake program managers and product owners (with no real products to manage and business priorities to own) and agility leads (ex-no-longer-needed roles, fabricated just to keep people busy) may have to be reduced (RIFed), as non-essential, because they do not measurably contribute to ROI.

Are There Alternatives To This Chaos?

Yes, indeed, your daily reality does not have to be as unattractive and depressing as described above.

There a couple things you could do to improve the situation:

1. First, think holistically, and try to understand what would make your organization survive and prosper in the world of high-pace competition and AI. Here, what may come to rescue is understanding of how to drive Business Resilience in complex and dynamic markets.
2. Second, try to move away from the stale belief that organizational structure of your company is an untouchable “no go zone”. Do not treat traditional, legacy and oftentimes outdated functions, roles, departments etc. as perpetual elements. Everything in life evolves and so should your organizational structure. Once you overcome this mental blockage, it will be much easier for you to rethink your product definition and make it drive the optimal definition of your organization structure, not the other way around. You will see how, miraculously, your sub products, sub-sub products, “tech for tech” products, “area” products, components-as-products, and other “blah” products start disappearing.
3. Lastly, spend some time studying, how some of these problems been addressed and resolved by other companies that took things seriously and decided to improve themselves not just on paper/for PR but for real. Please review the following case studies.

Want More Help With Your Organizational Challenges?

The below list of challenges (top 25 are listed but there could be more) indicates that your agile transformation’ is offtrack and your ‘product operating model’ does not work. If you recognize that you are having a problem, you may wish to rethink if/how you wish to proceed further, because the further and for longer you move in a wrong direction, the more difficult it would be to course-correct later.

If you feel that you need help, in the form of an assessment, reflection, private consulting, training or extended coaching support, please reach out. Do not wait until it becomes too late.

Lastly, on May 2, please attend this free webinar “Using System Thinking & Modelling to Solve Tough Organizational Problems“, delivered by Certified LeSS Trainer and Coach Gene Gendel and hosted by Lean, Agile and Large-Scale Product Development (LeSS) Global Community. Some of your pressing questions could be asked there.

1. In a rush, to become agile, did your organization adopt an “operating model”, by incorrectly copy-pasting something that has been well known in the industry for years but required a much deeper understanding, before implementing?
2. In pursuit to become product-centric organization fast, did your end end up with tons of products-wanna-be, such as: “area products”, sub-products, technical products, “tech-for-tech” products, “no_real_customers_no_human_users” products?
3. At your company, are products defined by a technology managers and architects, or business people? What impact does it have on customer centricity?
4. Do multiple back-end applications get integrated into a single product way too late in a process, resembling a classic waterfall?
5. Does it feel that coordination between so many, so-called, products is unexplainably hard, time consuming and expensive?
6. Does it feel that the financial/budgeting aspect is missing from product management/ownership and is handled by org structures that are too distant from product management/ownership/development?
7. Does it feel that product managers and products owners, “manage and own” in spirit only, and are, mostly, disempowered?
8. Do you feel that technology people lack basic understanding of business, whereas business people have lost their trust in technology?
9. In your organization, does technology dictate “what agile is” and expect business to follow?
10. Do you feel that too many locally optimized, mid-level managers are focused too much on their own, personal successes that frequently do not add up to a collective success?
11. Does it seem that there are too many local initiative owners, whose priorities compete for budget, and whose personal agenda prevails over collective agenda?
12. Does it seem that legacy resource management/sharing and skill set capacity allocation are being applied to agile (adaptive) ways of working?
13. Is executive management disengaged from strategic discussions that define value?
14. Does executive management set strategic priorities?
15. Is there a lack of synergy between business strategic goals and technology strategic goals?
16. Is there a lack of effective collaboration among technology teams, and between business and technology?
17. Are people still confused with how to focus on products in an environment of portfolio-to-program-to-project management?
18. Is there a confusion between portfolios of true-real products and traditional budgeted work, loosly called “portfolios”?
19. Is there a misalignment between strategic goals, product roadmaps and product backlogs?
20. Is there a confusion between outputs and outcomes, defined by short-term and long-term plans?
21. Is there a confusion between true product/feature teams and component/application/delivery teams?
22. Is there a gap between financial decisions/costs and product prioritization decisions?
23. Are there challenges in identifying meaningful metrics and separating them from vanity (gaming) metrics?
24. Is there confusion about what should be included in executive reports?
25. Is there a confusion when to apply: Scrum, XP, Large Scale Scrum, Team Kanban, Enterprise Kanban?

AI, of course, can be used to improve the performance of individual single-skilled specialists, and this is what we see as of 2025, but there is a large landscape. Let me share.

AI-Supported Org Design (“AI OD” for short) will be becoming a hugely impactful topic affecting all of us and all the organizations in which we work.

AI OD is the strategic practice of applying AI (agents and other upcoming innovations) to continuously inform, accelerate, and personalize how an organization is structured, how it evolves, and how its people learn.

It’s not about replacing managers or employees (!) —it’s about empowering us to design adaptable, resilient orgs with fewer structural overhauls and more intelligence baked into the day-to-day.

☝️ The core organizing principle: AI Makes Versatile Teams Viable.

☝️ The core operating principle: With Multi-Learning as the Engine.

How do these principles differ from applying AI to get individual performance gains? Let me unpack this slightly.

Strategic AI Application

If we unpack these two principles, then we can see that this is all about applying AI to support an organization’s development direction and accelerate its evolution to gain high performance and other competitive advantages. That is a strategic AI application.

Some guides and practices to focus on here:

👌 #1: Multi-Learning as the Engine: Especially in Adaptive Topologies (see Org Topologies Primer for details), learning—not just delivery—is the primary currency. AI enables this by making the unknown known and the unlearnable learnable and with ease. Sample scenarios:

• A backend developer shadows a customer support session and begins contributing to onboarding scripts/
• A frontline support agent learns enough Python to automate common diagnostic steps, reducing ticket escalations and easing the load on developers/
• An end-to-end team includes privacy review and data protection steps in their regular sprint workflow—not because they were forced to, but because someone on the team got curious, shadowed legal, and brought that knowledge back in.
• A delivery manager starts using AI tools like Cursor or GitHub Copilot—not to replace anyone, but to better understand how her teams are using it, what it’s good at, and what the current limits are.

👌 #2: Learning Becomes the Flow: AI agents will suggest relevant prior work and recommend 5-minute learning prompts when patterns emerge. AI agent says to a team:

“Team X solved this two sprints ago.”
“Want to see how testing was solved in a similar sprint?”

👌 #3: Matching of Work-to-Skill in Real-Time: Rather than static org charts or disruptive reshuffles, AI supports the continuous alignment of skills to work based on live data and evolving interests, and when multi-learning is too expensive, AIs will suggest micro-reteaming without major upheaval as a temporary, quick-fix solution.

That’s what Org Topologies offers as a field guide for leaders in this disruptive era of AI we all happen to live in, in collaboration with Roland Flemm and Craig Larman.

In the last months, I’ve had many conversations in the LeSS community as well as in the product I work for, about Requirement Areas. From those discussions, I’ve discovered new ways of explaining them. Here, I’d like to share some of these.

What are Requirement Areas?

Requirement Areas is a grouping of items on the product roadmap used to create a view on the Product Backlog. This view helps us structure the teams accordingly.

Then what is the product roadmap? A product roadmap is a high-level view of the Product Backlog. In the LeSS books, Craig and I talk about items in the backlog that can have ancestors. Nowadays, I refer to items that have ancestors as “roadmap items”. Together they form a high-level view of the Product Backlog, which is usually referred to as the Product Roadmap. Requirement Areas is a grouping or categorizing items on the product roadmap that we use for structuring the work.

Why Requirement Areas?

The original reason for starting this grouping, which began about 20 years ago with the first LeSS Huge adoption, was to support the Product Owner in keeping an overview of the development and prioritization. By having a grouping, we can create a view of the Product Backlog according to this categorization and structure the teams and PO around this. This enables us to scale from roughly 8 teams to any size product development.

Requirement Areas also give other benefits since they help in facilitating multi-team events. An area is always between 4-8 teams, so the multi-team sessions always have a reasonable amount of people to use practices as mixed-up groups in multi-team Product Backlog Refinement.

How to create Requirement Areas?

Creating Requirement Areas is not hard. The hardest part is that they are different from structures that people are used to. To create them, you need to understand what the main functionality will be the focus in development for the next year(s): the product roadmap. When you have that, do the following:

1. Group related items in the roadmap that are related to affinity.
2. See if you can think of a name.
3. Imagine how many teams would be required to work on these.
4. If the number of teams is smaller than 4, go to step (1) and redo the grouping or combine categories.
5. If the number of teams is larger than 8, consider splitting the category or revisit (1) and try again.

Notice: The key factor that defines an area is the number of teams working there because the purpose of areas is to structure the work. Never have areas smaller than 4 teams.

What are not Requirement Areas?

There are a couple of common mistakes when using Requirement Areas. The biggest one is to have small areas (smaller than 4 teams). This is resolved by adding two small ones.

Other common misconceptions are:

• Confusing them with Product Areas. A Product Area is a grouping of functionality in the product and not a functionality in the roadmap. This difference is significant! Your product might have a large amount of functionality related to “financial reporting” but when you do not plan to build new functionality in financial reporting, then you would never have a Requirement Area for that. For creating areas, look at the roadmap, not the product.
• Using the Product Architecture for creating Requirement Areas. A Requirement Area is a grouping in the roadmap, not a split based on architecture. When you split based on architecture and structure teams accordingly, that is referred to as Development Areas. These are not recommended because all the component team dynamics will manifest in development areas.
• Requirement Areas are often viewed as separate Products. Organizations frequently transition from many small products to one large product when adopting LeSS. During this process, they often confuse Requirement Areas with what they previously called a Product. This situation aligns with the misconception (2) but is common enough to warrant explicit mention.

There is a lot more to say about Areas, but for this blog, I’ll leave it here. More in the next blog.

In this episode, we have the privilege of having Mauro Sacchi, an esteemed leader in digital R&D at Wärtsilä, whose innovative approach and vast experience in transforming traditional industries into agile powerhouses.

I’m excited to share our transformation story at Wärtsilä, where we’ve embraced Large-Scale Scrum (LeSS) principles to break down organizational silos and unlock our teams’ full potential. This journey wasn’t just about implementing a framework – it was about fundamentally changing how we approach product development and team collaboration.

The Challenge: Fragmented Firepower

When I took over leadership of our digital R&D organization three years ago, I encountered two critical challenges:

1. Inability to direct our firepower to the most valuable work - Our organization was fragmented into silos, with over 10 teams each maintaining their own separate backlogs.
2. Human potential diminished by hierarchical structures - Brilliant people with advanced degrees in physics and mathematics were being treated as mere code producers rather than valuable contributors to product decisions.

Let me illustrate this with a real scenario: One team was working on something extremely valuable for a customer who had complained about our development not meeting promises. Meanwhile, other teams couldn’t help because they were bound to their own backlogs and priorities – even though those priorities were objectively less valuable.

The LeSS Revelation

Though I’d been a Scrum practitioner since around 2007, I hadn’t been exposed to LeSS until taking this role. When my predecessor mentioned the organization was founded on LeSS principles with a Spotify model, I did what any responsible leader would do – I studied up and enrolled in the first available training with Bas Vodde.

That training was nothing short of a revelation. It wasn’t about falling for a theoretical framework (I’m not easily lured by process-heavy approaches). Instead, LeSS addressed my two concrete problems through two powerful principles:

1. One product, one backlog - A clear approach to prioritization based on customer value
2. People at the center of value creation - Recognizing that human potential drives success

The Big Bang Approach

We decided to implement the change in one go rather than incrementally. Why? With around 10 teams, we needed a meaningful critical mass to truly make a dent in our agility. So we merged all previous backlogs into one and elevated the role of the product owner.

This created what I call “necessary friction” – the productive tension that forces meaningful conversations about what truly matters to customers. Many organizations avoid this friction by creating silos, but that’s a missed opportunity for value creation.

“When you start to question and challenge, especially when you put items in competition with each other, you create friction. In my view, that friction is absolutely positive – it’s a dialogue you need to have for proper product ownership.”

Product Ownership: Not for the Faint-Hearted

In a LeSS organization, product ownership is a serious role that requires making hard decisions. The product owner isn’t just a requirements analyst – they must mediate across multiple organizations and customer requests to create one prioritized backlog.

This isn’t about being “nice” or popular. It’s about having the courage to say “no” or “not yet” to stakeholders, which can be politically challenging in a large corporation. Sometimes you need to compromise, but the focus must remain on maximizing value.

In our context, we have a product owner who owns the product we develop, while product managers from various organizations process customer requests to this product owner. Our product isn’t sold standalone – it’s part of a bigger ecosystem of services, which adds complexity to these relationships.

Unleashing Human Potential

Perhaps the most rewarding aspect of our transformation has been seeing our people flourish. In traditional industrial settings, software teams are often treated as IT service providers who simply code what they’re told. But in our world of maritime and energy equipment, software has become a critical engineering discipline that should sit at the same table as mechanical and electrical engineering.

This represents a massive cultural shift for corporations that don’t have software in their DNA. It means elevating software engineers to work alongside other disciplines to solve problems together – that’s true product development.

The results? Teams taking ownership, caring about the work they do, and helping each other regardless of their comfort zones. When it clicks, it’s a pleasure to witness.

“I see teams with excellent positive dynamics because they embrace the simple principle that we are doing product development. The success of my team is the primary objective for value creation, and I do whatever it takes to help that team succeed and deliver value to customers.”

Not a Walk in the Park

I want to be transparent – this journey hasn’t been easy. Some individuals don’t want to work in an environment where more is demanded from them. Some truly just want to code and be told what to do. We’ve been adamant that people belonging to teams need to do their best to make the team successful, even if it means working outside their comfort zones.

We’re also bridging two cultures – the software domain and the mechanical world – which operate at different speeds and often involve different generations. The youngsters need to respect the deep domain knowledge of experienced mechanical engineers, while the mechanical engineers need to recognize software engineering as a distinct profession requiring its own expertise.

The Long Game

Creating this culture takes time. While there are quick wins, building an organization with this mindset is a long-term journey. We’re far better than we were three years ago, but we’re still learning and growing.

For organizations considering a similar transformation, remember that you need to play the long game. The necessary friction will never (and should never) completely disappear – if it did, that would signal a return to silos and disconnection.

Final Thoughts

If you’re considering implementing LeSS in your organization, I’d recommend the training not just for product developers or coaches, but especially for organizational leaders. The principles of LeSS are fundamentally about designing organizations to succeed from both human and structural perspectives.

And if you’re in the middle of this journey already, remember: don’t give up. It’s worth it.

• Mauro

Podcast with Ben Maynard and Mauro Sacchi

Listen to the podcast, below, or here at the Product Agility website

The LeSS City Guide Simulation is an interactive, hands-on activity designed to help participants experience the dynamics of multiple teams working together on a single product.

In this updated version of the Nexus Zoo simulation, the focus is shifted to a practical project: creating a city guide for the city where the training is taking place. Unlike the Nexus Zoo simulation, this exercise incorporates events typically seen in LeSS adoptions, such as a Self-Design Team Workshop and Multi-Team Refinement, to better simulate LeSS dynamics.

This activity helps participants understand how multiple teams collaborate to achieve a shared product goal, offering insights into the challenges of scaling Scrum. It is usually conducted before introducing the events in LeSS to highlight the differences between LeSS and Scrum.

Materials Needed

To run the LeSS City Guide Simulation, you will need the following:

• Colored voting dots (green, red, blue, yellow)
• Large post-its
• Colored A4 paper
• Pens and markers
• Transparent binder and puncher
• Stopwatch or timer

Step 1: Self-Design Team Workshop

The simulation begins with a Self-Design Team Workshop, where participants form their own teams. The trainer provides colored voting dots representing key skills needed for the work:

• Green Dot: Good knowledge of the city
• Red Dot: Good drawing skills
• Blue Dot: Beautiful handwriting
• Yellow Dot: Tripadvisor on the phone

Each participant selects dots corresponding to their skills, making them visible on their name tag. Teams are then formed with 4-5 people, ensuring a balanced mix of skills across all teams.

Step 2: Multi-Team Product Backlog Refinement

Once teams are formed, the Multi-Team Product Backlog Refinement event begins. The Product Owner (PO) — who could be the trainer or, preferably, a co-trainer — presents the product goal: creating a local city guide and getting feedback on it as soon as possible. The initial items for refinement include:

1. Cover Page
2. Must-See Attractions
3. Museums
4. Restaurants
5. Hidden Gems
6. Current Events

The PO uses large post-its for each of these items, presenting them in the order above. Items are distributed for refinement, with one item given to a group of 3-4 participants, which should be a mixed group across teams.

The goal of each group during refinement is to create:

1. A suggested list of items (e.g., top 5 attractions)
2. A layout of the page (what it should include and where - eg. drawing of the attraction, map, etc.)

After a time-boxed refinement session, all participants walk around the room, and each group presents their work. A second round of refinement may follow to add further details if needed.
At the end of the Multi-Team PBR, the PO collects the post-its with the most interesting items (e.g. Must-See Attractions, Museums) to create the backlog.

Step 3: Definition of Done (DoD)

The Product Owner presents the Definition of Done on a flipchart or large post-its, covering the following:

• One page per item
• No two consecutive pages of the same color
• One integrated product
• One common copyright at the bottom center of each page
• Clear handwriting; no grammar mistakes

Step 4: Sprint Planning

Sprint Planning follows, during which the PO presents the top backlog items and asks which team will take each item, one by one. The list will usually look like this:

1. Cover Page
2. Must-See Attraction 1
3. Must-See Attraction 2
4. Museum 1
5. Museum 2
6. Must-See Attraction 3
7. Museum 3

The teams take as many items as they think they can complete in the given time for the Sprint.

Step 5: The Sprint

The Sprint starts, and the facilitator sets a visible timer. Teams use the time to complete an increment that meets the Definition of Done. The facilitator and/or PO should stay available to answer questions but avoid interfering unless needed.

Step 6: Sprint Review

When the Sprint ends, the Sprint Review takes place immediately, during which the completed work is inspected. The trainer sets a timer to keep the Sprint Review concise.

Step 7: Team and Overall Retrospective

After the Sprint Review, each team holds a Team Retrospective to discuss what went well and what could be improved. Afterward, the entire group participates in an Overall Retrospective, which includes the PO. This retrospective focuses on systemic improvements for the next iteration.

Common Challenges and Learning Opportunities

The simulation reveals several typical challenges, especially in the first iteration:

• Lack of Communication with the PO: Teams often do not ask the PO questions about the product, such as the city guide title or copyright. In LeSS (like in Scrum), the PO is accountable for maximizing the value of the product resulting from the team’s work and should involve the team in product decisions while retaining authority over key decisions.
• No Integrated Product: Participants often miss the tools for integrating pages (e.g., puncher and binder) and usually just present individual pages. In LeSS, it is important to have an integrated product that is handed over to stakeholders (e.g., customers) at the end of the Sprint.
• Delayed Integration: Teams often integrate their pages into the binder only at the end of the Sprint, rather than continuously as pages are completed. In LeSS, continuous integration is encouraged to avoid last-minute issues and increase learning by observing what other teams are doing.
• Insufficient Communication Between Teams: Teams often struggle to coordinate on items that should be consistent across all pages (e.g., copyright). In LeSS, team members are encouraged to coordinate directly by walking over and discussing whenever needed.
• Unfinished Pages: If pages are incomplete at the end of the Sprint (e.g., drawing is not finished), the PO may add these items to the backlog for the next iteration.

Step 8: Debrief

The simulation usually involves at least one more iteration to allow teams to apply their improvement strategies and learnings. At the end of the simulation, a debrief session takes place to highlight key takeaways. Common debrief questions include:

• What differences do you see between Scrum and the way you worked in the simulation?
• What worked well in terms of communication between teams? What challenges did teams face in coordinating with each other? How did you ensure consistency across different pages?
• How did delayed integration affect the final product?

Suggested Timings

• Multi-Team Product Backlog Refinement (PBR): 8 minutes
• Sprint: 10 minutes
• Sprint Review: 3 minutes
• Team Retrospective: 3 minutes
• All other events: As long as it takes

Facilitation Tips

This section provides helpful tips for facilitating different parts of the simulation to ensure a smooth and effective learning experience.

• Multi-Team Product Backlog Refinement (PBR): The PO should offer one item at a time (one item for a group of 3-4 people). Teams sitting at their team tables should decide how to split into different refinement groups. The PO can answer questions about what should be done but should not be overly involved in discussing details.
  In order for the PO to easily create the backlog at the end of the PBR, distribute large post-its and ask the teams to use them for the suggested attractions, museums, etc.
• Sprint Planning: Ensure that instead of one team picking similar items (e.g., two museums), those items are distributed across multiple teams to promote cross-team learning and adaptability.
• Sprint Execution: As a facilitator and/or PO, provide honest feedback on participants’ work but avoid giving direct guidance on how to proceed. Instead, encourage participants to think for themselves. For example, when asked about specific product details (e.g., copyright), respond with questions that prompt participants to come up with their own solutions. If asked how to coordinate that every team uses the same copyright, say, “I don’t know. What do you think?”

The LeSS City Guide Simulation provides an engaging, practical way for participants to understand the challenges and dynamics of multi-team Scrum, focusing on collaboration, handling dependencies, and continuous improvement.