Clouded Judgement 6.19.26 - Workflows are King
Every week I’ll provide updates on the latest trends in cloud software companies. Follow along to stay up to date!
Workflows are King
Workflows workflows workflows…I’ve probably written about this in the past (hard to keep track of everything I’ve written at this point, so I’m sure there will be some repetitive content!) but I wanted to circle back to it.
For SaaS companies, the conventional wisdom was that you developed a moat if you built a system of record - a platform that stored data. If you owned / controlled the data, you had a moat! Data has gravity. True, but that wasn’t the real moat. The real moat was the hundreds of workflows that grabbed data from that system of record and then got work done. Sometimes those workflows originated from the system of record platform itself. Sometimes the workflows originated elsewhere, and one stop of the workflow grabbed data from the system of record.
The real moat is owning the platform that the most workflows touched (and the platforms the most workflows touched was almost always the system of record). Swapping out the system of record was nearly impossible because it didn’t just mean porting the data to a new system of record, it meant rebuilding / verifying / testing / securing / etc ALL of the workflows. Many of these workflows were in the critical path or customer facing. The cost of going through this change management was nearly always greater than the value of swapping to a new system of record.
I think the same thing is repeating with AI, with a twist. In SaaS, the moat lived at the data layer. Workflows formed around to the system of record, and this is what made it so hard to rip out. With agents, we still have workflows, but those workflows start to become more dynamic vs static (for SaaS workflows). So now the moat / anchor moves up a layer. The moat isn’t a derivative of where the data sits (ie workflows touching data), it’s where the work gets orchestrated. This is similar to what I wrote about last week about the value of becoming the Clearinghouse.
So what would my take away be for founders? I think the instinct when you read this (the moat is now the orchestration) is to go try to build the orchestration layer from the start. I don’t think this should be the takeaway! At least that’s not how systems of record because what they did. Salesforce wasn’t the platform a thousand workflows touched from day 1. They started with something more narrow / niche, owned a single use case, got really good at that one thing, and then slowly expanded outward until more and more workflows were built around them.
I believe the agentic version will have the same playbook (albeit from a different starting point). Pick a single workflow (probably something that looks like it’s about to get commoditized), something that will become more important in the future but appears niche today (you want to be riding the right wave), and do this much better than anyone else. People will assume there’s no defensibility in this one niche (and why you’ll get underestimated).
Then use this one workflow / wedge as strategic real estate. Build other workflows around it that are adjacent. Then slowly build the orchestration layer around it all (the thing that manages, routes, and governs the agents doing the work). One of my favorite sayings is “startups aren’t static.” What you do today isn’t the only thing you’ll do. You’ll expand, go deeper in certain areas, etc. What’s important is that where you start is strategic real estate you can build around. Then you earn the right to “manage” (ie orchestrate) all of these workflows (ie agents)
The end state really is a new kind of system of record. In SaaS, the database held data and the moat formed around it in the form of workflows. In an agentic world, the “database” from the SaaS world becomes workflows. And the company that owns where those workflows get orchestrated I think will own the next moat.
Top 10 EV / NTM Revenue Multiples
Top 10 Weekly Share Price Movement
Update on Multiples
SaaS businesses are generally valued on a multiple of their revenue - in most cases the projected revenue for the next 12 months. Revenue multiples are a shorthand valuation framework. Given most software companies are not profitable, or not generating meaningful FCF, it’s the only metric to compare the entire industry against. Even a DCF is riddled with long term assumptions. The promise of SaaS is that growth in the early years leads to profits in the mature years. Multiples shown below are calculated by taking the Enterprise Value (market cap + debt - cash) / NTM revenue.
Overall Stats:
Overall Median: 2.9x
Top 5 Median: 26.4x
10Y: 4.5%
Bucketed by Growth. In the buckets below I consider high growth >22% projected NTM growth, mid growth 15%-22% and low growth <15%. I had to adjusted the cut off for “high growth.” If 22% feels a bit arbitrary, it’s because it is…I just picked a cutoff where there were ~10 companies that fit into the high growth bucket so the sample size was more statistically significant
High Growth Median: 16.8x
Mid Growth Median: 4.7x
Low Growth Median: 2.5x
EV / NTM Rev / NTM Growth
The below chart shows the EV / NTM revenue multiple divided by NTM consensus growth expectations. So a company trading at 20x NTM revenue that is projected to grow 100% would be trading at 0.2x. The goal of this graph is to show how relatively cheap / expensive each stock is relative to its growth expectations.
EV / NTM FCF
The line chart shows the median of all companies with a FCF multiple >0x and <100x. I created this subset to show companies where FCF is a relevant valuation metric.
Companies with negative NTM FCF are not listed on the chart
Scatter Plot of EV / NTM Rev Multiple vs NTM Rev Growth
How correlated is growth to valuation multiple?
Operating Metrics
Median NTM growth rate: 13%
Median LTM growth rate: 16%
Median Gross Margin: 76%
Median Operating Margin 2%
Median FCF Margin: 21%
Median Net Retention: 110%
Median CAC Payback: 44 months
Median S&M % Revenue: 34%
Median R&D % Revenue: 23%
Median G&A % Revenue: 13%
Comps Output
Rule of 40 shows rev growth + FCF margin (both LTM and NTM for growth + margins). FCF calculated as Cash Flow from Operations - Capital Expenditures
GM Adjusted Payback is calculated as: (Previous Q S&M) / (Net New ARR in Q x Gross Margin) x 12. It shows the number of months it takes for a SaaS business to pay back its fully burdened CAC on a gross profit basis. Most public companies don’t report net new ARR, so I’m taking an implied ARR metric (quarterly subscription revenue x 4). Net new ARR is simply the ARR of the current quarter, minus the ARR of the previous quarter. Companies that do not disclose subscription rev have been left out of the analysis and are listed as NA.
[table]
Sources used in this post include Bloomberg, Pitchbook and company filings
The information presented in this newsletter is the opinion of the author and does not necessarily reflect the view of any other person or entity, including Altimeter Capital Management, LP (”Altimeter”). The information provided is believed to be from reliable sources but no liability is accepted for any inaccuracies. This is for information purposes and should not be construed as an investment recommendation. Past performance is no guarantee of future performance. Altimeter is an investment adviser registered with the U.S. Securities and Exchange Commission. Registration does not imply a certain level of skill or training. Altimeter and its clients trade in public securities and have made and/or may make investments in or investment decisions relating to the companies referenced herein. The views expressed herein are those of the author and not of Altimeter or its clients, which reserve the right to make investment decisions or engage in trading activity that would be (or could be construed as) consistent and/or inconsistent with the views expressed herein.
This post and the information presented are intended for informational purposes only. The views expressed herein are the author’s alone and do not constitute an offer to sell, or a recommendation to purchase, or a solicitation of an offer to buy, any security, nor a recommendation for any investment product or service. While certain information contained herein has been obtained from sources believed to be reliable, neither the author nor any of his employers or their affiliates have independently verified this information, and its accuracy and completeness cannot be guaranteed. Accordingly, no representation or warranty, express or implied, is made as to, and no reliance should be placed on, the fairness, accuracy, timeliness or completeness of this information. The author and all employers and their affiliated persons assume no liability for this information and no obligation to update the information or analysis contained herein in the future.
Excellent post, as always!
Can you please edit to reattach the comps table? I find that super useful every week. Thank you!
Careful what you assume here. Each new abstraction layer tends to obliterate the old one. Mainframes allowed for multi-national companies and centralized the economy. Lots of paper pushers probably lost their jobs and we got things like airline reservation systems and the SWIFT money system. Minicomputers revolutionized manufacturing and further replaced paper processes with amazing automation. (I used some of the first ones, dating myself a bit. Revolutionary). PCs, with their cheap microprocessors and MSFT supplied abstraction layer obliterated minicomputers and the data entry workers supporting the minicomputers. The productivity gains from these automation levels kept interest rates down through the 1990s on wildly improved productivity. Then the internet obliterated newspapers and created social media. The point is that with new tools we can do new things, not old things faster or better. So it is traditional workflows, designed as they were to work around the limitations of the departmental technology used, that will probably go. Rather, AI is likely to make corporations more agile by including much more data, some now in people's heads, say from meetings and from news feeds, not just from transactions and certain contacts, to support faster and wiser behavior. My bet is workflows go from departmental (for departmental level automation) to end-to-end, so for instance, you don't get bounced around endlessly when trying to get support. That by definition is not a good workflow. Until then, we will make lots of errors but my bet is the change we face will change workflows as well as the choke-point abstraction layer we are all wondering about.