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:
- 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.
- 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.
- 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.
- 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?
- 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?
- At your company, are products defined by a technology managers and architects, or business people? What impact does it have on customer centricity?
- Do multiple back-end applications get integrated into a single product way too late in a process, resembling a classic waterfall?
- Does it feel that coordination between so many, so-called, products is unexplainably hard, time consuming and expensive?
- 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?
- Does it feel that product managers and products owners, “manage and own” in spirit only, and are, mostly, disempowered?
- Do you feel that technology people lack basic understanding of business, whereas business people have lost their trust in technology?
- In your organization, does technology dictate “what agile is” and expect business to follow?
- 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?
- Does it seem that there are too many local initiative owners, whose priorities compete for budget, and whose personal agenda prevails over collective agenda?
- Does it seem that legacy resource management/sharing and skill set capacity allocation are being applied to agile (adaptive) ways of working?
- Is executive management disengaged from strategic discussions that define value?
- Does executive management set strategic priorities?
- Is there a lack of synergy between business strategic goals and technology strategic goals?
- Is there a lack of effective collaboration among technology teams, and between business and technology?
- Are people still confused with how to focus on products in an environment of portfolio-to-program-to-project management?
- Is there a confusion between portfolios of true-real products and traditional budgeted work, loosly called “portfolios”?
- Is there a misalignment between strategic goals, product roadmaps and product backlogs?
- Is there a confusion between outputs and outcomes, defined by short-term and long-term plans?
- Is there a confusion between true product/feature teams and component/application/delivery teams?
- Is there a gap between financial decisions/costs and product prioritization decisions?
- Are there challenges in identifying meaningful metrics and separating them from vanity (gaming) metrics?
- Is there confusion about what should be included in executive reports?
- Is there a confusion when to apply: Scrum, XP, Large Scale Scrum, Team Kanban, Enterprise Kanban?