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 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)?
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.
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:
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.
RSS feed
