Why is build versus buy more important now?
Build versus buy has never been as important a topic as it is right now. The reason is that people feel like they can create for themselves a lot of the software that they previously paid for.
This has caused quite a large disruption in many different markets. Product companies have been selling well-written and well-created software to a lot of different people, but they're facing a large problem where some of those people only want a small subset or a very specific set of features from the product that they're paying for.
Those people feel a push to build the software that they want themselves, and for them it feels like it fits them better.
How is AI changing the build versus buy decision?
AI is the thing that's pushing this problem to the front of a lot of CEOs' and product managers' desks, because AI has given people the ability to create reasonably decent software to solve their own problems.
This is hitting that aforementioned company that has a subset of features. It also hits companies that have been making very well-made but very simple software and then profiting from it, because AI can make that simple software quite effectively now. So that's pushing this problem towards people's desks, and they're having to solve it.
But on the other side of it, malleable software, enabled by AI, has given us the ability to push back in some ways.
For the extremely simple case where somebody is churning because they have made the exact same product themselves, that is not helped by malleable software. In that case, the person is getting almost 100% of their requirements solved, but they're doing it with a much more cost-effective method.
Where malleable software comes in is the user who has a large piece of probably quite expensive, probably quite sophisticated software, but they're only using a small subset of the feature set, and they also have very specific needs.
Those people are faced with a really hard problem where the company that they're using is unlikely to prioritise their very specific needs because they don't apply to everybody directly. Yet they don't want to have to vibe-code their own replacement for the software.
So they'll either have to put immense pressure on their vendor to make sure that they get their feature at the top of the roadmap, or they have to invest in building the software themselves.
What malleable software lets them do is build that extra functionality into the app for them, so they can create this little bespoke add-on that will cover that feature gap. They can keep using the software without having to go and build it themselves.
The vendor wins because they don't churn a customer, and the customer wins because they don't have to make a highly sophisticated piece of software and maintain it themselves.
What problems are best solved with malleable software?
There are several signals.
The first one is the easiest one: bespoke features. These are features where a single customer has requested them. It might not be super impactful, and you definitely don't want to add it for every single customer. That's a great place for malleable software because if one person adds one feature to their one workspace, it doesn't matter. It's not going to affect any of your other people, and it's not going to add code that you have to maintain.
It really is irrelevant to the rest of your business, and if it keeps that user happy, then that's great.
That's really useful from the customer success side, from the sales side, and from the end-user side. That's where malleable software shines the brightest.
Secondary to that is experimental pieces of software. Let's say you have a product and you're a new product manager, and you believe that the product could really thrive if it went in quite a bold new direction, but you don't have the evidence to support that yet.
What you can do with malleable software is place a very low-cost bet and then roll it out to a few people and see if they use it.
What you're not doing is adding code to the codebase. You're not adding complexity, you're not needing to feature-flag things. You're adding something that only exists in a malleable software platform, and it's allowing you the ability to test out that extremely experimental feature without risking anything.
So those are two good examples of when malleable software either can be used because of signals you're seeing, or to get new signals that will be useful to you.
Which case feels most urgent: bespoke features or experimental directions?
Definitely the bespoke features.
Bespoke features are where a lot of lost deals happen and also where a lot of churn happens. It also gives us the ability to do things that we've never been able to do in software.
We've never been able to just delight customers with features that don't necessarily solve pain, but are interesting to them.
A good example would be if, for instance, you have a customer and their mascot is a cat, and you can put a dancing cat on their dashboard. It's a stupid feature. Nobody would ever want that feature. It would never get to the top of a backlog.
But for that one customer, for the one person that is using that, that person is delighted by that feature.
That's the type of thing you can do with malleable software, which you would never, ever do with traditional software.
How do you decide whether a bespoke feature is worth it if it doesn't scale?
It's not a question of scale. It can scale.
The only question of scale would be whether or not the customer is worth either their own time or the time of a CSM.
If, for instance, you're running a B2C app and your customers are worth something like a dollar a month to you, and each of your customers is building five dollars of features a month, that would be bad. You would lose money.
But for a B2B company, for the most part, it'll be the time of the CSM, the time of the AE, or the time of the end user themselves that they invest in building these things.
That's the only real thing that you need to invest in terms of scaling. Scaling isn't necessarily a big issue under a B2B model, because you already have customers and you already have customer success people and all that kind of stuff.
How does malleable software change the relationship between vendors and customers?
I think it brings you a lot closer to your customers because previously you needed to find some sort of abstraction of your customers' needs.
You needed to aggregate their needs and find something that would cover the majority of the problems that they were experiencing.
With malleable software, you're not doing that anymore. You're looking at capabilities. You're saying, are we giving our CSMs and users the capabilities to actually solve these problems?
The advantage to be had by understanding your user deeply, getting very close to them, and then solving the problem 100% rather than solving it just partially with some sort of aggregated feature is really significant.
What does an organisation need to be ready for malleable software?
I don't think it necessarily requires a shift tomorrow.
Technology like Rough is very easy to plug into existing software products. The real question is: is your organisation ready for something like this?
The way that we currently think about features is very much that the feature is the artifact at the end of a very long process, and that process involves lots of different departments.
With malleable software, we're thinking about the feature as more of a signal in and of itself, or a tool that somebody in a sales or CS team has in order to make customers happy.
The main question is: is your organisation positioned appropriately to use something like this technology, or is there going to be a lot more alignment-building and strategy-changing before you get there?