🏗 Why do SaaS Startups struggle to build Self-Serve products?
🏗 Why do SaaS Startups struggle to build Self-Serve products?
Understand the necessary steps and explore ways to speed up the process.
We talked to 150+ SaaS builders, and SaaS growth enthusiasts And these are the
Top reasons we heard
Challenging for 1st time PLG teams: First-time founders and CTOs find it extremely challenging. It takes 2+ yrs to build towards it.
PLG is not their core DNA: Most startups do not understand what they need to do to make their products self-servable for their end-users.
No Standard Specifications: Building for PLG is very different from building a classic B2B SaaS product for SLG.
Engineers attempt to stitch different tools together: Typically, they have to choose and stitch 20+ different categories of tools, with a total of 400+ individual products (as of early 2024).
Analytics and GTM teams depend on Product Engineering: Until a basic product is ready for self-serve, growth teams can’t do much. They tend to wait on Product/Engineering to show some proof-of-concept.
Building and Operating Self-Serve is non-trivial, expensive and custom
PLG Readiness is a new chasm. Most early-stage SaaS companies burn 30-40% of their raised capital in building the self-serve infrastructure
Implementing Product-Led Growth (PLG) in a SaaS company involves a collaborative effort across various departments. The effort in terms of spend and time can vary widely depending on the size of the company, the current state of the product, and the specific PLG strategies employed. Below is a table that outlines a general framework for the effort required by each department.
Which departments need to work together?
The following is a departmental breakdown of a mid-scale $10-100M ARR company focusing on PLG+ motions.
Note:
The number of individuals involved and the spending are indicative and can vary.
The spending includes salaries, SaaS tools, training, and other resources.
A successful PLG strategy often requires a cultural shift and buy-in from all levels of the organization.
Continuous iteration based on user feedback is crucial for PLG.
① ENGINEERING an end-user-initiated (Self-Service) product is very different than building for Sales-Initiated products.
Sales-led approaches are in sharp contrast with self-serve products. The sales team initiates a Proof of Concept with customers, initiates an account(tenant) provisioning request to the Engineering/operations team, invites the customer’s admins, on-boards them and gives them a usecase-by-usecase walkthrough.
Product and Engineering teams have to build for
User-initiated actions like Signup, Try, and Buy.
In a self-service world, end-users are in control of signing up to your product, trying and buying small (most times). Building for event-based user actions requires orchestration across tools and teams.
With end-users initiating most of the actions, it is now imperative to do the following
Authenticating an end-user
Auto-enriching the end-user to find out details of the demographic and firmographic profile
Adding to wait lists – especially in case of blocking a surge of users signing up while they pilot with a small set of known customers
Granting User Access to the product
Onboarding the user – helping them set up and use the product
Enrolling the user/account into a Free Trial (or any other free plans)
Provisioning users and Accounts (aka Tenant) into the system
Allowing newly signed-up users to join existing Tenants, if any.
Sending Welcome email notifications
And much more…
② ANALYZING who the users are And what they do with your products - requires significant investments in Product Analytics.
Product Management, UX, and Engineering teams have to collaborate across the board to design and optimize the user journey. This involves
Buy: Choosing & acquiring Product Analytics tooling
Instrument code for SaaS telemetry events (take 3-6 months),
Create PLG Analytics Dashboards and Customer Journeys
Includes Standard SaaS Analytics reports like Acquisition, Retention, Activation, etc.
Create custom reports for Feature Usage, Subscription Retention
Start Correlating with releases & business changes.
Attempt to integrate the analysis into Custom lifecycle marketing (feedback loop). E.g. When a user is stuck with setup, send an in-app message/email to figure out how to get unstuck.
Rinse and Repeat
③ DRIVING GROWTH, typically increasing engagement and monetization - requires process automation across Sales, Revenue, and CSM tooling
Because end-users are in control, they prefer to do things of their own will and time. Constantly nagging them to buy/upgrade has a higher chance of churn. Instead, figuring out when to talk to them, and “manage for success”, requires process automation and data-sharing across Sales, Revenue, and CSM teams.
Try: Figure out what features, length of trials, and use cases to drive Activation moments.
Engage: Get users to use and find enough value to solve their “jobs”
Buy: Provide in-app/self-serve ways to purchase the products. Transparent pricing and flexible (e.g. Monthly/Annual) plans, with clear articulation on what they get per plan, are reasonable expectations from modern users.
Upgrade: Providing clear quotas (product limits) and additional incentives (e.g. more solutions for JTBD, more features, more security, higher SLAs, etc)
Downgrade / Churn: Allowing users to do in-app downgrades/cancel plans, still providing enough incentives to continue to use the products.
CSM / Feedback: Collecting feedback (e.g. more convenience, more integrations, more value) within the product.
RevOps: Understand and experiment with pricing plans, value, and packaging features to drive growth - requires data across usage, subscription, and product feedback.
The struggle to build each of these areas is real. There are lot many point solutions out there.
However, the struggle to bring them all together takes $1-3M and 2+ years.
This is the driving force behind ThriveStack
- to simplify the Self-Serve process for those building SaaS solutions.