Abstract

In this post we will explore the depth of challenges when adopting product-centric operating models in organizations, why this makes sense, and what processes of continuous innovation could such a model put into practice, increasing the chances to build organizations that can more safely adapt to continuously changing market and social conditions, in a rapidly changing context such as the ones we’re immersed in as global society goes through the nexus related with reinventing much of itself.

Subscribe to our newsletter if you don’t want to miss a thing!

Productization is a pervasive trend

Product-centric operating models are taking hold in the market and many organizations have embarked on the transition toward such a model in the past decade. At Boundaryless we’ve also been investigating the rationale that could make the case for organizations to transition towards a product-centric model, and we’ve found that markets are gradually generating the conditions for composability and modularity to be favored (see Towards Modular and Composable Markets – Boundaryless). As a result, we believe that it is important to focus on the emergence of such a modular model of organizing: for the organization to behave in continuity with the market, responding to its rising complexity, adopting a similar internal texture may be essential. The fact that pioneers and leaders in organizational development have adopted it, empowering divisions of different sizes, and missions, to become strongly independent – often bearing their own profit and loss – confirms our bias.

Despite the intrinsic challenge to control, an organization that produces multiple products allowing product divisions to bear their own P&L statement – and relatively manage their own strategy and development – can achieve coherence through overarching coordination that can be enacted, for example, through investment policies and primitives that promote collaboration between unit for the achievement of higher value services. Such an organization can achieve what is sometimes called “messy coherence” (see how Sonjia Blignaut explained the concept in a conversation with Emanuele Quintarelli) through a set of enabling constraints, known for being essential to creating an innovation-conducive environment.

“According to the studies we reviewed, when there are no constraints on the creative process, complacency sets in, and people follow what psychologists call the path-of-least-resistance – they go for the most intuitive idea that comes to mind rather than investing in the development of better ideas. Constraints, in contrast, provide focus and a creative challenge that motivates people to search for and connect information from different sources to generate novel ideas for new products, services, or business processes.”

From “Why Constraints Are Good for Innovation” – Acar et al. HBR

In particular, the adoption of a positive P&L requirement at the level of a product division will likely be less conducive to the accumulation of organizational debt and – if coupled with organizational artifacts that lend themselves to inter-unit collaboration such as multi-unit contracts to serve as a basis for bringing complex customer scenarios on the market.

The idea of a micro-entrepreneurial unit is central in the 3EO Model inspired by Rendanheyi as it enables a transition towards a product-centric operating model in a bottom-up fashion: by using positive P&L as the leading “forcing function” and by making it easy for units to trade and source services not only inside the organization but also on the market. In such a context the organization would still provide shared common services but would often avoid obliging customer units to source such services only from the captive environment. At the same time, the shared service providers themselves could be encouraged to seek to provide services outside the organization when possible. An organization structured as such can achieve agility, and adaptability and can rapidly rebundle its capabilities around emerging opportunities.

As we discussed in a previous piece (Primitives of Contract-based and Unit-based organizing for better Agility and Engagement), the delicate balance in providing shared services to the product units is one of the spaces where the organization can seek optimization sometimes at the expense of efficiency: too busy and efficient shared services could in fact mean that the product units are stuck in waiting time, while too unoptimized shared services may end up becoming a burden to productivity and impact negatively on margins.

In this piece, we want to focus more on the product units though, and go deeper in the understanding of the dynamics that impact product teams as they grow and interoperate inside an organization.

Creating autonomy bubbles for the creation of more integrated value propositions

What is the rationale for creating a separate P&L division with its own product focus in an organization? 

The first thing we want to achieve is that a new product team can be created quickly and autonomy can be granted to operate its strategy. Secondly, we want to create a space inside which different structures can be sought to integrate vertically with the aim of creating a differentiating value proposition. If we agree that positive P&L could be a great forcing function for the organization to avoid accumulating organizational debt in units that are not able to deliver a clear value proposition and a clear interface, we also need to acknowledge that – to create an optimized product – you have to leave freedom for the internal structures of the micro-entrepreneurial unit to be shaped in ways that are not necessarily based on maximal composability but instead allow stronger divisions of role and contribution for the achievement of more characteristic product experiences. 

Inside the product units, more specialized differentiation needs to be granted: we know very well that to ship a certain experience to the market an organization needs to change shape accordingly. You ship your org chart: this is essentially what Conway’s law says and the evidence connects it with the idea that you’ll need to shape the teams and their interactions that are internal to a product unit (that could bear its own P&L) in a way that is optimized to produce the strategic outcomes that the unit is seeking at that point in time.

In an effort to get some inspiration from the bleeding edge of practice, we recently had the chance to talk with Casey Winters about how fast-growing product organizations arrange the responsibilities in their teams. Winters – which had tremendous experience in tons of high-growth scale-ups made the point that usually teams working on a product will be distributed into these three pillars:

