A Clash of Mindsets: When New Products Depend on Existing Products
A common pattern of business growth is to expand from a single product to multiple products. Sometimes, this can be achieved with relatively minimal disruption, like when the products are highly distinct and can be developed fully in-parallel. This is often not the case, however.
As some companies become multi-product, there is a high degree of overlap between new and existing products. One type of overlap is where the new product builds on capabilities provided by the existing product. This can become delicate when the mindsets of each team are optimising for different things, most commonly speed vs reliability.
Teams building new products typically want the ability to move quickly, experimenting with new product and features ideas as they seek problem-solution fit. They have few, if any, paying customers so there is no risk of losing market share if things break or aren’t polished.
On the contrary, established product teams have a successful product with a paying customer base. Constantly changing the product and implementing half-baked features is a risk to revenue. The system needs to be highly reliable because even just a little downtime can alienate loyal customers.
When a team building the new product wants to move quickly, but they depend on regular changes to an existing product owned by a team with a more cautious risk appetite, one or both products may suffer if the delicate situation is not acknowledged.
The Nature of Evolution
New innovations often become the platform for future innovations. Google Maps started life in 2005 as a desktop application for getting from point A to point B. Since then, Google Maps has become the foundation for many other innovations after being opened up to developers via APIs.
Uber started life as a ride-hailing product. But nowadays, Uber’s Fulfilment Platform has been extracted and become the base for many other innovations including food, grocery, package delivery, and even 3rd party taxi companies.
The costs of having to build a unique fulfilment capability inside each of those products would be highly inefficient.
“The simplicity of standard building blocks allows higher orders of complexity.”
— Simon Wardley
In the Wardley Mapping Universe, Simon Wardley describes evolutionary phenomena using climatic patterns. Two particularly relevant patterns are Efficiency Enables Evolution and Higher Order Systems Create New Sources of Worth.
In Wardley lingo, Google Maps is so efficient that it acts as a building block for higher-order systems (e.g. map-based property search) which deliver new type of value (e.g. seeing real-time property search results on a map).
Wardley Mapping also points to the cause of social challenges that emerge when there are dependencies between newer and older products. In his Pioneers, Settlers, and Town Planners model, Simon Wardley explains the varying mindset of each group. Pioneers “show you wonder but they fail a lot. Half the time the thing doesn’t work properly. You wouldn’t trust what they build.” While Settlers “can turn the half baked thing into something useful for a larger audience”.
It’s not inevitable that every product or innovation is going to become a platform for future innovations, but it is inevitable that some will be. It’s therefore logical for every business to anticipate the evolution of their products to be well prepared for dependencies.
Engineering for Speed and Reliability
It shouldn’t be treated as a law that teams will clash when there is a dependency between their products, even if there is a big difference in mindset. One of the key reasons for the tension is two teams wanting to move at different speeds with a different risk appetite.
If both teams can move at their maximum speed without compromising the reliability of existing products, there is much less risk. It seems unrealistic wanting the best of both world (speed and reliability) but the field of software engineering established during the past decade that speed and reliability can both be achieved.
A good engineering organization moves at speed with high reliability. It doesn’t need to be a choice of one over the other. Many of the practices that enable teams to move quickly are the same practices that enable highly-reliabile systems: automation, observability, testing, and design.
I’ve worked with small startups and large enterprises where teams are deploying the company’s most critical system to production multiple times per-day . Any organization can achieve high speed and reliability if they invest sufficiently in their engineering capability and culture.
For multi-product companies who want to rapidly develop new products without compromising the reliability of existing products, investing in modern engineering practices is such a huge benefit.
Rethinking Domain, Software, and Team Boundaries
As organizations grow, the structures and practices that helped them to be effective at one scale hinder them at another scale. Moving from a single to multiple products can be one of those situations where architecture starts to get in the way.
When a new product depends on an existing product, it’s often possible to remove friction-causing dependencies by rethinking domain, team, and software boundaries. A typical example is where a subset of domain concepts which belong to each product are logically coupled and should be split out.
With the shared domain concepts extracted from the existing product, both teams may be able to move at their optimum speed. But not always, they may both require changes to the shared domain, in which chase some conflict will remain.
It’s not always obvious when multiple teams are both building capabilities which are logically parts of the same domain. Quite often it takes a while to appear. This can happen when the new product team is given full freedom to build all of the capabilities they need in the new product.
At first they might build all the features that don’t require them to talk to other teams, hiding the problem. A bit further down the road, dependencies start to appear and changes often require both codebases to change at the same time.
I suggest regular domain discovery workshops to identify hidden domain coupling.
If you’re new to domain discovery and modelling, check-out the free tools from the DDD Crew or the free kata exercise.
Fostering Collaboration Instead of Competition
It’s always a warning sign to me when multiple teams are given their own unique business outcomes to achieve, yet there is backlog coupling meaning they are not 100% in control of their own destiny.
For example, If Team A needs Team B to make changes, but Team B has been given their own separate goals, then why should Team B compromise their own targets (and be punished in some way) in order to help Team A?
This is an important leadership and strategy issue. Firstly, it’s essential to articulate clearly what the priorities are. Do new products take precedence over existing products when there is contention over time and resources?
Leaders can’t just push over-ambitious objectives onto multiple teams and keep applying pressure to deliver when difficulties like dependencies are raised. Leaders need to be clear about priorities and ensure that collaboration between teams is encouraged and rewarded, even if it means objectives for one team are not achieved when they focus on helping another team.
Optimize for Existing or Future Revenue Streams?
As a side-note, in my experience there is a strong bias towards existing revenue streams. Whenever there is contention for people’s time, existing products usually win because “they pay they bills.”. This is something that people naturally default to when there is contention over investment.
I think this is often overly short-sighted. A disruptive new product that could 5x your company’s total revenue can be even more important than guaranteed revenue now.
If leadership truly values the new products, then they need to be very clear precisely how much they are prepared to balance the investment in new vs existing products, especially when a dependency or other conflict means you can’t have 100% of both and need to make a trade-off.
More Products, More Problems
Becoming a multi-product company is exciting. It’s a sign of both success and ambition. Naturally, though, the business model, operating model, and strategy all become more complex, especially when dependencies and contention for limited resources arise.
In order to best prepare yourself, I can’t think of anything better than learning Wardley Mapping. Understanding how concepts evolve through different stages of innovation, and how evolution in one component will affect others, is such a useful skill to help anticipate problems in advance.
It’s also key to recognise that structures which make a small single-product company successful probably won’t be optimal for a larger multi-product company. Event Storming and Team Topologies are tools that can help you in this space to re-think boundaries.
Even with the best strategy and organization structure, there will always be dependencies. If you’re pushing multiple teams in different directions and forcing them to compete with each other, then there is a need for leadership to be clearer about priorities and incentivise collaboration around what’s most important.
