post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

mission statement

Deep dive: Crafting your product vision and mission

Podcast

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

René is an experienced product leader who spent the last few years helping several SaaS start-ups in the creator space. He is a self-professed product geek, developer, blogger, and outdoor adventurer. He is passionate about creating high-quality products users love. His background includes roles in development, consulting, project management, and enterprise agility.

Rene Rosendahl

<p>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.</p>
<p>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&#8217;ll suggest a tool to help with these concerns—the concept of “feature set maturity”.</p>
<h1>Feature sets</h1>
<p>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.</p>
<p>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:</p>
<ul>
<li><span style="font-weight: bold;">Display</span> a map in different modes (standard or satellite map) with appropriate ways to manipulate the view (zooming, panning, rotating, etc.),</li>
<li><span style="font-weight: bold;">Finding</span> places (by name or address), and</li>
<li><span style="font-weight: bold;">Routing</span>, 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.</li>
</ul>
<p>Then there are secondary feature sets, such as:</p>
<ul>
<li><span style="font-weight: bold;">Personalization</span> such as managing bookmarks of places you’d like to remember, dropping pins, etc.</li>
<li><span style="font-weight: bold;">Discover</span> and explore places or businesses (with photos, reviews)</li>
<li><span style="font-weight: bold;">Traffic</span> integration (current speeds, potentially even with accidents, road construction)</li>
</ul>
<p>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?</p>
<p>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.</p>
<p style="text-align: center;"><a href="https://www.mindtheproduct.com/%e2%80%8b%e2%80%8bproduct-design-practices-to-spur-customer-adoption-in-any-industry/" target="_blank" rel="noopener">Read​​ Product design practices to spur customer adoption in any industry.</a></p>
<h1>The maturity model</h1>
<figure style="width: 1600px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/03/fd130959-b9bf-4eec-9d1b-213a975cdfa4_screenshot_4013.png" alt="The maturity model" width="1600" height="898" /><figcaption class="wp-caption-text">The maturity model</figcaption></figure>
<p>Each feature set has its own <span style="font-style: italic;">functional maturity</span> that describes how well developed and extensive the feature set is. I like to distinguish the following levels:</p>
<p><span style="font-weight: bold;">Level 0 &#8211; Foundation/Infrastructure</span> &#8211; 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.</p>
<p><span style="font-weight: bold;">Level 1 &#8211; Basic Functionality</span> &#8211; 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.</p>
<p><span style="font-weight: bold;">Level 2 &#8211; Rich Functionality</span> &#8211; At level 2, the feature set is mature, quite extensive, and provides more sophisticated functionality.</p>
<p><span style="font-weight: bold;">Level 3 &#8211; Advanced</span> &#8211; 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.</p>
<p>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.</p>
<p>For most products, <span style="font-weight: bold;">core</span> feature sets should be at level 2 (rich) to offer a solid experience to your users.</p>
<p>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).</p>
<p style="text-align: center;"><a href="https://www.mindtheproduct.com/build-better-products-with-effective-mvps/" target="_blank" rel="noopener">Read Build Better Products With Effective MVPs</a></p>
<p>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.)</p>
<p>For <span style="font-weight: bold;">secondary</span> 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.</p>
<h1>Uses</h1>
<p>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?</p>
<p>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?</p>
<p>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.</p>
<p>Lastly, it might be useful to also look at the competition and analyze how our app stacks up.</p>
<h1>Anti-Patterns</h1>
<p>With the understanding of feature maturity and what the various maturity levels are, there are several anti-patterns to avoid:</p>
<h3>Weak core</h3>
<p>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.</p>
<figure style="width: 952px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/03/fb8a63f8-1613-49bd-a4ea-f2df8012aa95_screenshot_4015.png" alt="Core vs Peripheral feature sets " width="952" height="622" /><figcaption class="wp-caption-text">Core vs Peripheral feature sets</figcaption></figure>
<h2>Strong peripherals</h2>
<p>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.</p>
<figure style="width: 930px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/03/424c63be-9d06-4483-9362-a752444eb4d8_screenshot_4017.png" alt="Core vs Peripheral feature sets" width="930" height="620" /><figcaption class="wp-caption-text">Core vs Peripheral feature sets</figcaption></figure>
<h2>Core imbalance</h2>
<p>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.</p>
<figure style="width: 930px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/03/25232302-93c9-4be0-ad51-96df08dc2c20_screenshot_4016.png" alt="Core vs Peripheral feature sets" width="930" height="646" /><figcaption class="wp-caption-text">Core vs Peripheral feature sets</figcaption></figure>
<h2>Spread too thin</h2>
<p>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.</p>
<p>(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.)</p>
<p style="text-align: center;"><a href="https://www.mindtheproduct.com/developing-innovative-digital-products/" target="_blank" rel="noopener">Read Developing innovative digital products</a></p>
<h1>Visualization</h1>
<p>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.</p>
<figure style="width: 1328px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/03/6924b0f8-63e2-49be-afaf-06fba6699b66_screenshot_4019.png" alt="Feature trends over time" width="1328" height="954" /><figcaption class="wp-caption-text">Feature trends over time</figcaption></figure>
<figure style="width: 1418px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/03/30673cb3-bc1e-40cf-9257-ae68b349036d_screenshot_4020.png" alt="Feature trends over time" width="1418" height="684" /><figcaption class="wp-caption-text">Feature trends over time</figcaption></figure>
<h1>Wrapping it all up</h1>
<p>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.</p>
<p>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.</p>
<p style="text-align: center;"><a href="https://www.mindtheproduct.com/tag/product-market-fit/" target="_blank" rel="noopener">Discover more content on Product/Market Fit</a></p>

Understand your application’s feature set maturity

Rene Rosendahl

Read more

Comments