The SaaS Product Journey

The little I know

Throughout the last decade, I’ve been product-planning, architecting, and managing the development of dozens of SaaS products in different shapes and forms for various audiences and verticals. In fact, over the last five years alone, I have closely overseen more than 20 SaaS web apps ranging from early-stage to large scale production usage under direct or indirect control.

Personally, this time period allowed me to come to some conclusions and gain insights. I tried to find patterns in these complex product development cycles. Being a big believer in the optimization of processes, I started by laying down the “Oops I did it again” moments in each of these projects until I reached a pattern that seemed consistent and repeatable.

In this post, I’m going to define the main life stages of a SaaS product.

Three stages to a SaaS product

The good thing about the “SaaS lifecycle template” is that there are only three stages to it. The challenging thing is that each and every one of these stages brings a complete and live comedy, drama, and horror show. The positive outcome of every step is dependant on many things, some of which are out of our control (and will not be described in this post), and some require a more profound understanding to ensure that we can do our best to hit the positive exit criteria and proceed with our successful and efficient SaaS product journey.

Stage 1 — Lean MVP

“We’re here to make the world a better place. Now, just get the point of our product and let us move on.”

What happens here? Usually, at this stage, several creative people gather together to create a product that will help users achieve something that could not have been done before in the same manner (UX/Costs/Algorithms, etc.)

The main concept is to develop something rather quickly, convince the stakeholders of its validity (management, investors, friends and family, early customers…) and get the approval and/or funding needed to proceed.

How long should it last? You want this stage to be as fast as possible so that you can validate the idea, see that there is a need, receive some good vibes, and move on to actually building your product. The validation stage is usually the most critical phase for many reasons. Although from the product development point-of-view, you want to create a critical mass of product so that the initial demos could be performed, and you could easily understand whether this concept brings value or not. This should be a short stop along your journey, so don’t let it drag on.

What to develop? Well, the features developed here on your product should be fundamental, sometimes just a presentation will suffice. Personally, I believe that a minimal working demo achieves way better results than a presentation. There’s something about going into a meeting with investors or early customers and being able to show them that you’ve achieved something tangible that actually works (and is not just a mock), even if it generates minimal value at this point in time. This allows you to start to prove your proof-of-concept even if not having demonstrated the product viability.

From a features aspect, you should try to concentrate on the backbone needs of the SaaS app, things like authentication, a beautiful overview page with a dashboard, one or two CRUD screens for main handled entities (product specific), and one WOW “knock you over” feature (very product specific).

A WOW feature is what I call the visual representation of the core business value of your concept. This is the single thing that people came to the meeting to watch and often is your unique selling point.

You don’t want to outsmart yourself here. The UX/UI won’t matter since you control the demos so you can overcome things that haven’t been developed yet or thought through completely. Show a basic vision-to-productization and get quickly to the WOW stage.

When do you move on? This one is easy for me to answer. The positive exit criteria for this stage is achieved once you get the approval you’ve been looking for that your concept is worth something. This can come in the form of early adopters, funding, or just from seeing a lot of those “WOW, that’s dope!” faces. You’ll know when you’ve made it. Trust me.

Stage 2 — Version 1.0

“We have some early-stage customers. We have a budget. Now let’s make a product and get traction!”

What happens here? Basically, there’s a company that needs to be built as well as a product. There’s been an interest, and there’s probably a budget available to help transition from the MVP-mode and to start developing towards the company’s launch and first stable release.

At this stage, you want to build something that can last for several years. You don’t want to have to deal too much with scale but also want to build a good foundation for your SaaS product.

How long should it last? Hopefully, this stage will last for a few years, at the very least. During this time, you will perform short interactions, develop new features requested by customers, and validate or contradict your business hypothesis.

This will probably be one of the most active stages of building the product you’ll encounter. Be prepared to remain in this stage for a while, so be responsible for what you build.

What to develop? The features developed in the SaaS product at this stage can be split into two main categories:

1. Core-business functionality
2. Business-agnostic functionality

The first category — the Core-business features include everything that your customers pay you for and the main reason you’re in this business. Make sure that at least 70%–80% of your R&D resources go towards making this part shine. Hopefully, your sleepless nights will be centered around this core value. This must be the essence of your business.

The latter category of features is all the ones that help your customers gain the most out of using your product. I like to call them “Productization Features”. Customer success, support, management, security, visibility are among the common categories of stuff you must provide (not necessarily now but at some point). 

