SaaS Product Readiness Pyramid

Most great products involve vision and practicality. On the vision part, you would want to innovate with something that you came up with and you imagine it can solve many problems out there. On the practicality part, some of the features you will build in your product would center around requests from customers, or potential customers. This is what “Customer-Driven Product Development” is all about. Usually, when fulfilling such requests there are several levels of readiness. Each one provides a business value and solves a problem. In this post, I will walk through the Feature Readiness Pyramid of SaaS. That includes three main tiers.

Feature Readiness Pyramid of SaaS

Real-Life Example — SSO functionality

Let’s consider this user story: “As an enterprise user of ACME SaaS platform, I would like to be able to federate the login process of my organizational users to our organizational identity provider”

A very visionary (or not so experienced) product manager would start to build the most amazing experience mock-ups around this user story, just to realize that building it perfectly might lead to exhausting 3 sprint epic, which would cause the R&D team not to deal with other crucial features.

On the other hand, we want something that works, even if it’s minimal, that can fit one sprint of development and provide a business impact!

Let’s try to break down the pyramid into its three tiers, by pushing our SSO user story along.

First tier — Functionality

When a feature request pops-up it would usually go out for voting, and when the time comes and it became important enough to implement, the first thing we would do is try to “solve the business problem”. That would usually involve an Alpha stage of the feature, which will enable basic functionality around the user story. The state of mind here is important, we’re still not sure that this feature will become a standard in our product, so we would not want to invest too much effort into it. Let’s solve the problem, enable business, and LEARN.

The user needs to get from one place to the other to pass a message, and you’re basically just saying: “Listen, you don’t really need to get there, just let us go there on our own and pass the message for you”.

Functionality — Example through SSO capability

Enabling functionality around SSO will be fulfilling the basic need of the customer. If the enterprise customer wants to be able to federate logins to their IDP, perhaps the minimal viable feature would be:

1. The customer would open a request to configure their Okta SSO, with all the required details
2. Customer-support will configure the Okta SSO on the backend
3. Customers will be able to log in via federated SSO using their Okta identity provider

That’s amazing, the business request was fulfilled. Is the experience perfect? Probably not. (1) What if the customer needs to make some changes in the configuration? (2) What if another customer needs a different identity provider rather than Okta? (3) What about mapping the roles of the organizational user groups to the ACME SaaS roles?

Of course, the solution is sub-optimal at it’s best. But it works. The quality must be amazing, no bugs might exist at this stage. The functionality exists, but there’s no control and no user-experience.

Second tier —Control

The second stage would typically involve providing some level of control for the end-user. Usually, this would be the next step in making the feature work, but also maintainable on some level of practicality. Usually, we can move the usability up a notch by providing some level of documentation, external APIs, or even easing down the process of making the user story completed from the customer’s point of view.

The general idea here is to allow the user to get from one place to the other and pass their message by picking up rides on the way or taking the bus. Not an amazing experience but at least they have control over the ride.

Control— Example through SSO capability

For example, if the ACME SaaS has 100 customers that have been waiting for the SSO feature, it would probably not make sense to have the support team maintaining the feature for them and handling every change request. But do we have to build a full-blown SSO control? Not entirely, the control tier in this case could also be an external API with documentation. So we open up an API (by utilizing an API system we already have in place) and providing documentation on how to set up an SSO configuration.

That’s cool, the business request was fulfilled and the customer also has some level of control over the process. But is the experience perfect now? Well… Not so much. For example, what if there are no developers that can help the customer set up the process? Is this the best user experience we can provide?

Third tier —Experience

The concept is simple. If the feature was required, and not only once, but really required — by customers. Then let’s make a hell of an experience from it. Let’s move the full control for the customer.

They want to get from one place to the other, sure, let’s provide them with an app in which they can just click on a button and order a ride, every time they need to go somewhere.

Experience matters- that’s why customers get back to you.

Experience— Example through SSO capability

It might sound like the most complicated step, but actually it’s simple, let’s build an amazing feature around SSO configuration. It should be a self-service process. A customer logs into the system goes to their account configuration and just configures their own SSO, the whole nine yards. The next time they log in to the account, it is all set up and login federation is performed. What if the customer forgot to do some mapping of roles or wants to change something? No problem, just login into the account and change some SSO settings. Amazing!

Inversion of Control in SaaS products

The idea in the last step is what we call at Frontegg — “The Inversion of Control of SaaS products”. Basically, we want to move the control to the customer’s end. We would like to provide a full experience in which the end-user can have full visibility and full control over every capability in their SaaS application. You can solve core problems by providing the most basic level of functionality the customer needs to do business, you can even ease the process a bit by providing some level of control to their hands, but at the end of the day, a real enterprise-readiness of your product will be determined by how much self-service is enabled in your offering and how much it is built for scale of business.