How will banks equip and empower Two Pizza Teams (TPTs) after PSD2?

In a business world overrun with Three Letter Acronyms (TLAs), it seems unfair to add another one. The Second Payment Services Directive (PSD2) that covers the European Economic Area (EEA) has added to the pile of TLAs. We now have Payment Initiation Services (PIS) and Account Information Services (AIS). These services can be provided by new Third Party Providers (TPPs). A similar regulatory initiative in the UK is being pursued by the Competition and Markets Authority (CMA).  Nevertheless, when the economic history books consider the catalytic impact of PSD2 and CMA on the structure and operations of the financial services industry, perhaps the most enduring TLA may be “TPT”, for “Two Pizza Team”.

The focus on organising effective and agile teams in commercial organisations has given rise to the “two-pizza team rule” i.e. that teams shouldn’t be larger than what two pizzas can feed.  The underlying logic is that more communication isn’t necessarily the solution to communication problems. As group size grows, you simply can’t have as meaningful of a conversation with every person, which is why people start splitting off into smaller clusters to chat. Small teams make it easier to communicate more effectively. They also encourage high autonomy and innovation.

There are challenges inherent in attempting to accelerate pace using large teams, as there are issues relating to the size of the team itself (identifying accountability, giving recognition). In larger teams, the number of links between people is a problem. As group size increases, the number of  unique links between people also increases, but exponentially. A small team of 6 creates 15 links between everyone, a larger team of 12 will generate 66 links and a team of 50 has 1,225 links to manage. This exponential increase means that coordination and communication costs are soon growing at the expense of productivity. “Ensuring that all relevant stakeholders are represented” in a large team is likely to create a team that is incapable of moving at pace towards its objective. The cost of coordinating, communicating and relating with each other snowballs to such a degree that it lowers individual and team productivity. It’s easier to be effective in an environment where everybody knows your name and understands who you are as person.

Pursuing the "two pizza" rule could become a real imperative for banks if the development of Open Banking within the API Economy creates a new Dominant Design for the banking industry. The overarching business outcome from Open Banking that we can anticipate is an expanded Financial Services market size, where competition is framed by ecosystem-versus-ecosystem competition rather than product-versus-product. If so, this requires an entirely new perspective within the financial services industry. Product Businesses focus on the needs of the mass market in conceiving new products and services, which they can deliver with economies of scale and sell in large volumes. Product Businesses are “pipes”. They’ve been the dominant model of business for a long time. Firms create stuff, push them out and sell them to customers. Value is produced upstream and consumed downstream. There is a linear flow, much like water flowing through a pipe. In contrast, a Platform Business aims to capture niche markets “in the long tail” without having to attempt to create products and services for them. Instead, App Developers might find the niche markets lucrative enough to pursue using the platform as a foundation. The platform owner can therefore penetrate many market niches without bearing the direct costs or risks of dabbling in them.  

Within the current mainstream industry perspective, the most attractive data is the data on the customer’s direct engagement with the bank. The primary insights being pursued are insights into the standardised customer needs in the mass-market. Customer journey is typically defined as “the complete sum of experiences that customers go through when interacting with a company and brand”. When customer journeys are assessed, the main journey often being examined is the customer’s journey once they enter the bank. Given the mass market/large segment focus, the pace of innovation sees very infrequent and rare new products and channels aimed directly at the mass market.

In contrast, Open Banking and ecosystem-versus-ecosystem competition implies a perspective that the most valuable data is data on the customer’s ecosystem activities, obtained with customer consent. The locus of innovation comes from the newly visible customer needs surfaced by developers leveraging Open Banking APIs, rather from the bank-as-a-platform’s own innovation efforts. The most important journey is the journey out into the ecosystem to insert financial services into the customer’s financial life cycle at the most appropriate time and in the most convenient place. The pace of innovation accelerates significantly, with the continuous release of large numbers of APIs for partners and developer communities.

This change in perspective will change a bank’s management model from the command and control of own resources to orchestration of an ecosystem. With the new perspective, the key tension to be managed is no longer a bank meeting customer needs but rather the right balance between partner autonomy and tight process integration. The value to the end user comes from the ecosystem rather than the bank only. The dominant innovator is no longer the bank as this role moves to the third-party App Developers. The most crucial element of this change in perspective is the understanding of a good product - the new perspective is that a good product outside an ecosystem is irrelevant.

It is a major organisational challenge for traditional banks to create empowered and equipped Two Pizza Teams that can manage valuable and rare financial service domains with agility within ecosystems. Traditionally, incumbent banks have had “teams of thousands”. They have historically aggregated expertise into functional groupings, which is efficient when operating at scale in a mature business model. This focus on scale economies was possible because of the exclusive access to client data and the preference for private sales forces. However, it comes at the expense of flexibility in cross-department working.

