B2B enterprise is the mother of all bloated software.
When Salesforce first launched, it had the promise of a new dawn. A new CRM, ERP, B2B software, whatever you want to call it, which broke the trend of the dull and grey solutions from the 1900s.
If you look at Salesforce today, the image of an incredible new dawn is not exactly replicated in their product.
Salesforce fell into the same trap that it’s old school competitors had faced. Bloat.
There is a reason why Salesforce is the way it is today. There is a reason why many enterprise-grade SaaS platforms are just as bloated as Salesforce is.
The diagram above visualizes the natural flow of bloat.
The reason this cycle repeats 1000 times with 1000 potential features (some of which become real), is due to the fundamental reason why these Products are so interesting:
There is no end to the problems that need to be solved.
And due to that, there might be no end to the amount of functionality needed to solve it.
That’s a dangerous path to go down.
Now this is the way it was.
Enterprise-grade software has always needed to serve a very complex & broad set of needs:
- Multiple user types
- Multiple industries
- Varying company sizes
- Varying security needs
- And much more…
They also needed to justify their subscription fees and annual price hikes with something.
Features are an easy answer to that increased cost.
Eventually, all these features hamper the breath of fresh air the software initially was, and instead, it becomes the very thing it replaced. A shitty hard-to-use, bloated ERP.
The problem in the past has been bloat.
Now bloat may not be a bad thing strategically for the business.
Bloated & feature-heavy software might mean you need more training for your users due to its complexity. This could allow the software company to:
- Bring in specialist training and charge more fees (Onboarding Consultants)
- Create certifications for the product, creating an new economy (Agile methodology, scrum masters)
- Capture almost any customer type, as it probably has the functionality to serve their needs in some way (Salesforce)
Certain types of bloat are worse than others.
Ad-hoc or low-volume usage features are disproportionately more harmful when building.
Less users and less value are obtained from a certain amount of development & design time.
The less repetitive a feature, the less benefit from a product perspective.
More repetitive features make a platform more sticky for users. More sticky = harder to churn. Harder to churn means more repeatable business.
Ad-hoc features for users need to be easily accessed but are typically the opposite, and this has some massive costs.
- Usability cost — now a user has to practice more ‘recall’ to find what they want, as there are more options to choose from
- Training cost — the user has to learn multiple different patterns & routes, in resolving their request
- Technical cost — more has to be maintained, and more bugs can appear
- Design cost — as the experience bloats, the perception, brand and other visual elements can be diminished to the user or a prospect
These features cause the most bloat, and the most harm.
But bloat was also unavoidable with the technology we had.
There was no other way to serve all these user needs and requirements, without building more features, no matter how non-repetitive they were.
Until now.
AI here can genuinely solve the bloat problem for Enterprise SaaS.
The bloat of ad-hoc use features can be cured.
We have this ad-hoc data problem at autone. Retail users need to find ad-hoc data answers every single day. A CEO might ask them to check something urgently, a supplier might have had a change in circumstance, or an important buyer might be coming into a boutique store.
When the data needs are not repeatable and have their nuances, building for all these cases would quickly become a nightmare for the UX of the platform.
We would get into the same feature bloat situation as Salesforce and old-school ERPs.
So we need to try a different approach.
We need to reframe the problem.
Ultimately a common thread across these ad-hoc data requests is the request part.
Users are answering a question, and they’re usually answering it so they can tell someone else that answer.
So why not just let them directly ask the question? Instead of fiddling around with menus, input boxes, chart types and so on.
By creating one mechanism here to resolve ad-hoc requests, you reduce the need for someone to search & find a feature, (and for the tech team to design & build it out). You create a scalable solution that can solve many of the same types of requests, now and in the future.
This single mechanism acts as a bucket for lots of requests, spewing out what they need, before they go off into where they need to go (usually to tell someone else what they learnt).
This conversational AI experience drastically reduces the functionality that would have been required in the past.
Google search is a good analogy to use here.
That single bar is the genesis for so much, and then when the user gets their result, they’re off to somewhere else. Google facilitates the user experience like few other products.
LLMs today can do the same, for enterprise software. Especially in data-heavy scenarios where there is lots of querying.
With one question, you can get the answer you need.
And because we have the context behind your questions, we can even suggest relevant options.
Here for the example of a poorly performing department in New York, users can be suggested actions to increase sales, freeing up space for better selling items, and ultimately improving the bottom line of the business, which is exactly what autone was designed for.
No more diving into 15 menus, no more creating 15 different views. No more configuring 4 dashboards and comparing them to 10 other data points.
You can simply ask, understand and act.
Now you can create one interface, with potentially infinite outputs in a highly contained environment.
The exact opposite of bloat.
It's simple for usability and relies on a new type of user experience. One where users work side by side with AI and need to trust and understand how solutions are derived. But that’s for another post.
This conversational experience takes UX into a new era. One where the user experience requires a deep understanding of outcomes, and UI plays a very different role from what it does today.
I’m excited for that future.
Sakky B
Product Design @ autone