To clarify, here is where you’ll have to develop some of your Enterprise-Readiness features (depending on your product vertical and customer segmentation) such as Advanced Authentication (SSO, Multi-factor authentication), Roles & Permission management, Audit logs (aka Activity logs, Audit trails), Notifications and Alerts, Reporting, Licensing, 3rd-party app integrations and many more. Usually, these features are for parity but can also prove to be an essential part of your differentiation if your competitors have not invested too much effort here.

When do you move on? There are several possible outcomes for exiting this stage.

Pivoting… A pivot or discontinuity of the product could be one of them. In this case, you would iterate to create new versions with different sets of features (maybe even aimed at varying types of users). The critical thing to remember is that all of the “Business-agnostic functionality” features you’ve built and the good practices you invested in when building your core features, could be reused at this stage and do not need rebuilding from scratch.

Growing big time… These are a rich-man’s problems! We’ve made a great product, and we’ve been able to grow a great company.

Stage 3 — Rewrite Everything

“We’ve made it! The hard work has paid off, and now it’s time to rebuild the perfect version.”

What happens here? As mentioned in the previous exit criteria, you’re at this stage because what you built led to tremendous success, and someone really wants you to continue doing what you’re doing and, well, rebuild it. “Rebuild everything?!” you may ask? Well yeah, it’s just part of the lifecycle of a product, and this stage will usually happen to the companies that succeed. The reasons are many. For example (1) M&A which makes the buying company want to embed the product as part of their product line (2) Moving to Multi-product mode, which means you want to develop a platform of products now and the initial product needs to become a part of this platform or (3) Big-scale occurs, meaning the “lean approach” you’ve taken over the years to get to this point have amounted to something that is really monstrous and can not be scaled without a complete (or a massive) rewrite.

How long should it last? This is the stage where your initial product, or whatever will be left of it post-re-write, will live forever (or at least until it’s shut down).

What to develop? At this stage, you will gather everything you’ve learned until now and apply it to a perfectly rewritten product. There needs to be serious product management done before diving into engineering. The PM will usually gather all the user stories currently covered and are in use by existing customers, then add them to a list of requests from different stakeholders for the new product. The PM will then add all the features they ever requested from R&D but were pushed back (“this would take months to deliver, so pick what you want to exclude from the release…” – quote from the engineering manager) and prioritize them into a final scope of work. This list then moves over to the engineering manager and team, who then work on evaluations and estimations. Prepare for a long project.

Some of the backend components can be reused, but most will need to be rewritten from scratch since they do not meet scale. 

The interesting (and scary) part here is that “second category features” (aka “Business-agnostic functionalities”, or “Productization features”) might also require rewrite at this stage. For example, the SSO might require more security and support for more Identity Providers. It’s possible that the technologies and standards for doing SSO have changed, and your initial development (if you chose to develop this by yourself) does not apply anymore. One instance of this is the introduction of OpenID connect, which has become a standard for SSO during the last few years. 

Another example of backend feature rewrites is that, now that you’ve grown big enough to have a large number of customers, there are also many more 3rd-party integrations required, if Slack was enough a year ago, MS teams and Discord might be requested by your customers at this point of time. Scale and privacy demands for Audit Logging are much more significant at this stage, as is the case for many other features.

Besides feature requests, the technological aspect might also affect the decision on whether to rewrite certain features. For example, on the frontend side, we might choose to perform a rewrite due to technological evolution, e.g., adoption of new-age UI frameworks like React and Angular which happened a few years ago. Adopting concepts like micro-frontends at the early stages of a product might ease this process, although I wouldn’t recommend forcing generic approaches into those early-stages. Keep it lean and as customer-centric as possible.

To Summarize

Developing a SaaS product involves developing features and functionalities that vary depending on the stage you’re at. Carefully selecting the correct features and focus for each stage is crucial so that you can focus on what really matters. Making the right product/technological choices at an early stage is also crucial. Choosing to dive deep into certain features that are not centered around your core business value (just because “it would take me only three days to develop”) puts your entire organization (product, developers, QA, DevOps, SREs) at risk. The ROI is significantly lower, and you can find yourself in vast amounts of product and technical debt.

Choose carefully what you build and when you make it and always keep in mind what the real goal is of the stage you’re currently at.