As “product people”, we own and nurture software products with the goal of creating value for our customers (users) and achieving business results for the organizations we’re part of.

We need a way to articulate how well-developed (or nascent) the different parts of our application are, make decisions on where to invest time and effort, and layout a roadmap showing the progression of our app. (And once in a while we also need a way to peek at and compare ourselves to the competition). In this post, I’ll suggest a tool to help with these concerns—the concept of “feature set maturity”.

Feature sets

Feature sets are the main functional building blocks that make up our software. Some of these feature sets are primary or core as they provide the main functionality that makes our applications what they are. Other sets are secondary or peripheral, as they support the core feature sets, but they’re not the main ways our application delivers value.

Let’s look at an example: a typical map application on your phone or PC (e.g. Apple “Maps”). I would consider its core feature set:

• Display a map in different modes (standard or satellite map) with appropriate ways to manipulate the view (zooming, panning, rotating, etc.),
• Finding places (by name or address), and
• Routing, i.e. providing directions based on the mode of transportation (walk, drive, etc.) while taking into account road types and average speeds to arrive at an estimated duration.

Then there are secondary feature sets, such as:

• Personalization such as managing bookmarks of places you’d like to remember, dropping pins, etc.
• Discover and explore places or businesses (with photos, reviews)
• Traffic integration (current speeds, potentially even with accidents, road construction)

These non-core feature sets are still important, but in and of themselves, they’re not as significant as the core ones. Example: Who cares if you can see detailed accident information if you can’t properly find a location via its address?

If you’re not entirely clear which of your application’s feature sets are core vs. peripheral, it could lead to some interesting conversations in your organization to figure out and agree on what your product’s core feature sets are.

Read​​ Product design practices to spur customer adoption in any industry.

The maturity model

Each feature set has its own functional maturity that describes how well developed and extensive the feature set is. I like to distinguish the following levels:

Level 0 – Foundation/Infrastructure – This feature set does not exist yet visibly to the customer, but the foundational capabilities exist in the backend (below the surface). For many feature sets, level 0 is a required investment before the rest of the application can be built. Example: Processes and data to enable performant analytics.

Level 1 – Basic Functionality – This feature set is not overly mature yet but fully functional. This level represents at least table stakes; anything less would be too meager to even be considered functional and competitive in the marketplace.

Level 2 – Rich Functionality – At level 2, the feature set is mature, quite extensive, and provides more sophisticated functionality.

Level 3 – Advanced – This is the highest level and means that this feature set is fully developed and satisfies even advanced users. Depending on the packaging and pricing approach, users might pay extra for more premium functionality.

The visualization as a pyramid is intentional: Layers have to be stacked in order and the levels have to be “built” from the bottom up. A foundation, even if “thin”, is always needed. Basic functionality has to be introduced before richer functionality can be delivered. It’s not reasonable to leapfrog or skip levels, e.g. after introducing basic functionality it won’t be feasible to go straight to advanced and premium in one step.

For most products, core feature sets should be at level 2 (rich) to offer a solid experience to your users.

There are some exceptions to this depending on where the market and the competition are. If you’re introducing a new type of application in a non-existent or barely established market with few competitors, a level 1 feature set may be sufficient as an MVP to get your product out there. (Think about the first mapping application, which likely only offered only very basic functionality. Fast forward to today though).

Read Build Better Products With Effective MVPs

If, however, the market and the competition are already well established and mature, a new entrant in the market will likely not be able to get away with a level 1 feature set. (A new app in the now mature mapping market will need to provide advanced features to compete and gain market share.)

For secondary feature sets, it’s often sufficient to offer basic functionality as they play only a supporting role unless these are delighters aimed at differentiating the product from competitors. In that case, however, these feature sets should probably be considered primary as they represent the core competencies of the application.

Uses

This model as a way of looking at your application can be useful in several ways. First off, it leads to healthy conversations around what an app really is about and what it isn’t, what’s core vs. peripheral, and how it tries to compete. How is its scope? Just right or too wide or narrow? Where do customers expect more?

It’s also a good way to visualize overall functional maturity and can guide conversations around where to invest time and energy. Does it make sense to build out the core or focus on secondary feature sets? Are there imbalances to fix? Does it make sense to extend the app and add feature sets?

Related to packaging and pricing, this model could also spawn discussions related to introducing a paid premium tier or deliberately giving advanced functionality away for free.

Lastly, it might be useful to also look at the competition and analyze how our app stacks up.

Anti-Patterns

With the understanding of feature maturity and what the various maturity levels are, there are several anti-patterns to avoid:

Weak core

An application whose core features are weak is not likely to be successful in the long run. Efforts should be directed at quickly maturing the core feature sets.

Strong peripherals

As long as the core features are reasonably well-developed, having very strong secondary feature sets is not necessarily a big problem, especially if they might provide a competitive advantage. However, instead of spending too much effort on advancing the secondary feature sets, it may be more beneficial to advances the core feature sets first.

Core imbalance

If your application relies on several core feature sets, it’s best if they are similarly well-developed, so they’re not in an imbalance where some sets are very advanced while others are too basic.

Spread too thin

Few applications can pull off being a jack of all trades. If an application tries to incorporate and support too many feature sets, the application tends to get “big”, hard to use, and its core value proposition might get diluted. Organizationally it will also be challenging to support all the feature sets with ongoing improvements as the development organization is spread too thin.

(If you believe all those features sets are crucial to the success of your application, it might be time to consider solving for some of the peripheral areas by integrating with 3rd-parties instead of continuing to maintain them all yourself.)

Read Developing innovative digital products

Visualization

As seen above, bar charts are a great way to visualize feature set maturity to make them more useful for discussions. Additionally, you might also experiment with spider and line charts to illustrate trends over time or even compare your app to a competitor.

Wrapping it all up

At the end of the day, we all need to find a limited number of core areas where our application stands out and can truly shine by delighting users. Additional feature sets are there to round out those core capabilities without creating distractions or diluting our main value proposition.

Hopefully, the application maturity model has given you a new way to reason about your application’s feature sets and spawned some ideas about how it might be useful in your organization, influence product roadmaps, and serve as a catalyst to deciding where to focus energy.

Discover more content on Product/Market Fit