Is AI going to eat software?
Let's talk about the recent Klarna story.
Klarna recently announced that they are ditching Salesforce (and soon Workday as well) and replacing them with internally-built tools thanks to “a combination of AI, standardization, and simplification”
I really want to buy into the claims that this is a preview of things to come: No more crappy enterprise software nobody likes to use, which requires $millions paid to consultants to configure the software for you 🦄 And with the AI-fication of development, you can have non-FAANG tech talent work together with business users to build the tools.
BUT I am sceptical about this, on a few levels. Let's 'delve'1 in…
First source of scepticism: This might be more PR stunt than real story
Remember, Klarna is gunning for an IPO. This isn't the first story about how they're using AI to achieve impressive results in recent months - in Q1, they announced that they're using AI to automate 700 customer service jobs. The techno-optimist in me says they're just making good use of generative AI, but the sceptic in me is thinking that they're maybe just trying to create an impression that they’re a solid buy ("an AI-first company!"), regardless of what their financial statements might suggest come IPO time.
Klarna is far from alone here. Companies of all shapes and sizes are rushing to push out examples of using Generative AI, even when the business case is weak (spending more on Open AI API credits, cloud compute, or data scientist wages than what they're saving), or when the technical implementation is poor and results in hilarious and/or costly repercussions.
Objection #2: Can companies really DIY the tools they need?
The argument here is the same as with no-code tools pushing development from specialised, expensive software teams to the hands of business users.
The no- (or low-)code argument goes: Business users understand their problems best, they're experts in their domain. When you need to bring in a software team, you need to spend a lot of time translating requirements, risk misunderstandings, and incur huge costs to build stuff. With a no-code tool like Notion or Airtable, you get the drag-and-drop beauty of Excel, and couple it with the power of databases and other software components that lets you build simple-yet-powerful business applications like CRMs, project management trackers, content calendars, budget planners, and product roadmaps.
A lot of teams are very happy users of Notion, Airtable, Coda. They tend to be in smaller organisations, have simpler requirements, and start from a relatively greenfield setup.
Enterprise SaaS can be very complicated. Granted, a lot of that complexity is borne out of a need to serve many different customers, but a lot of it is also because, well, it's complicated stuff. Lots of workflows, governance, features, compliance reqs, localisation... There's a reason why most SaaS companies add headcount besides needing more folks to grow even further.
Looking at the Klarna story, they called out that their replacement of Salesforce and Workday wasn't just about using AI - it was also about standardisation and simplification. So it makes sense that maybe a bloated tool wasn't needed after they simplified their workflows and SOPs. The question is, will that simplification last? Kudos to Klarna if so. But usually complexity in orgs follows the second law of thermodynamics, and increases over time.
If Klarna's requirements for complexity in their CRM or HCM grow over time, will the company reach the tipping point where it makes economic sense to go back to Salesforce or Workday? And even if that happens, will economic rationalism prevail, or will they instead bow to the sunk cost fallacy and double down by investing more on enhancing their software than it would've cost to re-buy instead?
Objection #3: Just because you can doesn't mean you should
Suppose the economic case of Klarna, or any Klarna, ditching their costly, bloated, and unfit-for-purpose SaaS tool is overwhelming. They can save money and
Well, no. Investment decisions are not made on the basis of "do the benefits outweight the costs?", they are made by evaluating opportunity cost. Take this simple case as an example - suppose I have $100, and want to decide where to invest it.
Option 1: I invest $100 and get back $150
Option 2: I invest $100 and get back $500
Option 3: I invest $100 and get back $50
Option 4: I do not invest my $100 and keep $100
Looking at the above, you'd be silly not to take option 2, right? Assuming I've not hidden the details about probability of success and risk and all that.
But why? Option 1 is also net positive! Benefits > costs! But obviously the net gan is much less, $50 vs $400.
Okay, back to the less simplified point: Businesses generally succeed by honing in on their competitive advantages and investing their time and effort and extracting value out of them. It's why most businesses nowadays use AWS, GCP, or Azure instead of hosting their software in proprietary datacentres and server farms: Even if it costs a bit more to run your workloads in AWS than your own servers, you don't need to run a whole IT department that has to take care of that stuff for you, buying hardware, maintaining it, and then being in trouble if you've under- or over-invested. It's why I'm using Substack to host this blog and send out copies via email, rather than build my own website to do so - I want to use my time to write articles, not debug the stupid coding errors I'm inevitably bound to make.
So what does this mean in the context of Klarna? Well, think about it: Who's building this in-house software? It'll be a mix of Klarna's technical folks and the business users who'll be using it. Is that the best use of their time? Shouldn't they be shipping features, running campaigns, keeping customers happy? Why are they spending time on this instead? Will they also need to keep spending time away from their day job to maintain the software?
Maybe it's some other tech team (not Klarna's A-Team) building this. Maybe it's outsourced. But it still has to be managed. Which executive now has to dilute their focus because in-house software product management has become part of their remit?
All that said, there comes a point where the best use of a company's resources is to in-house a capability. When I was at PepsiCo, I was scaling an internal product that was replacing what was previously being done by an agency. The agency was changing tons for the work, so we only used them for large countries, and they only did the work once every 1-3 years, so the insights weren't fresh.
Another example of in-housing that defies conventional wisdom is 37Signals' migration away from the cloud, who are looking to save ~$7m over the next five years (for context, their cloud spend was $3.2m per year, so this is a big saving). Does that mean everyone should start buying server racks again? Almost certainly not. But it made sense for 37Signals, who have a relatively stable userbase, strong technical expertise, minimal need for higher-level cloud services, and a clear economic case for the transition.
Going back to the question "will AI eat software?", when it comes to this objection I think what we're looking at is a shift in the threshold / tipping point where a previously unwise decision to DIY becomes wise. AI lowers the barriers to software development, for example by making a small team of developers more productive, or making it easier to disentangle complex business logic. It's a bit like how it's easier to build software today using Python and its abundance of packages compared to 40 years ago when COBOL was the backbone of enterprise applications.
Objection #4: This is AI-washing
It's a lot more palatable to say "we are cutting jobs and/or budgets because AI is making us more productive" than, say, because you realised you over-hired, or because of inflation remaining high, or because you think there is a recession looming.
Another (of many) example: UPS had its largest layoff in 116 years last February, with the CEO alluding to their AI work in the same announcement (but later a UPS spokesperson clarified that AI isn't replacing jobs), rather than letting the attention go towards the drop in parcel volumes or their rise in labour costs following their agreement with their unionised workforce 6 months earlier (NY Times).
So, is AI going to eat software?
Look, there will be some 'eating' for sure. For use cases where the business case almost made sense before LLMs, the answer is most likely now DIY > buy. But I don't think most 'buy' decisions were just one step away from being 'build' decisions.
What I do see as much more likely is for software companies that successfully pivot (or start as greenfield developments) with AI at their core to make steady advances against incumbents. In some cases, that'll be companies competing with other software businesses, like Intercom's embedded AI chatbots. In other cases, it'll be more about AI automating work that was previously seen as strictly a human service offering, like paralegal work being done by the specialised LLM foundation models of Harvey AI.
Could a law firm build their own paralegal agents using Open AI's API + software engineering teams + specialists collating legal knowledge? Yeah, probably. Would it be cheaper, faster, and more reliable than to use Harvey? Not in the short term, that's for sure. And probably not longer-term unless if you're one of the largest players in the market.
Could an ecommerce business built its own Intercom-style chatbot? Maybe if they're quite large, but even then - what strategic priorities will you need to drop or dilute in order to save a 6 figure sum? And then you'll have built something that's not going to evolve over time or get fixed when it breaks, unless if you decide to make another sacrifice and once again deprioritise your competitive advantage.
Self-sufficiency sounds like a nice idea, but it's not generally what's most profitable. Apple, the world's largest company by capitalisation, outsources its manufacturing. Nvidia doesn't build its chips either - they do the design, and TSMC manufactures them. Shopify provides the online storefront, but doesn't handle logistics or fulfilment. Netflix uses AWS instead of running their own infrastructure. The list goes on.
AI is transforming the way we build software, which will of course impact the SaaS landscape. But it won’t happen overnight, and not all attempts to ditch SaaS will be well-thought out (much like all decisions in large organisations where the principal-agent problem runs amok)
In other news
Book recommendation: I've been reading David Pereira's excellent book, Untrapping Product Teams. Really enjoying it - will be sharing my notes and highlights in the coming weeks.
Barcelona meetup: Last week, we held the first Barcelona Data & AI product management meetup! If you're in Barcelona, then (a) sign up to join the next meetup here, and (b) let's meet for coffee!
London meetup: Next week, I'll be in London for the BigDataLDN conference, as well as our next London Data & AI product management meetup
Data PM in Action podcast: We recorded some excellent episodes earlier this summer that I can’t wait to see published in the coming weeks. If you’re a Data PM and want to share your story and lessons learned, drop me a message.
DPM course: I'm putting the finishing touches on my first course! If that sounds interesting to you, I'd love to get your feedback on what you'd like to see included or not included before I launch later this month!
Did you know that ‘delve’ is one of the tells for spotting ChatGPT-generated content? https://pshapira.net/2024/03/31/delving-into-delve/