This article was originally from a presentation at the Product-Led Festival, which you can watch here.
My name is Natan Cohen, I'm the Head of Solution Architecture at Qrvey, a platform for SaaS organizations looking to tightly integrate self-service analytics capabilities into their own solutions.
In this article, I’ll talk about the best ways of delivering your SaaS application solution as quickly as possible and various strategies for maximizing your ROI.
Since we now live in a subscription-only world, we'll be focusing almost exclusively on that type of model.
Topic areas include:
Let's get into it 👇
The SaaS solution/product landscape
What is a Saas solution/product?
First and foremost, if you identify as a SaaS organization you offer software as a service and you'll typically ensure that your product and solution supports multi-tenancy.
When we use the term multi-tenant we don't mean multiple customers, but rather, we're implying that multiple customers can safely and securely use the same application that may be deployed to the same environment.
Sometimes, the application of service is the core offering for a SaaS organization, and other times it's created to augment an existing solution or offering.
Pricing is typically based on a tiered subscription model. If you're building a SaaS solution this decade, then you'll almost certainly have a cloud-first deployment. Not necessarily cloud only, it could be cloud hybrid, but typically, you're going to find some component of that solution to be cloud first.
SaaS companies are all the rage
The number of SaaS companies that exist today far exceeds the number that existed a decade ago, or maybe even just a few years ago. SaaS companies now exist to support almost every type of industry, and they're highly specialized. There's a lot of competition and they typically need to move very fast to bring their solutions to market.
The primary motivating drivers for offering a solution
There are at least three primary motivating drivers for offering a solution for SaaS organizations, each one significantly different in terms of why you're creating the solution.
The most common is to create a market differentiator, which is to specialize and to either solve a new problem that hasn't been solved before or solve a common problem in a new way.
Alternatively, you could be looking to expand your roadmap by offering an entirely new set of capabilities for your existing solution.
The third driver is that you might be trying to break into an entirely new industry.
Go-to-market strategy
The three strategies I’ll cover in this article are:
- Phased delivery → what you should be including in your MVP and what can be saved for a future phase.
- Tiered subscription model → how many tiers to have and various strategies to always deliver value, even at the lowest tier, while not giving too much away.
- Pricing models → how pricing can fit into your tiered subscription model.
Phased delivery
The features you choose to develop for the MVP phase (minimally viable product), which is the critical first phase, should stem from the problem or the challenge you're trying to solve.
Another way of stating this is to say that if you can't directly tie a feature to the core challenge you've identified, then perhaps that feature should be saved for a later phase, or should be shelved entirely.
What you consider minimally viable, and what your potential customers consider to be minimally viable, do not always match.
Don't assume! One of the most common mistakes made during the MVP phase, and even subsequent phases, tends to be an assumption that a specific component of a feature could be saved for a later phase when in fact, most of your potential customers would see that specific component as critical for the feature to be viable at all.
For that reason, communication with existing customers, prospects, or future customers should never be a one-off. There should be ongoing discussions, demo sessions, perhaps a pilot program, and maybe even a closed beta with a few select prospects or customers.
Your MVP phase will typically be a substantial upfront effort. After a successful MVP launch, you now have the distinct challenge of keeping your customers excited, engaged, and thinking about how they might expand their usage of your solution.
Ideally, a phase two or phase three release should take less time than the MVP. When you release the next phase, make sure you're able to market at least one defining feature. A defining feature is not an incremental improvement of an existing feature. Incremental improvements are important, but a defining feature gives your existing customers something to stick around for; it gets them excited and gives your marketing team something to talk about and frame what this release is about.
For example, if I were a customer building out a self-service reporting capability within my application, I might structure three phases of releases, where the MVP gives customers the ability to consume baseline standard reports and dashboards (the core value proposition).
In phase two, I might give them more standard reports and dashboards but my defining feature would probably be self-service itself (the ability to create custom reports and dashboards).
Then once those two things are completed, it leads into a third phase, which can be all about automation and forecasting.
Tiered subscription model
The most common model to define your subscription tiers is a three-tier model. Having too many tiers can make your offering confusing and most companies try to avoid the ‘pay for each feature’ model, which makes it hard to budget and forecast their expenses for the year.
The first tier should always offer the core value proposition. Your customers don't want to feel like the first tier doesn't even meet their basic needs or the reason why they signed up and became customers in the first place.
The second tier often adds at least two additional defining features. This makes tier two all about more features and capabilities.
The third tier is usually focused on volume and scalability. Scalability can either be vertically (more content, more data, more users), or it can be horizontally (more lines of businesses within a single organization, or more application integrations within a single organization).
For example in a three tiers model, the first tier could be access to a set of baseline reports. In other words, users can view and they can export.
At tier two, they can do everything in tier one, but they can also have access to self-service dashboards, builders and chart builders so they can view, export, modify, create and share.
At tier three, you introduce everything in tiers one and two, but at higher limits or even no limits on the amount of content, users can create and also allow usage across multiple lines of businesses.
Pricing models
Once we have a phased delivery approach with a three-tiered subscription model, we want to know how to determine pricing and what factors we should consider.
The most common type of value-based model is to approach it from a features and capability standpoint. In other words, the value is proportional to what you can do within the product.
Another way of determining value is to tie it directly to the customer's forecasted revenues or cost savings. In other words, if you're saving X dollars, then we'll take 10% of the X dollars.
A third way would be to tie it directly to the type or the size of the customer's business you're selling into (SMB, SME, or LE). what's the value-based model?
The most common way to define the volume-based model, which is focused on how much, is to base the pricing on the number of users or the data footprint. You could even get more granular and specific with users. For example, it might not be feasible for your customers to pay a per-user fee because they could have thousands of users so you could gate it on the number of creator users. You could also base it on the volume of data your customers plan to use with your solution.
Another way to define volume is if your customer is a large enterprise and you want to base it on the number of lines of businesses that would be leveraging your solution.
A third way would be to gate pricing off of the number of application integrations within the same organization and then scale up the pricing for each additional point of integration within a different application.
And Voila! 🎉
Here’s an example bringing it all together into the same self-service reporting example. I still have my three-tiered model and I've given them names the marketing department can refer to them as:
- Tier one is the Starter Package, this gives you access to the baseline set of reports, which is my core value proposition. I might offer a starter an unlimited user model if they identify as an SMB.
- Tier two is the Professional Package, where I give you access to self-service. Your users can not just view but create, modify and share content. I might offer unlimited users for the midsize business (SMEs).
- Tier three is the Enterprise Package, this would give you higher limits, or no limits on the amount of content you can create. I might allow usage across multiple lines of businesses or an unlimited user model for the large enterprise.
