The End of Silos: A Case for a Leaner SaaS Organization

As the world is moving towards empowered end-users, self-service, and inbound over outbound, I think it is time we consider re-evaluating the SaaS organization.

When we built out the old SaaS organization, we kept adding departments. For example, when Customer Success became a thing, it was added as another organizational bucket. But the downside to having these buckets is that they still rely on cross-department collaboration, and having different departments just leads to wasted time on reporting, overhiring, internal battles, and misalignment. In my view, it’s time for a new simplified SaaS organization.

In Userflow, we are only three people. My co-founder takes care of Product management, design, and development; he has one designer on his team. My role is to handle our GTM functions, including sales, sales engineering, customer success, marketing, and partnerships. This, combined with my experience building Cobalt, was part of my inspiration for the below suggestion to change the SaaS organization into a simpler organization built for a Product-led future.

A New SaaS Organization

The standard advice for scaling startups is to further specialize your organization in more departments as you grow, but if I were to scale our current organization, I would instead scale below the department structure we have today: Product and GTM. One can accomplish this by keeping certain roles aggregated and only having specialized roles for functions that are truly needed.

3 suggestions for how to achieve this:

1. Merge Sales, Customer Success, and Sales Engineering into Product Experts

In my view, the best sales and customer success managers are the ones who

1. Both are able to sell to and support a customer.
2. Understand the product inside-out. You can no longer simply rely on having a sales engineer to help with all the answers.

Therefore I am an advocate of merging sales, customer success, and sales engineering into a single role called Product expert. This role will be able to do product-led sales and success. For some highly technical products, this might not be feasible; but for the Standard SaaS organization I believe it would.

2. Keep functions that work closely together in the same department

To avoid having too many management divisions and layers leading to alignment meetings and more, I suggest we put functions that work closely together in the same department. E.g., Engineering, Product, and Design who already work together in pods. Each of these can still be separate subteams, but ultimately they report to the same leadership.

3. Measure both departments on revenue

To ensure alignment, both the Product and GTM functions should have shared revenue goals and work closely together to create a highly collaborative organization. Everybody in an organization should care about revenue. Having two departments instead of 5+ makes this alignment significantly easier.

Does it Scale?

You might argue that having a successful three-person organization is insufficient evidence to prove that such an organization will scale. And yes, first of all, it is currently just an idea/suggestion, but there are several industry trends that are already pointing to a model like this that could work. Below, I highlight three of them:

1. The rise of the Chief Revenue Officer

A natural progression as a SaaS company grows beyond a certain size is to add a Chief Revenue Officer, to whom the VP of Sales, VP of Marketing, and VP of Customer Success report. This is partially to decrease the reporting workload on the CEO, but it is also a way to create alignment between the three areas. This trend shows the power of these three functions being even closer together and reporting to the same management, as I suggest in the New SaaS organization.

The only thing I suggest we change in relation to the CRO is the title itself. As mentioned, I believe that in a PLG world, not only the go-to-market team but also the Product team should be measured on revenue to drive the right incentive and business understanding.

2. Successful PLG companies that grew without sales teams

There have been many PLG success stories. One of the most impressive ones is Aha! Who bootstrapped to $100M ARR. For a long part of this journey they did not have salespeople. Instead, they relied on customer success (or product success as they later called it). A quote in the great story shared by Danny Archer, Aha! Employee #4 on Kyle Poyars newsletter highlights this:

“We called the sales-assist team “customer success” for the first six years. The role wasn’t the same as what everyone knows as Customer Success now; that more traditional CS function later became our “product concierge” team.

The “customer success” title changed into “product success” around mid-2022. The profile we hired for was very different from a traditional sales rep—we looked for prior product management experience, not prior sales experience. The idea was that folks who grew up in product management would be naturally consultative with our target customers.”

This aligns closely with my thoughts around Product experts: sales, customer success and sales engineering melting together to a single function.

3. The increased popularity of PLG and self-serve

As I wrote in my article Product-led Growth – What it is, and why you need it, PLG is gaining popularity in the SaaS industry. Almost any SaaS company of any size strives to build some form of a PLG motion. rimarily, this is because the modern end-user wants to self-serve and has been empowered to drive decisions on tools. As Openview puts it, we are in the end user era. In such a product-led end-user world, an outbound sales team is less important, the responsibility of sales and customer success is hard to differentiate, and the product team gets more responsibility to drive revenue for the business by building free trial/freemium activation flows and product-led onboarding. In my view, the old SaaS organization simply won’t work in a PLG setup.

What’s Next?

At Userflow, we will continue our growth journey with a simplified SaaS organization, and I am excited to see where it takes us. I also hope to see larger SaaS organizations challenge the existing organization structure, even if they do not do something completely similar to my suggestion. SaaS has changed, and therefore the organizational structure needs to change as well.