Product-aligned vs Capability-aligned Organisation Design
There are broadly two dominant approaches used to organise teams in modern organisations that have moved beyond traditional activity-oriented organisation design (organising people by their specific skill).
One perspective is to organise teams ‘vertically’, aligned with the company’s products. Google might have a Google Drive department, a Google Maps department, an AdWords department and so on.
The other perspective is to organise around business capabilities — common services/features/functionality used in many or all of the company’s products. An example would be an internal user management system, so that customers have a single login used across an organisation’s entire product portfolio.
As you can probably tell, these choices aren’t mutually exclusive. You can apply the different patterns in different parts of your organisation and combine them for best effect. The interesting questions is: what are the trade-offs of each approach and when should we prefer one over the other?
Product-aligned vs Capability-aligned: Supermarket Example
A few decades ago, a world-famous supermarket began opening physical stores, and eventually started relying on computers for a variety of purposes, like tracking orders and inventory.
Then along came the internet, so they set up a completely new department to build and operate online services. In order to provide the best experience and use modern technologies, physical store and online store were separate IT systems and separate IT teams.
This was an excellent decision that allowed the supermarket to move quickly and build up market-leading online capabilities.
A few years later, mobile devices became really popular, and people wanted to buy carrots and peas on their smartphones. The online team’s code and infrastructure was starting to creak, so a business decision was made to set up a completely new mobile department who could deliver the best possible mobile experience without being inhibited by the existing systems.
Again, another great decision by leadership. This time they had the best mobile experience and they continued to out-innovate the competition. They added other products, too, like banking, continuing with the same model.
The next shift in technology and consumer expectations was dramatic. People started taking great user experiences as standard. Thanks to the likes of Facebook, Twitter, Amazon and many other products, consumers started expecting a fully-consistent, seamless user experience across all of their devices.
This became a problem for the supermarket.
Users had to log in with different accounts to each product. Users could not see their in-store purchases on the website, nor website purchases on the mobile app. Loyalty points for in-store purchases took 24 hours to appear and could not be used on the mobile device, whereas loyalty points for online purchases appeared immediately but could not be used in-store.
Management also grew concerned over duplication. Why is each department re-inventing email sending infrastructure, order management, user management, loyalty, and so much more?
The vertically-sliced product-aligned organisation design was no longer a competitive advantage. In fact, it was a significant hinderance to satisfying market demand. The supermarket were fully aware of this and began their transition to a capability-aligned organisation design.
1. I am making many over-simplifications in the next sections. Some intentional and some probably naive. Please do leave a comment if you disagree or feel further elaboration is necessary.
2. And in many cases there are solutions to minimise the costs while retaining the existing org structure (e.g. a data warehouse to avoid data silos). However, I present trends here that I have genuinely witnessed in numerous organisations.
Product-aligned
Aligning by products confers high levels of autonomy to each department. It’s their responsibility to turn a profit and grow market share, and they are free to invest however they feel necessary to achieve that goal.
✅ Decision-making Autonomy
They can choose the technologies they use, they can choose what to build in-house vs buy off the shelf, they can choose how much salary to pay their employees and hire who they feel they need to get the job done.
✅ End-to-end Technical Ownership
Each department owns its products end-to-end. It does not rely on other parts of the business to improve it’s products.
✅ Financially Self-sufficient / Simpler Funding Model
As long as the department is hitting it’s financial targets and the numbers look good each quarter, the department can be largely left alone to run their successful business by generating their own profits and covering their own expenses.
✅ Reduced Organisational Politics
Decision-making autonomy and end-to-end ownership reduce the dependencies on other departments minimising cross-department organisational politics.
For example, if Department A and Department B depend on Department C but Department C only has capacity to service one, either A or B cannot achieve their business goals and they may be prepared to go to war over it.
✅ Innovation Speed
Departments can move fast due to their high levels of autonomy. If they need to build a new service or hire new people, the department has the autonomy to quickly make business and technical decisions, accelerating product development.
✅ Optimised User Experience
There is no compromise on user experience. A product-aligned department produces the very best user experience they can for their products.
❌ Sub-optimal Business Outcomes
High autonomy can lead to low-alignment across products. Each product may optimise for itself at the expense of optimal organisation-wide outcomes.
❌ Cost-inefficiencies & Duplication of Effort
Ownership of end-to-end product implementations can result in departments having to build technical capabilities that aren’t differentiators. And these supporting capabilities could be duplicated for each product.
As alluded to previously, user account management & email/notification capabilities are usually the type of generic capability that are duplicated within organisations.
❌ High Opportunity Costs
Time spent building non-core capabilities is time taken away from building differentiator capabilities that really drive growth.
❌ Neglected Non-core Sub-capabilities
Each department will do just enough work on it’s sub-capabilities to support it’s main business goals. Any potential differentiation in those sub-capabilities may be neglected.
For example, growing email capabilities into a smart contact capability that communicates with customers in different ways and uses AI to create customer-specific content. Which product would be developing this? Probably none.
❌ Poor Overall User Experience
Customers using different products may feel frustrated by the inconsistencies — especially if they have to log in with multiple accounts and data from one product is not available in another.
❌ Data Silos
Departments can become data silos. This is a problem when a business wants to harvest its entire data set for key insights to understand consumer behaviours and gain competitive advantage.
❌ Lack of Cross-pollination
In large, product-aligned organisations it’s common to see very strong boundaries where knowledge and ideas do not flow freely.
Capability-aligned
Aligning by capability offers the promise of a more collaborative organisation, working as an ecosystem to provide more innovative environments and more connected end-to-end user experiences.
There is an interesting decision to be aware of with capability-aligned organisations — who owns the user experience? A common pattern is to isolate ‘experiences’ from services. Each experience is owned by a dedicated team.
The alternative pattern is to break up the experience into ‘chunks’ (user journeys, individual pages, etc) and have teams who own end-to-end vertical slices — e.g. the product details page for a marketplace for example.
✅ Powerful Internal Ecosystems
Capabilities can be shared across the organisation. Functionality and data available to one product can be made available to all of the company’s products.
✅ Deep 3rd Party Integrations
Internal ecosystems driven by an API-first culture can more easily be opened up to external companies who can build their own rich experiences on top of your organisation’s capabilities, further driving market share.
✅ Joined-up Customer Experiences
Shared capabilities enable customers to see their data across all of the company’s products, encouraging brand loyalty. For example, a single user-login for all of the company’s products.
✅ Cost-efficiency
Shared capabilities preclude the need for each product to duplicate the same functionality, so less of the overall organisation’s time and money is spent on duplicating the same functionality.
✅ Rich Data Analysis
Capabilities share their data across the organisation, making it easier for data scientists and stakeholders to accumulate the data they need to derive rich insights.
✅ Deep Innovation
Each capability is is owned by a team who treat it like a product. Instead of having the bare-minimum functionality required to satisfy existing product requirements, the capability is continually enhanced with innovative new features.
✅ Capabilities Can Become New Revenue Streams
When treated like a product, innovative or high-leverage internal capabilities can be opened up to the outside world as an additional revenue stream.
✅ Flatter Structure
Typically the organisation will have a larger number of smaller units at the same level, akin to a set of collaborating peers, rather than a few highly hierarchical product-aligned departments.
❌ Higher-coordination at the Programme Level
For large programmes of work spanning multiple capabilities, the effort to coordinate teams and the bureaucracy can be overwhelming. Each capability is a separate product with it’s own roadmap and multiple internal customers each pressuring for different deliverables.
❌ Reduced Autonomy and Speed
Due to the higher coordination, adding new features to products may require collaboration of multiple capabilities. The coordination of programmes of work spanning multiple capabilities can require significantly more management overhead and result in orders of magnitude longer lead times.
❌ Complicated Funding
How do we fund a team that makes no profit? Many capabilities will have only internal customers and will therefore not generate a profit. Whether it’s managers pitching for investment or capabilities finding ways to charge costs back to internal customers, it usually gets complicated and controversial.
❌ Lack of Customer Perspective / Selfish Silos
Capabilities can become deeply disconnected from the end-user. They may not realise why their internal customers are asking for changes and so they aren’t invested in helping to deliver the best possible experience to end-users, which is essential from an organisational perspective.
I call this pattern the selfish-silo.
❌ Empire Building
Each capability will need to justify it’s own existence and convince the business to continue funding it, and management of the capability will want to further their own ambitions by growing the capability. With every capability trying to grow it’s own empire, it’s harder for senior management to know how to best spread investment.
❌ Overly-complex, Generic Capabilities that Suit Nobody
Trying to create capabilities that satisfy tens or hundreds of internal customers can result in unusable capabilities that have become way too complex by trying to cater to the needs of all customers.
❌ Ecosystem Overhead
Creating an ecosystem of internal capabilities requires a significant investment. Platform tooling is essential but so is governance — identifying and policing standards that work for everybody and help everybody to work together.
❌ Hard Convincing Internal Customers to Use the Capability
Even when internal capabilities exist, a lot of time and energy can be spent encouraging internal customers to onboard with the capability and discontinue their own solution. Internal customers may be reluctant to incur the costs of switching.
Internal Products & External Products
Over recent months I’ve grown discontent with the product-aligned vs capability-aligned distinction. I’ve started using a an alternative classification which better reflects the purpose and role of organisational units.
For me there are only internal or external products. Everything is a product owned by a team applying modern product management best practices to best suit the needs of their customers.
We can instead classify products by the type of capabilities they provide:
- Experiences (user-facing applications)
- Business Services (provide high-level capabilities)
- Data Services (provide low-level data capabilities)
- End-to-end product slices (spanning all 3 of the above)
I’ve written about classifying capabilities previously but I constantly gain new insights that challenge me to think differently. There is still a huge amount to discover here.
So how do we actually find the perfect boundaries? I’m still working on that.
