Stripe Can't Save You: Why the Real Bottleneck in Ai Is the Monetization Stack
Forget seats and tiers. AI monetization is probabilistic, real-time, and wildly underpriced. Our pricing systems didn’t get the memo.
Ai Agents: A great Product in search of a soul?
Every good product or shift has a soul.
A computer in every home.
The world's information at your fingertips.
Professional photography in the palm of your hand.
You know. That sort of grandiose thing.
So what about Ai? ‘PhD level intelligence’ ain’t the one. Nor is ‘automating mid level coding and operations jobs’.Not even a CFO is that excited by that.
Do they want it? Yes! But is it exciting? No!
So what gives with AI agents?
They’re a sensational idea.
But there is a lack of clarity around what they are.
Are they:
A technology, or
A business model, or
A monetization model
In many ways, SaaS had it easy.
Yes, with GTM costs at all time highs it doesn't seem that way now. But they did
They had a new technology. Cloud. A new business model. Software as a Service. And, most importantly, a new monetization model. Subscriptions. And on top of that, they had the wind behind them, with Cloud companies spending heavily to promote the new tech.
In terms of the consumer hierarchy or prefs...Cloud & SaaS meant:
Speed
Scalability
Cost Attribution
All of which was hard for a startup or challenger to turn down.
Ai agents are a little different. The speed is not there. The speed to adopt depends on legacy architecture...and hence is Slow! Slow. Slow.
The scalability is there. Maybe?
But the cost attribution is another nail in the coffin.
So what now?
Even the mighty Salesforce are struggling to shift Ai Agents.
And they've led the pack in the Ai Agent ambition tour.
They were the bright hope in this Ai Monetization Crisis.
But all is not lost.
Maybe it’s just the architecture? Maybe Ai Agents are a new Monetization Model?
Ai Agents: A New Monetization Model
It would be easy to talk endlessly about the need for a new tech stack for pricing and monetization. I wouldn’t be the first to speak about such a dream. And hopefully, I won’t be the last. But it wouldn’t do any good. Pricing isn’t that sexy, you see. And as for Monetization, no one knows whether it should be an ‘s’ or a ‘z’.
So instead, it’s perhaps more useful If I take you through a thinking model. Slowly, Page by page. This may help you come to the same conclusion. Or maybe a different conclusion. Or a better solution. Who knows. But here goes.
Note: I’m using the CRM vertical as an anchor to explain the monetization journey, but it could apply to any vertical or horizontal SaaS
SaaS: In The Beginning
We have always had client lists. On papyrus, on paper, on-prem, on stone (well, maybe that’s taking it a bit too far.
In the 1980s many digital companies sprang up to serve this transfer from paper to digital.
In the 1980s many digital companies sprang up to serve this transfer from paper to digital. Yeah, this is worth saying again.
They called it CRM. Customer Relationship Management
But while the early digital versions were pretty good at the CRM part of the equation.
They weren’t that easy to plug and play and this required a high level of implementation skill and resource to realise the value.
Makes me think of SAP and Oracle. Both Formula One style machines if implemented properly. But that’s the rub. Implementing them properly requires F1 engineering and management team. Without that, it’ll quickly go pear shaped
That opened up a gap in that Non-Techy clients might need, but not be able to implement, a CRM. A gap that a new entrant could fill.
And that was. You guessed it. Mr Benioff. And his brilliantly named ‘Salesforce’.
This, on the surface, looks like a delivery model shift. And it was. The move from heavy tech installed on your own servers, to software you could use from the cloud. The hardware was someone else’s problem. You only cared about the software. But the Cloud was so much more. Software as a Service. And as we know, any new service needs a price. And maybe even prompts a new way to re-configure Monetization.
But for now, we could keep it simple. I give Jack and Jane access to software that would have previously had to install themselves and they pay me a fee on the regular. we could call it a monthly license fee. Or better still, let’s call it a subscription as they subscribe to use the service on a monthly or annual basis. $20 or $30 per month should do it.
And you know what was even better. Well, with the ‘On-Prem’ i.e. the on your premises installed software there was a certain rigidity to the implementation. Remember the whole ‘Waterfall’ thing. New feature update weren’t that easy to pull off.
But with SaaS. That was a breeze. The software was updated centrally by the CRM SaaS company and you just got it. Just like that. Easy peasy lemon squeezy!
So, you could request new features that would enable your CRM to be better. And, you know what, the CRM company would listen. Their Product Manager may even put it onto their roadmap.
But you were not alone. Every client had ideas like yours. New features. New screens. New products. A bunch of new stuff. And, of course, the CRM company was more than happy to expand its product with all these great suggestions. Who wouldn’t be?This is free market research, baby! And it also allowed it to improve its product and maybe even do a cheeky one and increase its monthly prices.
Happy days. Right? Well, for some. Yes. Fully featured CRM software at my fingertips. Bring it on! But for others, the casual user, the small company, maybe even Jack and Jane, these added features led to confusion. Feature Fog. Overwhelm. I’m all out of choice confusion terms…but you get the picture.
Random behavioural science corner. The Choice Paradox study found that people buy more when there’s less choice. So six is preferable to twenty four kind of thing.
But the feature engine had started. And behind the wheel were keen as mustard product managers, edge marketers, and nice, but eager to please sales people. And what they all want. Say it with me. Features. More Features!
When the will of one, is obstructed by the will of another, what emerges is what no one willed.
Engels
So, here we are. A product with more features than you can swing stick at. Although many would like to try!
This put a strain on the users. In may ways, this seems like what they call a first world problem. The ‘if you were really hungry you’d eat what you’re given’ kind of argument. I suppose it does seem weird asking for less, rather than more features. But take the other side. The more features, the more thinking the user has to do. The more thinking, the less time the user has to realise value.
If we think about it from a combination perspective, no one uses all of a product suite. For instance, how many Excel functions in their library have you used? Ten? Twenty? Maybe a hundred. But certainly not one thousand or two thousand. For many of use, the extra n+1 is unnecessary. An unused feature. A bloat. Particularly if it slows cognition, runtime or consumes energy or local storage.
Let’s say your company buys a new six feature SaaS knowing full well that employees use a combination of four of these six. But, a different four per individual preference.A feature with six features that you use four would result in fifteen different combinations. Sounds reasonable.
But say the feature set now expands to thirty. Yes, thirty is on the low side. You’ve also expanded your team’s workflows, so you now use six features rather than the original four. The number of combinations of features now rises to five hundred and ninety three thousand, seven hundred and seventy five. Yes. 593,775. You see the problem. Feature bloat also leads to operational workflow management problems on the client side, as the increased features lead to a wide variation of use across similar, if not the same team’s use. You could call it ‘The Excel Effect’ Everybody’s using the same product, but in different ways. The same, but different.
Of course, you can just segment right? Yes. Splitting use by segment definitely helped. Both from a user focus perspective and a monetization perspective. The Good Better Best Model provided a great way to monetize all they way up the demand curve with prices gradients like 1X, 2X, 4X or 1X, 3X, 9X or even the legendary 1X, 12X, 64X. But it was a temporary solution to a long term problem.
But feature creep and ‘segment packing’ are hard to keep at bay especially when you’ve built a feature machine in product, marketing and sales.
Feature parity arrived, sooner than anyone had imagined. The feature ‘Cold War’ was here, and everybody settled into a war of attrition. Growth stagnated. Marketing budgets spiralled. Ain’t nothing going on but the rent as Gwen Guthrie sang.
But then along came Ai. Well, that was always here. But LLM’s Large Language Models packaged Ai neatly into an accessible and usable product. A new dawn? Maybe?
But you know what happened next? You can guess. More features. Ai features, mind. But more features nonetheless. And more segments. Good Better Best. Ai! Ai was poured everywhere. Like it was ketchup. And everything tastes better with ketchup.
Ai is maybe a new platform. A new business model. A new product. A new Monetization model. Maybe all of the above. Who knows? But for now, it’s just more features. In a CRM world in this case, which already has too many features.
And, just like Excel, although the Ai tools are Ai great, it needs master user to get max value realisation out of them. Kinda like the F1 car. No ordinary mechanic. No thank you! And what of the cost?
Unlike, run of the mill software, this Ai thing is expensive. With compute no longer being negligible, someone’s gotta pay! For VC backed startups, all is good, they can burn, baby burn and giveth consumer surplus away. But for listed SaaS, they can’t! They have to charge. But charge what? No one knows what inference costs? Or at least what it costs with a product that requires customers to experiment to get to their value realisation point. Remember. The 1st job of a customer is to realise value. But the 1st job of their CFO is to predict and budget for expected costs.
Maybe if the customer could identify the jobs that they use the software for, then we could be sure of what to add Ai sprinkles to in order to fulfil these jobs. And, maybe we could also segment by jobs?
But no one likes the ‘Job To Be Done’ in Tech, right? Wasn’t that de-bunked by a bunch of tech Bros a whiles back? That’s 1990s theory. What’s it gotta do with 2025 Ai?
So what is Jobs To Be Done?
The theory emphasizes understanding the "job" a customer is trying to get done, beyond just the product's functionality. This includes functional, emotional, and social aspects of the job [Google Ai]
Could those thirty or so features we mentioned earlier be bundled into many jobs. No, not the five hundred thousand from before, but say, five hundred?
Sounds good.
What if configuring jobs made it easier for customers to get to value realisation?
What if those same jobs could be marketed to other customers?
What if those specific jobs could be sold by Sales people much easier?
Let’s say it again, the 1st job of a user is? The 1st job of their CFO is?
Surely, features bundled into jobs would help all of these participants in your eco-system?
Is it that simple? No. But it is possible. Here’s how.
Imagine rotating features by ninety degrees.
Features are listed in the GBB Good Better Best columns. To continue our example, the 6 selected features could be picked from this column of 30 features and arranged into 1 job. Then another six into another job. Then another six into another job. And so on.
But it’s not only six. It can be three, or two, or eight of nine features made into a job. Ten even. What’s important is that it’s the jobs that are valuable, not the features.
It would look something like this:
To add more colour, you could:
Bundle Features into Tasks.
Then Bundle Tasks into Jobs
For instance, in the CRM example, a task could be to update the client’s record with a call meeting transcript. Whereas the overall job could be to keep client’s records updated with all activity. Which may include tasks of calls, in person meetings, zooms, conferences etc.
So Tasks are a unique set of features. Call it a bundle of features. And Jobs are a unique set of tasks. Call it a bundle os tasks.
And now, we can call each Job a JTBD. But that’s boring and lacks punch. Ok, so why don’t we call each Job and Agent? Agents are all the rage nowadays.
Yes, we’ll call them Ai Agents!
So the CRM looks like this now.
Agent Job 1.
Agent Job 2.
Agent Job 3.
Agent Job 4.
Agent Job 5.
Agent Job 6.
Agent Job 7.
Agent Job 8.
Agent Job N etc.
And Marketing can now give these Agents specific names like ‘Update Client Conversation Records’ or something much better than that. Either way, it can be named and marketed and sold. And would add to the user cognition. And help the cold start customer problem. And And And.
So what about the Pricing. Well, that can be done per Agent. Per use, Per month, whatever your fancy. The most important thing is that the Agent enables the whole eco system to monitor and manage its use and its unit economics.
And economics are what CFOs are here for. Unit economics allow CFOs and their FP&A to compare Agents to Onshore, Nearshore,
Offshore and maybe even JerseyShore, only joking!
CFOs love Agents that can help with budget and forecast attribution to the relevant cost centres. Especially those that can be subject to rigorous cost comparisons with us humans. Agents can turn a CF NO into a CF Yes when it comes to Ai adoption and approval.
And better still. It will allow you to itemise cost bills per Agent. Nothing us Accountants love more than a forecast to actual reconciliation Gets me all excited just thinking about it.
And it’s worth noting. None of this was possible before with a lateral product feature set.
The Customer dashboard would resemble that of AWS billing console…but better, of course! Agents cost by time, by date, by total cost etc
With notifications and all the lovely budget tools we get from our friendly cloud providers, but tailored for agents.
Of course, this would not need to be built from scratch as there are a raft of tech startups could provide this.
But that’s complicated I hear you ask. And won’t it require a whole new Monetization stack. No to the first question. It’s not that complicated. And yes to the second question. It will need a new Monetization stack.
Let’s go through each layer using some examples of tech already out there in the market. Note: this is not a prescriptive list of software vendors, just indicative. And no, I’m not currently sponsored by any of these vendors! Did I say, YET!
For ease, let’s call it a Value Capture Monetization System.
Value Capture Monetization System Architecture! 🚀
The value ledger. From tracking customers to experimenting with value delivery and capture.
Here’s how each part fits in and some software tools [non-prescriptive] that could make it work:
1️⃣ CRM (Customer Relationship Management):
👉 Salesforce
What It Does: Keeps track of customers and helps manage all interactions.
Why It’s Important: We need a clear record of who our customers are and what they need, so we can create personalized offers and better understand how much value we’re delivering to them.
2️⃣ Value Segmentation Layer
👉 Amplitude
What It Does: Groups customers into segments based on the value they’re likely to get from the product.
Why It’s Important: By segmenting customers, we can tailor products and pricing to match different needs, which means more precise and fair monetization.
3️⃣ Value Experience Management Layer
👉 Qualtrics XM
What It Does: Measures and manages customer satisfaction and experience.
Why It’s Important: Ensuring customers actually experience the promised value keeps them satisfied and loyal. This layer makes sure that what we offer matches what they expect.
4️⃣ Value Capture Feature Packaging
What It Does: Breaks down features and sets up options for how we can charge (like by feature, usage, or entitlement).
Why It’s Important: This layer lets us “turn on or off” different features and adjust pricing models so we’re capturing value in ways that make sense for both the business and the customer.
5️⃣ Value Capture Calculation Engine
👉 Custom Pricing Tool
What It Does: Calculates exact pricing for each customer based on their usage, chosen packages, or other metrics.
Why It’s Important: Accurate calculations mean we’re charging customers the right amount for the value they get, not underpricing or overcharging.
6️⃣ Value Experimentation Layer
👉 Statsig
What It Does: Tests different pricing and monetization strategies to see what works best for revenue growth.
Why It’s Important: Experimenting with different approaches helps us learn what works, what doesn’t, and ultimately optimize pricing for growth.
7️⃣ Payment Processing
👉 Stripe
What It Does: Processes payments from customers, making sure transactions are smooth and secure.
Why It’s Important: Reliable payments keep everything moving and ensure customers have a seamless experience when they pay for their products.
That’s it! Your very own Value Capture Monetization System
Value Capture Monetization System
In overall terms we need to engineer the ability to:
To Price Per Job
To Bundle Features Into Tasks
To Bundle tasks Into Jobs
To Have Separate Entitlement Flags
To Meter By A Number Of Different Ways Like Usage, Work, Seat, Time, Outcome…
To Bundle Jobs Into Packages To Help GTM
Obtain User Experience Stats To Help Price Experiments
Calculate Value Capture Metrics For CFO & CPO
There you have it. We may not have gotten much value from Ai Agents as yet. But it’s coming. And luckily, for the Monetization Product Manager, this is your chance to go to the ball and show your framework, product, feature, customer research and packaging skills.
Ps. Happy to chat. DM me on Linkedin or chat in the Substack comments.