One of the by-products of a connected world is that the services (SaaS) we choose to use, having a greater value for us the more connected they are to other services/products. We are shifting from a product & platform (OS-centric) world to an ecosystem world. This has a huge impact on how you design products for success.
Take Slack as an example, Slack grew rapidly even though there were a number of competing services available at the same time. Slack did two things really well
- They designed the sales process to be focused on product qualified leads vs sales qualified leads (this is a topic for another post)
- Slack’s strategy was to be connected to as many other services in the User’s ecosystem as possible, and to become the launching point of interaction between these services.
Slack’s strategy was not just a customer experience, but also a simple API (even the their bot is an API) that enabled them to accelerate their importance in the user’s ecosystem.
Products/services that want to be truly engaging, need to aim at persistence. This means designing beyond user usability into a background connected data stream that feeds into other services. In a SaaS world, you need to think beyond your user interfaces to your application programming interfaces (APIs).
A Persistent user’s behavior is often invisible to them. Once you have the users engaged and using your service, your key aim must move to designing services that other services can consume in the background – thus deeply ingraining yourself into the user/customers ecosystem, which reduces the risk of switching and increases your power/value in the user’s ecosystem.
This means not only designing for simplicity of integration, it means having a strategic view of what the total ecosystem could look like, and where you fit into it.
This strategic analysis needs to consider whether you are a feature, a platform or a service.
A feature in the SaaS sense solves a very specific set of problems but does not own the data, i.e. it does not originate it, nor does it own the endpoint where the data is transformed into something else. Data includes users, source files, logs/analytics etc. a feature is continuously in danger of being designed out by its partners i.e. services upstream and downstream add the feature into their service and thus reduce the need for your offering.
A platform provides a base for others to develop services or features with it, traditionally they are technology-based, encapsulating a wide variety of reusable functionality that is generic but complex enough that recreating it is too hard to undertake on a project by project basis.
A service owns either the input or exit points of data and undertakes a key set of transformations to increase its value via bespoke functionality. Sometimes, this data can be proprietary increasing its value, sometimes it can be connectors or integration points. Licenses, like banking & telecoms or preferential/exclusive access like Oracle’s data cloud, provide these services with long-term market power – even while they may seem to be becoming utilities.
While you could monetize at any point along this continuum, the drive should always be to increase market power through asymmetry of access to data you control. In a world where connection to other services is a key benefit – controlling this as tightly as possible becomes a strategic requirement. Where does this leave you?