• the core product and product innovation work pillar: “to strengthen the core product with additional features and maintaining the core”
• the growth pillar:  “to grow overall usage of the current product.” 
• the technical scaling (or “platform”) pillar: “working on internal features that support other product and engineering teams to allow them to scale”

Winters also said that – often in combination with this basic structure – another dimension of team structuring could be that of mirroring either the value proposition(s) that the organization is executing or the strategic challenges that the organization is going through at that very moment. As an example, according to Winters, in an organization that is producing a marketplace, teams could be organized with two structures, one that looks into the consumer’s value proposition and one that looks into the supplies value proposition, therefore we could imagine the structure expressed above as replicated – at least partially – towards the two sides (Conway’s law anyone?).

“At Faire, we choose to follow strategy above all else — meaning that the charter and structure of our organizational pillars should reflect our most important customer and strategic problems, even as our priorities may shift from year to year.”

Carla Pellicano (Faire) From “Strategy leads the Faire product-org, not inertia” 

Similar patterns have emerged from the DevOps community in the past decade, with the best-recognized framework probably provided today by Team Topologies. According to Pais and Skelton, teams in mature software-delivering organizations (the organizations where the distance between team structures and product structures is the least and therefore Conway’s law is the most recognizable) are often distributed, or should, according to the following structure:

• Stream-aligned teams
• Platform teams
• Complicated subsystem teams
• Enabling teams

While complicated subsystem teams and enabling teams can be seen as org-wide artifacts the first two resonate vividly with the idea of product work and technical scaling:

Scaling inside the product bubble

What we obtain so far is a picture where we have independent product divisions (micro-enterprises) that can be organized autonomously internally mainly with the objective of adapting their operating model to the product outcomes they want to generate. Are you producing a SaaS product? Maybe you want to have a certain team focused on an Enterprise customer segment and another one focused on a single professional adopter. Are you producing a marketplace? Then better to have a team branch feeding the supplier’s value proposition and another one feeding the consumer one. Are you running an extension platform leveraging third-party teams? Would probably make sense to articulate part of the product division team in a way that caters to a better developer experience.

But what happens as your product scales? There are two clear ways to approach the question: 

• by sprouting new smaller products (and thus independent division) 
• scaling teams and giving as much as possible team autonomy by separating feature groups and sub-products 

Sprouting new products as the organization grows

In another recent blog post, Winters spoke about resisting product complexity and highlighted some techniques to ensure your organization can keep its products reasonably simple. The most interesting one for the discussion we’re having here is probably what he calls “Validate and Unbundle” something that has been used for example by Uber as it introduced Uber Eats:

“Leverage the scale of the initial product experience to expose people to the new value prop, confirm product/market fit, then move that new product experience elsewhere so the new value prop’s added complexity doesn’t deteriorate product/market fit for the initial product.”

From Five Ways to Address Complexity In Your Product

This approach has been discussed recently by Lenny Ratchinsky on his podcast with renowned CEO Coach Matt Mochary:

“The reason that a big company has a hard time innovating, it’s because once a product is scaled, it’s now got millions of users. So you have two things that you need to make sure stay true every day: the site is up and running and there’s no security breach. Every time you add code, you’ve got to test it thoroughly to make sure it doesn’t take down either one of those. The review process is insane.

So now you’re innovating, you’re writing prototype code on new features. You can’t get it approved. It takes so long. That’s what you’re trying to decouple and you’re trying to create an entity that isn’t touching the core code, but you also don’t want to have to go through the approval process of the product team or the head of product. That takes way too long, as well. That’s why it has to be a small team that reports outside of EPD (ed: Existing product development). It can’t report to the head of engineering, head of product, or head of design, it can’t. It’s got to go outside, usually directly to the CEO.”

From Mochary’s interview on Lenny’s Podcast 

Growing the number of teams

A different approach to separating products as they grow, which also connects with architectural implications, is that of adopting practices inspired by Domain Driven Design and bounded contexts. The idea of a Bounded Context is central to Domain Driven Design and was popularized, among many, by early DDD blogger Martin Fowler. Bounded Contexts essentially point out that the most elemental way of dividing responsibilities among teams may be that of recognizing the boundary where the concepts are used to describe a certain problem (and solution).

“As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. […] In those younger days, we were advised to build a unified model of the entire business, but DDD recognizes that we’ve learned that “total unification of the domain model for a large system will not be feasible or cost-effective” [1]. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model “

[1] Eric Evans in Domain-Driven Design

From BoundedContext by Martin Fowler 

