As a software engineer you should be no stranger to the word feature. You may be part of a feature team working on a user feature in your feature branch implementing a feature toggle, wondering what went wrong in the feature prioritization meeting that lead to this feature creep.

Features aren’t bad and they are in fact the primary way for a product to deliver value and benefits to the user. But features shouldn’t be the only lens you use when developing your product. By shifting your approach from delivering features to developing capabilities, you’ll be able to unlock a lot more from your sprints.

So what is a capability? I consider capability as the fundamental building blocks that makes up a feature. A feature may require a few different capabilities from your product to function. The same set of capabilities could also be packaged as different features to different users.

Build re-usable capabilities

Here at Mindvalley, we are building a learning platform to deliver high quality, transformational content to our students. An important feature for the platform is a robust media player on our mobile and web clients to serve video and audio content. We had to make sure we are able to stream content properly to our users.

Part of the feature specification is to implement a media transcoding pipeline for all our content. We developed it as a stand-alone service so it can be utilised by other parts of our ecosystem. In this instance, we developed the capability to transcode media content and then package it as part of the media player feature. This particular service has out-lived 2 iterations of our learning platform. 

Extract capabilities from existing features

You could also start with a feature and later extract common functionality from it as a capability. This is useful when you are experimenting with certain features and aren't sure if it will work out. On our mobile apps, we wanted to provide new users a taste of our content. We experimented with a simple on-boarding quiz to gather user interest and recommend them some relevant content. 

The backend was initially powered by Google Sheets. Only after we are able to prove that the feature provided value to first time users did we consider replacing the backend with something more proper.  However on the mobile clients, we made sure we have A/B testing capability from the get-go to allow us to test different versions of the quiz.

When we decided to rebuild the backend, we approached it from the perspective of providing our learning platform with a quiz engine. This capability allow us to not only power our initial on-boarding quiz but also serve as an important component in our future Adaptive Learning product roadmap.

Capabilities aren’t limited to architecture and infrastructure

It is quite common for engineers to rely on the underlying architecture and infrastructure to provide certain capabilities. A micro-service architecture lends itself well to agile teams developing capabilities in isolation while deploying your platform with Kubernetes will allow it to scale horizontally and be more resilient to failures.

Instead of relying only on your Infra team to develop capabilities, involve everyone at every level to start thinking from this perspective. From the way you design your APIs to the way you organize your code.

The main take-away here is to identify the common foundational building blocks of your product. The better you are at this, the more capabilities you can leverage in your next feature.

If you learned something from this article, do share it with your friends. And if you have a minute, subscribe to my blog for more insights like these.

Photo by La-Rel Easter on Unsplash