In our previous blogpost 'The Big Picture - Connecting Strategy to Architecture'", we identified a Feature Matrix as an important artifact during Transformations.

A feature matrix is helpful in the following digital transformation scenarios:

  • Mergers and acquisitions where digital products/services have overlapping or similar features.
  • Splitting a monolith to understand what personas use specific services/domains
  • Getting marketing, sales, product, and engineering on the same page

What is a Feature Matrix?

Buyers and creators use a Feature Matrix to organize features or capabilities. The Feature Matrix also organizes responsibilities for teams and individuals.

A B2B buyer uses a feature matrix when a platform spans more than one department or team. The matrix prioritizes different features and capabilities for different stakeholders. The matrix also helps identify non-functional needs from technology and financial stakeholders. This feature matrix is sometimes referred to as a Decision Matrix.

A B2B or B2C creator (supplier) uses a feature matrix when products span more than one market and/or domain. A B2B marketing manager uses a feature matrix to respond to RFPs. RFPs are often created by the buyer from their feature matrix.

What does a Matrix look like for a Buyer?

The example below separates 3 main categories:

  • functional,
  • technical
  • and financial concerns

in a digital (software) buying decision. The weights are fictional example to balance different needs from different stakeholders. The weights are for discussion purposes among diverse stakeholders. The buyer is trying to make a subjective process as objective as possible.

The matrix is often organized in a hierarchical manner within each category. For large platforms such as CRM or ERPs, the matrix may have one to two more sub-categories. In the example below, each category has 1 sub-category.


The prior example also identifies which stakeholders are responsible for scoring their categories.

Buyers of software use a matrix to help gain consensus and avoid risk. The matrix helps avoid an influential individual from making a bad decision for the company.

The weights are often subjective. The important point is that the criteria between vendors such be the same. It is also important that the same people score each criteria (row in the matrix).

A savvy buyer will attempt to quantify the relative difference in dollars or ROI vs simple scores of 1 to 4.

Once a buyer uses a feature matrix to make a decision, it is often discarded. A savvy buyer will use the feature matrix to create an implementation roadmap. The savvy buyer will attempt to measure value realization after the implementation.

What does a Matrix look like for the Creator or Product Manager?

The feature matrix for a Product Manager looks like the feature matrix for the Buyer. However, the Product Manager or VP of Product needs extra/different columns or dimensions. These are the 2 most common dimensions for Product Teams:

  • Target Persona - who is likely to use this feature? How important it this feature to this persona?
  • Codebase/database - in an M&A, which of our codebases have similar features? Which particular codebase best delivers this feature or capability?

The following example illustrates the Importance to different Target Personas. During or after an acquisition, a matrix such as this helps identify which products or platforms fit different markets. Early in the acquisition, Sales and Marketing can identify the right product fit for a new prospect. Later in the acquisition, the matrix can help inform a platform consolidation.

The following example illustrates the Strength or Quality of different features by codebase. These codebases are often referred to by their original product brand names. Sometimes they are an internal name that is only understood by engineers.

These additional dimensions to the feature matrix can help steer platform consolidation approaches. Engineering teams care most about this dimension. Engineering teams often re-organize around these clusters of features or business domains.

Case Study of a Feature Matrix for M&A

We have helped many clients create a product platform strategy after mergers and acquisitions.

Recently, we helped a multi-national company in the learning industry. Our client had merged with or acquired over 20 separate entities over 2 decades. Each entity had bought or built their own Learning Management System (LMS). All of these systems were used directly by their customers. Our client was able to merge these 20 entities into 2 separate codebases. Our client asked AKF to determine which of the 2 codebases should be selected going forward. To help inform our analysis, we worked with the Head of Product to create a strategic Feature Matrix.

Our client had a strong Head of Product. He already had a feature matrix organized for one of the two codebases. The matrix had 2 levels of functional groupings. This was very helpful to the engineering teams to understand what they were building.

He had also analyzed and compared features across codebases. However, he did not organize his codebase analysis in the same matrix (spreadsheet). He was unable to explain to executives how different codebases were designed for different buyers and users (personas). Furthermore, executives were blind to the depth and breadth of their products and services.

By using the approach described above, the Head of Product was able to capture and convey a large amount of information. With the use of pivot tables in a spreadsheet, he was able to zoom in and out of feature groups. He was able to show which codebases fit different markets. With conditional formatting (e.g. colors), readers could compare large amounts of information. The feature matrix served as the map for the joint product and engineering teams.

When should a Product Team have a Feature Matrix?

Heads of Product often ignore or neglect a Feature Matrix. The VP of Engineering or CTO can create one if Product reports to Technology. In most cases, the head of Product should own and maintain a Feature Matrix.

We have found a Feature Matrix helpful in these situations:

  • Sales training - a feature matrix helps the B2B sales team understand how prospects buy their software. It also helps a team respond to RFPs.
  • Marketing positioning - a feature matrix helps organize competitive analysis for strategic positioning.
  • Product strategy - a feature matrix helps product teams focus on underserved markets.
  • Engineering org design - a feature matrix can be a helpful input to splitting a large codebase into smaller services. Feature groups with frequent changes are good candidates for splitting off a new service. Follow our guide to know when to split a service versus keeping a monolith. 
  • Mergers and acquisitions - particularly for digital first companies, a feature matrix informs an integration roadmap. For traditional companies with IT departments, these matrices help with ERP and CRM consolidation.

Where AKF can help

If you need help with a digital platform strategy and architecture after several acquisitions, please contact us. We can lead these exercises or teach you how to create and maintain these artifacts. We can also teach your engineers how to safely split a large codebase or avoid rebuilding an entire codebase.