The coming PLG to SLG apocalypse(withsahel.com)
withsahel.com
The coming PLG to SLG apocalypse
https://www.withsahel.com/blog/plg-to-enterprise-timeline-compression
13 comments
Since I looked it up:
Product-Led Growth (PLG)
Sales-Led Growth (SLG)
Product-Led Growth (PLG)
Sales-Led Growth (SLG)
[deleted]
I didn't realize how much I appreciated writing having a distinct voice until LLMs made everyone sound the same. This strikes me as extremely LLMy:
> SaaS era: ~decade to go upmarket. Cloud era: ~5 years. AI era: <2 years. The gap between 'developers love this' and 'enterprises are asking for SOC 2' has never been shorter.
No judgement if you want to write your articles with LLMs or whatnot, you do you, I've just discovered that their default style grates a bit. It's like when Bootstrap came out, initially it looked amazing but very quickly it became the "default site" look.
> SaaS era: ~decade to go upmarket. Cloud era: ~5 years. AI era: <2 years. The gap between 'developers love this' and 'enterprises are asking for SOC 2' has never been shorter.
No judgement if you want to write your articles with LLMs or whatnot, you do you, I've just discovered that their default style grates a bit. It's like when Bootstrap came out, initially it looked amazing but very quickly it became the "default site" look.
PLG only worked when the product could sell itself to a team without procurement getting involved. That window is closing fast and everyone pretending otherwise is about to have a bad year.
Why is the window closing though? Because the prices went up? Or companies have to demonstrate belt-tightening? Or the AI mandate has teams building their own saas?
There's several aspects. For one, I don't see teams building their own SaaS even with AI. Companies buy rather than build to avoid significant operational and maintenance burdens as well as transfer risk and liability to a third party. AI does not change that calculus.
What AI instead is enabling a shift from Software as a Service to Service as a Software. In other words: SaaS is dead, long live SaaS. Most vendors in SaaS started because software is high margin and has limited scaling costs. But as they mature, they find clients also want guidance, professional services, and clear outcomes. This is part of the rise of the Forward Deployed Engineer (FDE) as a formal role. So it's not enough to sell the software, you also now to have sell how to use the software and what transformations are possible using the software. Essentially you can sell software to an individual but you sell transformations ("value alignment") to teams, divisions, orgs.
Another is that inference will become more expensive rather than cheaper over time. The capex spend on data centers has to be paid back by someone. This is the standard Silicon Valley playbook. Start cheap, gain marketshare, operate as a cartel, and then massively hike prices (i.e Uber, Airbnb...). So vendors (even if they operate with value-based pricing) still have to protect their inference costs will see more value from going upmarket early with larger contract deal sizes
TL;DR
Companies will still buy SaaS but a new variant -> services and outcomes rather than purely software. This coupled with increasing inference costs means value alignment will more likely require a negotiated conversation than a 1-click purchase
What AI instead is enabling a shift from Software as a Service to Service as a Software. In other words: SaaS is dead, long live SaaS. Most vendors in SaaS started because software is high margin and has limited scaling costs. But as they mature, they find clients also want guidance, professional services, and clear outcomes. This is part of the rise of the Forward Deployed Engineer (FDE) as a formal role. So it's not enough to sell the software, you also now to have sell how to use the software and what transformations are possible using the software. Essentially you can sell software to an individual but you sell transformations ("value alignment") to teams, divisions, orgs.
Another is that inference will become more expensive rather than cheaper over time. The capex spend on data centers has to be paid back by someone. This is the standard Silicon Valley playbook. Start cheap, gain marketshare, operate as a cartel, and then massively hike prices (i.e Uber, Airbnb...). So vendors (even if they operate with value-based pricing) still have to protect their inference costs will see more value from going upmarket early with larger contract deal sizes
TL;DR
Companies will still buy SaaS but a new variant -> services and outcomes rather than purely software. This coupled with increasing inference costs means value alignment will more likely require a negotiated conversation than a 1-click purchase
Thank you for taking the time. Your dot-connection ability is well honed.
This is particular apt for me as I switch from employment from product consumer tech to a smaller-scale sales-led company.
What's your take on the forward-deployed engineer setup in the mind's of the startup as a long-term, viable/lucrative model? I've always heard the warning for tech startups to avoid the traps of becoming a consultancy.
This is particular apt for me as I switch from employment from product consumer tech to a smaller-scale sales-led company.
What's your take on the forward-deployed engineer setup in the mind's of the startup as a long-term, viable/lucrative model? I've always heard the warning for tech startups to avoid the traps of becoming a consultancy.
That warning is still valid and prudent. Consultancies are highly customized one-time engagements that do not easily scale. Startups prefer to have long-term relationships built on useful software.
The difference of customization vs. implementation which is where the role of the FDE shines. A consultancy builds something specific for a customer whereas a startup builds general purpose software. The FDE can then act as a force multiplier in educating the customer on how to use the product to its full potential.
Essentially as AI is making software more commoditized (i.e, there's a billion notetaking apps for example), the ability to sell a solution and outcome that solves individual customer pain points while still supporting a unified product experience serves as a differentiator moat. If every platform in the market offers the same features, you'll go with the person that offers the best hightouch sales experience. This is why over time as startups scales, opex switches from eng to sales and marketing.
The difference of customization vs. implementation which is where the role of the FDE shines. A consultancy builds something specific for a customer whereas a startup builds general purpose software. The FDE can then act as a force multiplier in educating the customer on how to use the product to its full potential.
Essentially as AI is making software more commoditized (i.e, there's a billion notetaking apps for example), the ability to sell a solution and outcome that solves individual customer pain points while still supporting a unified product experience serves as a differentiator moat. If every platform in the market offers the same features, you'll go with the person that offers the best hightouch sales experience. This is why over time as startups scales, opex switches from eng to sales and marketing.
I agree with the headline, but find it ironic that there's no self-serve option
There's no irony there. The friction is actually quite intentional.
Enabling the capacity of unified selling motions early on in a company's lifecycle is not something that one can just sample or "try". It's a commitment that executive leaders and champions have to take seriously. Folks might see the pain point but only understand the tip of the iceberg but having a conversation and paid pilot surfaces key structural issues. This leads to stronger outcomes rather than trusting that companies know exactly what to do and can self-serve those transformations themselves.
So you can say in our scenario, the headline is in fact too true and the timeline collapsed to nonexistent for us, haha.
Enabling the capacity of unified selling motions early on in a company's lifecycle is not something that one can just sample or "try". It's a commitment that executive leaders and champions have to take seriously. Folks might see the pain point but only understand the tip of the iceberg but having a conversation and paid pilot surfaces key structural issues. This leads to stronger outcomes rather than trusting that companies know exactly what to do and can self-serve those transformations themselves.
So you can say in our scenario, the headline is in fact too true and the timeline collapsed to nonexistent for us, haha.
PLG. Any article I have to search for an acronym and don’t find it - nope.
Hard to tell if this is so hard to read because it is LLM generated, or because its is hollow "thought leadership" with no insight.
Unsure if there is no astroturfing rule for HN, but this is pretty blatant.
Unsure if there is no astroturfing rule for HN, but this is pretty blatant.
An enterprise customer will simply offer better margins compared to a self-serve one. So companies are recognizing PLG motion isn't a persistent revenue generating motion. Instead it exists more so as a product discovery and experimentation capacity with the aim to ramp you quickly towards enterprise negotiated deals.
The difficulty with this is simply unified revenue operations across blended PLG/SLG motions is complex to achieve if you did not build the commercial foundations early. The culprit varies:
1. Massive dearth of elite, world-class monetization engineers who remain in billing for the entirety of their careers; few engs stay in the billing space by choice
2. Starting with Stripe Billing (plans and subscriptions do not scale): in billing, exceptions are the rule not the exception
3. Commercial governance, command and control tooling for the fragmented revenue stack is nonexistent (it is not-uncommon to be using 8-9 platforms for your end-to-end catalog/pricing to contracting to metering to invoicing to collection to revenue recognition lifecycle)
Agents won't serve the Frankenstein mess. It is much better to have a single source of truth (i.e system of record) of commercial terms, guardrails, policies, workflows for agents to operate upon than trying to use agents as a drop in for the manual glue work monetization, billing and ops teams currently do.
I've seen this in my career at companies like Segment, Twilio, and Orb. Happy to chat more and learn about how your companies are dealing with supporting both self-serve and enterprise customers simultaneously. I don't believe any one does this superbly well!