To make the transition towards ecosystem-versus-ecosystem competition, banks need to narrow their market focus from large segments towards narrow microsegments. These microsegments correspond with key stages of the generic customer financial lifecycle. These differ across the lifecycle of a consumer and the life cycle of a business. For example, in very crude terms, a generic consumer financial lifecycle begins at the stage when a bank opens a child’s savings account that later converts into a college student account. Major life changes then occur at relatively predictable stages, that often give rise to major change in cash flows and potentially a financing opportunity e.g. consumer gets a job, consumer buys a car, consumer is a frequent leisure traveller, consumer changes job and relocates, consumer gets engaged, consumer purchases a home, consumer gets married, consumer becomes a parent, consumer makes major home renovations, consumer’s child is a new teen driver, consumer’s child goes away to college, consumer finalises plans to end full-time work, consumer’s child gets married, consumer becomes a grandparent, consumer’s spouse retires from full-time work and finally consumer retires from full-time work.

Traditionally, the account holding bank effectively had exclusive use of the data in the payment account that could signal the advent of these financial life stages. However, the evolution of platform business models has created ecosystems of complementary platforms and apps that are becoming better informed of the micro elements of each of these life stages e.g. Social Networking Platforms (consumer goes to college), Recruitment Platforms (consumer gets a job), Car Supermarket Platforms (consumer buys first car), Short Term Lodging Platform (consumer becomes a frequent leisure traveller), Real Estate Platform (consumer buys first home) and so on. Each of these life stages has an ecosystem forming around them. ProgrammableWeb publishes a repository of web APIs and applications. As of this date, it has documented over 16,000 open web APIs and thousands of applications. It is effectively the journal of the API economy. As at the publication date of this blog post, there were 165 Open APIs encouraging ecosystem formation around the Auto sector, 169 for Job Seeking, 132 for Design, 495 for Travel, 447 for Education and 168 for Real Estate. Each of these APIs can be used by many, many different competing and collaborating market actors. These areas of economic activity are amongst the pivotal points on the consumer’s financial life cycle and these “moments of truth” drive a very large share of revenues in the financial services industry.  

Taking a microsegment view will greatly help a bank to start thinking and acting within ecosystems rather than framing the market into large segments from the perspective of a product business. This new thinking and acting seems far more likely to be effective if a small, contained microsegment is rigorously evaluated and chosen for that initial baseline investment. The initial investment should have acceptable technical risk (e.g. maturity of technology, predictability of evolutionary trajectory, need for systems Integration, complexity) and an acceptable market risk (e.g. predictability of end user reception, predictability of end user needs, arrival of critical complements, matching by rivals etc.). The investment in the microsegment needs to be a discrete stage of investment with a measurable value proposition. The microsegment investment should deliver clear measurable benefits, even if no further stages are ever completed. A "microsegment by microsegment" approach may also radically change the technology procurement decision, if the aspiring bank-as-a-platform is not launching itself at the high-scale mass market. Crucially, given the potential of Open Banking to radically change industry structures, the investment in the initial microsegment should have plenty of cumulative learning on technical architecture, partner development, platform dynamics, team skill sets and business governance.

Within this microsegment-based approach, what might an Open Banking Two Pizza Team look like? There are many varying models of what roles the “technologists” within the IT function of a large organisations could adopt in DevOps or Agile teams (e.g. the DevOps Evangelist, The Release Manager, The Automation Architect, The Software Developer/Tester, The Experience Assurance Professional, The Security Engineer, The Utility Technology player and so on). In crude terms, the “non-technologists” with a business development function take up the slices of the second pizza (e.g. the Sponsoring and Accountable Business Executive/Partner Manager, the Product Manager for the Specific Service Domain, the Enterprise Architect with Organisation Wide Knowledge of Service Domains, the API Developer Community Manager for that Segment, the Risk and Compliance Specialist with deep domain knowledge of Information Security, Data Privacy and Financial Crime rules and regulations). 

Mere assembling a multi-disciplinary team to carry out concurrent work within the ecosystem is not sufficient. The Open Banking Two Pizza Teams need to be equipped, empowered and trusted to manage the key risks. Emergent strategy, plans and tactics need to sit locally within these small lines of business teams focused on microsegments. They need autonomy to quickly make commercial decisions without multiple “governance gates” to pass through. However, they also need rigorous and effective control policies (and hands-on tools to maintain policy compliance) that place clear boundaries on their conduct, compliance and record keeping (e.g. enterprise policy on technology standards, enterprise policy on reusable software architecture, GDPR compliance, PSD2 compliance, Customer Consent Management, Identity and Access Management etc.)

In crude conclusion, “Two Pizza Teams” seem to be the end destination for bank organisations making a transition to ecosystem-versus-ecosystem competition, with interim steps and some extra-large pizzas in the early days. This end destination does seem to imply a crucial first reorganisation. Having agile engineering inside a centralised “digital centre of excellence” won’t produce the business model innovation that will need to be continuous for the next 5-7 years. Distribution strategies and the pace of the transition to ecosystem-to-ecosystem competition will be different between the main banking market segments. Ultimately, only the person in a bank with line of business accountability for segment profitability and growth can empower these Two Pizza Teams and can also make the trade-off decisions between new staff, new proprietary channels, new partner/public APIs and new developer/partner incentives.