So what’s the point? Often, understanding where the need to gemmate a new team lies will be understandable through the lens of mapping the contexts and understanding where the bounded contexts emerge: a bounded context is a good indication that a feature group or sub-product could be built and a team can be made solely responsible for it. In this case, the pattern that could be preferred is the one pioneered by Spotify with its model (which is not a model after all and was discarded by Spotify itself). But the point remains: if you can’t separate the products and keep the product division small enough to figure out everything on its own, including its peculiar team structure, adopting something that is optimized to distribute autonomy and leadership over a stream or subproducts or feature groups may make sense. An approach like the one formalized by Team Topologies can be a good lens to look into the problem of scaling the number of teams working on a product. 

It needs to be recognized though that, as Scott Belsky said once: “Users flock to simple products. The product adds features, evolves, and takes users for granted. Users flock to simple products.” (thanks Casey Winters for resurfacing this). Therefore actively keeping product complexity low, and actively branching different products off – limiting their interdependencies – is a good solution to keep the system of teams looking after one product relatively small, ensure it has a clear understanding of its bounded context, ideally reach the customer independently, and therefore possibly aim for a positive P&L on its own, relying on some org-wide services for more explicit technical scalability around servitized capabilities

The need for a product portfolio overview and taxonomy

Eventually, it will be essential that an organization that wants to adopt a product-centric operating model adopts an intentional practice of portfolio mapping and product taxonomy. In this excellent post, Nick Tune connects with earlier writing by Clanton et al. making the point that a portfolio view and product taxonomy are essential to connect the market and business view to technical architecture and team structures.

A portfolio view like the one we described in this recent post “Framing a Portfolio of Platform-Ecosystem strategies inside an Organization” will help your organization to be more intentional with regards to identifying the need for seeding new teams that could:

• either be able to extract common capabilities from existing products and transform them into independent enabling services that could – in turn – be commercialized as separate products
• create a new product initiative and the related micro-entrepreneurial unit that can leverage on the existing portfolio strategically (for example through enabling technological modules or through pockets of users that can be easily brought in from other existing products).

A Recap 

In the post so far, we examined how we can look into a product-centric organization through – at least – three essential contexts. Indeed, despite the focus when thinking about a product organization has often been the product division (1 in the picture below) and how the product division can scale (2 in the picture below), it’s clearly important to look into the context that embeds the product division i.e the portfolio (0 in the picture below). The products in the portfolio are indeed often composed of more complex user scenarios. The 3EO framework provides for the artifact of the EMC (Ecosystem Micro Community Contract) to allow different product units to create agreements and share skin in the game on creating a more complex user scenario being brought to a customer. That scenario, in turn, could later develop product characteristics and be eventually incorporated as a separate entity in a process of progressive modularization where customer-facing innovations become products, and recurring capabilities emerging in the product units become enabling services. 

Looking at the dynamic element is key, especially as we seek to unbundle the organization and transform it into an ecosystem player. Traditionally product development cycles have always been framed as “internal” to the organization but the possibility to use patterns such as extension platforms (the mechanisms that some product organizations use to let third-party developers extend their products with “apps” or “plug-ins” that we extensively covered here) allows you to effectively “sense the future” as Simon Wardley once said. 

Essentially what happens is that we could empower a unit to run such an extension platform and let an external third party extend our product, letting the user interact with such extensions. This effectively brings a signal about what innovations are the most important. Subsequently, we could actively integrate part of the experience that the extension provided to become part of the bounded context of the “official” product itself. The same components could then evolve – some of them becoming elementary capabilities – as the whole product evolves towards a higher value system. Progressively, components could be transformed into utilities (such as APIs) that, in turn, can be provided back to the developer ecosystem (see the pic below).

Conclusions & further works

In this post we explored how product-centric organizations have to address the structural problem at three levels or contexts:

• decide what product teams to build as part of an organic portfolio
• design the structure of each product team in a way that each unit can “ship its org chart” organically
• assess what’s the best way to address the growth in complexity of single products, either by separating sub-products, branching, or scaling teams

Furthermore, we acknowledged that for product-centric organizations to thrive they have to adopt a conscious way to map their portfolios and develop product taxonomies. Such market-portfolio views are essential to give the organization’s board of directors (or similar entity) the capability to use investments wisely to seed new elements of the portfolio and to the contributors in the organization to visualize where an opportunity to create a new unit may lie given that the possibility exists for them to use enabling constraints (such as processes and artifacts to pitch their ideas and receive funding).

We also explained how – as organizations increasingly rely on patterns such as extension platforms to capture innovations coming from their developer ecosystems the product incubation processes should have to include future sensing signals coming from the outside and aim at continuous modularization.

At Boundaryless we’re now starting a new research thread inquiring how – internally to a product division – teams should be structured depending on the product they are building, and their strategic challenges. If you’re interested in sponsoring this research or contributing please reach out through the form below!