"I joined from that product team to this product team almost a year ago," said the Product Owner in the Mortgages team.
"What do you mean?" I inquired.
"Oh, I was in the Products & Propositions team before, creating new products, updating existing product rules, clarifying underwriting rules for brokers... that sort of stuff. But now, I'm playing the Product Owner role in change delivery," she replied.
"Do you find it different?" I probed.
"A lot different," she smiled.
This conversation took place during a workshop organised by the Agile Transformation Office (ATO) in a large financial institution, two years into their journey of implementing Scrum and SAFe. The Agile-Camp's frustration was palpable: " Execs are not getting the Product Thinking." The ATO wanted the organisation to " move towards a Product Model " hence the workshop with senior members from across the organisation, involving both change and run sides of the business. The agenda was filled with clichés: " moving from project management to product management," " establishing long-lasting product teams," and so on.
Getting such a diverse group into a room is a feat in itself, reflecting the ATO's clout with executive leadership and their substantial budget. As I reflected on similar sentiments echoed by agile consultants and coaches in recent LinkedIn posts, I felt compelled to write this.
Let's take a step back and examine these predicaments:
Do Execs really don't get Product Thinking?
If you're an agile transformation consultant or coach trying to influence the C-suite, let's first understand what they perceive when you say "product." Walk with me through their perspectives::
- Goods (Products) and Services: The most generic and widely held economic view is that "Products" are tangible goods, while services are intangible. This is the predominant view from the general public to governments when describing economic activity.
- Accounting & Finance's view: Closely matching the Economists view is the "Accounting & Finance" view of the "product vs service". They have some clear rules on what a product or a service means, how to capitalise, amortise, depreciate the investments and of course some creative ways of doing the same. They exactly know what they mean by product or a service, which I don't think matches with the views of many agile-camps.
- " Product in Marketing ": Turn around and you see, the core business offerings for which you have product teams already in place (even in "service industries" as classified by Economists). You already see Product Managers, their hierarchy / reporting structures, compensation models, a C-level exec like Chief Marketing Officer or Chief Commercial Officer etc. under these roles you find "Head of" roles (read Mortgages, Savings etc.), that are well defined. This "product function" emerged out of seminal works by Philip Kotler. Any organisation surviving since 1960s pretty much follows this construct when it comes to "Product". For them, Product is one of 4Ps of marketing, the other being Place, Price and Promotion.
- Products vs Services: Move along you find their IT team, who typically spend a significant portion of their change budget here, who in turn, do their best in "keeping the lights on". These are IT Service Management folks. They grew up by reading & implementing frameworks like ITIL. The recent version ITIL v4 asserts “products themselves have no real value but have only potential value”.
- Product vs Function: Further along the corporate corridors, you also have the "People function" also known as HR Function. These members are educated and experienced in people management, organisational design, organisational development etc. For them "Product" is one of many different ways to design an organisation, few others being "Functional, Divisional, Matrix" etc. In fact, the debate on Product vs Function based organisational structures isn't new. Harvard Business Review published an article titled " Organizational Choice: Product vs. Function " in 1968. There isn't a great deal we learned since then, on the relative advantages and disadvantages of these structures. We grew out of those into more "matrix-based structures".
Let's now go further and see what else the C-suite is exposed to. Ohh, yes, you find "Technology Consultants and Management Consultants".
With ever increasing role of Technology in transforming businesses, you cannot underestimate the influence of these Technology Consultants in getting significant mind-share of the C-suite. These technology consultants not just influence the C-suite but also influence the ways of working in delivering technology enabled change. A new paradigm these folks now propagating is " Product vs Platform ". Not just according to influential academics like Andrew McAfee and Erik Brynjolfsson (authors of The Second Machine Age and Machine Platform Crowd) and proponents of the platform economy, but also driven by the allure of many platform-based start-ups, their advise is clear: platforms, not products, are the future
Then there are Management Consultants. A wide spectrum here. But they are firmly under the grip of the thinking from business schools like Harvard or Sloan. If there is a Management Consultant who can get into C-Suite, then he / she must have exposed to the thinking like in the articles below.
https://sloanreview.mit.edu/article/why-service-businesses-are-not-product-businesses/
https://hbr.org/1978/07/strategy-is-different-in-service-businesses
https://hbr.org/1989/05/the-new-product-development-map
https://hbr.org/2012/05/six-myths-of-product-development
https://hbr.org/2013/05/a-better-way-to-think-about-yo
https://hbr.org/2016/09/putting-products-into-services
Now, my dear Agile guru, which product thinking you want the C-suite to set aside and replace it with yours?
I'm sure you are about to ask, "then what about Product vs Project and the advise that "long lasting product teams" as panacea, coming from many agile folks?" No, I didn't forget. I do agree, it is still peddled by influential people, quoting that elusive GAFAS affect; you have no choice but to believe.
Long lasting product teams, moving from project management to product management
Long lasting product teams is not the solution but the underlying reason for initiating projects. Most organisation already have long lasting product teams if you look into the whole organisation. They are adept at their trade. As they are long-lasting they just couldn't bring fundamental changes from new age technology solutions that significantly enhance their jobs. Hence they need Consulting companies to help them with, these consulting companies don't run the business for you, they come in for a specific period of time with a specific mandate, deliver the new tech-enabled solution and leave - the very definition of a "Project". If you keep them for long, they become exactly like the long lasting product teams you already have, even if you can afford their cost for that long. So you really don't want that long-lasting product team on change side of the business sitting on top of long-lasting product team on the run-side. Well, you do have an option of looking at end to end value streams and bring that run-side of product into change-side. There are a number of reasons why this is extremely difficult to achieve and is counter-productive. More over
value stream mapping as a visualisation technique is somewhat useful but value streams as an organisational-design construct has passed its "use by" date*.
There is nothing wrong in doing projects to support your product management team to significantly enhance their way of working and serve their customers better. By the way, the same GAFAS companies hired and still hiring loads of Programme & Project Managers. Don't believe me? Check their career websites.
That is the trouble with "product thinking".
- Execs do understand product thinking; it just doesn't align with the agile camps' view.
- Many organisations already have multiple product models; they don't need another.
- Projects are valuable if they deliver value.
- Rebranding roles like Delivery/Project/Programme Managers as Product Owners or Product Managers or Release Train Engineers won't always bring the expected change.
In short, "product thinking or models" isn't the solution to many problems you aim to solve. Revisit the problem statement and look deeper.
On that day
During breaks, a few participants admitted their confusion and few said, "this isn't going anywhere". But in the main sessions, there was a weird silence. Despite discomfort, frustration & confusion, there is a forced march forward. Clichés from the agenda were repeated, sub-committees formed, decided to meet again in few weeks for yet another round of full-day workshop. The cab ride back to the train station wasn't exactly a victory lap, more like a sulking session fuelled by lukewarm coffee.
"Am I the kid on the street saying the Emperor has no clothes", I wonder
If you are from the C-suite constantly hearing this nagging from your Agile Transformation Office, then connect with me. I can help.
*a big statement, more on that in a different post.