What's the difference between malleable and configurable software?
Configurable software is where you predict in advance all of the changes that your users may want to make to your software. You've almost certainly encountered this with something like a settings screen, or a theme picker. You can see this with products like Linear as well. Linear has the ability to turn features on and off, so you can say, I want this in my workspace, I don't want that.
Malleable software is where users can change things that you couldn't predict in advance. A good example would be something like Excel. Excel has the ability for specific power users to transform it into something which is almost unrecognisably Excel. You can turn Excel into a game if you want to. You can turn Excel into some sort of cityscape, or whatever. You can do a lot of things with Excel because it's extremely powerful, and if you are the right user, you can do very powerful things with it.
Now, I don't think the team at Microsoft predicted that people would be making Doom in Excel. They were just giving users the tools that they thought they would need to change the software in the way that would suit them the best.
So that's where malleable software and configurable software differ. And the type of malleable software that we promote is the type that uses AI to turn natural language into something more powerful.
Is it even necessary to move past configuration?
We have previously had this impression of software that the software needs to solve all of the user's problems in advance, and everything that it doesn't solve for, we put on the backlog or we promise it in the future. But generally, that recognises that the software we have is missing some capability that the user wants. Right? If you have a backlog, you're recognising that. So malleability is a way to close a lot of what that backlog is representing.
And Excel, sure, Excel got away with it. But to be fair, Excel only got away with it for very specific, highly technical users. Super users, pseudo-programmers in a lot of ways. So I would say Excel didn't really get away with it. 99.9% of Excel users are probably within the bounds of what Microsoft expected people would use it for. It's only this very specific cohort of people that have the ability to turn Excel into something greater than what it was planned for.
That is not something that needs to be only accessed by super users or pseudo-programmers anymore. Now all of your common, average users can take that gap that you recognise in your backlog, and they can make it real for themselves today.
What does a vendor lose when users build their own features?
I think that's a very reasonable fear.
If an end user has access to a set of tools, and they use those tools to create something dramatically different from what the product is intended to do, that may cause issues within the product, if the user is expecting the vendor to then support the features they've built.
This is why we say it's very important that users understand that when they build features inside malleable products, they are responsible for maintaining them. If I use Excel to make Doom, I don't expect Microsoft to come and fix my Doom if I find a bug. I'm on the hook for that. And that's also true for any users that create features inside these products.
So there's kind of two parts to this answer. The first is that you want users to do whatever they feel comfortable doing with your software, as long as you are not maintaining it.
The second side of it is that malleability is often used by sales, CS, product teams, people that are close to users but aren't the users themselves, to close those gaps. And there's a risk that those features are expected to be maintained. That's a fair assumption from a user's perspective.
So it's very important for B2B companies with malleable products to educate their user-facing teams on product strategy, aligning everybody so that they understand what the organisation's priorities are, what the ICP is, and what sorts of things we are willing to support and not support.
How do companies need to change if everyone is shipping features?
There are a number of pressures that all need to be balanced.
The first is that organisations need a reasonably high degree of product management capability. They either need to be resourced with product managers, or they need to have a good grounding of product management education, so that people inside the organisation understand why we have things like strategy, why we have priorities, why there are things we've decided not to put in the product, why we target these users and don't target those users.
If, for instance, you have a general inventory and supply management system and you're targeting the construction industry, you don't want your sales team going off and selling to supermarkets, because now suddenly you're competing in that industry. Even though technically your product can do it, strategically it's not a very good decision.
That's the first part of finding the line between what your product can do and the gaps you've closed.
But the other really important thing is visibility. You cannot make decisions around what you are going to support and what you're not going to support if you can't see what's already been built and is in your users' hands. That's why it's quite useful to have a product like Rough, which gives you visibility on the features that have been built by both your customers and your internal staff.
What is the actual dividing line between configuration and malleability?
I would say it's the number of permutations, and the way that you display those permutations.
If you break it down, most applications are just databases with a UI in front of them. Right? And the number of permutations you go through from the data layer all the way up to the UI layer is what makes software complex. With malleable software, we're basically giving users access to a lower level and letting them build things on top of it.
So the complexity comes from all the different permutations. Even if we just give users the ability to change the settings through a malleable interface, that's giving them different access to already available configuration. But that could still become malleable, because they might say, okay, the way I want to change settings is to tell the AI about my day using a voice interface and have it change the settings for me. Or I might want a three dimensional office environment where the settings are little widgets on the side of the wall.
Those are things the vendor cannot predict, even though the underlying functionality hasn't changed at all.
Where should a vendor start?
The easiest place to put any sort of malleability is usually dashboards. Users have different opinions on what they want to see on a dashboard, and nothing is more annoying than opening up a product and seeing stats you just don't care about, front and centre, because 80% of users seem to enjoy that stat being there. So dashboards are a great place to add malleability to your software.
Another place is import, export, or bulk edit. If you have a lot of data and users are often asking to export it in a certain format, or import data in a certain format and then change your software with it, these are all things that can be done very easily with malleable software.
Also, if you have a diverse range of users and there's tension where specific users have specific needs but you can't put those in the product because most people don't want them, that tension is sometimes solved very well through malleability.
And the same can be said if you have very large users. If you have big enterprise users with very specific requirements, and there's a lot of tension when you come into renewals, then malleability can add a little bit of extra gunpowder to your arsenal, so you can close a couple of feature gaps or solve a few problems that your competitors might not be able to.