Why does the feature request backlog become such a problem for companies selling to enterprise customers?
Nothing is actually going wrong when enterprise companies are getting feature requests piling up on their backlog. What is going on there is that enterprise companies have a huge amount of power when it comes to backlog influence. And the previous model has always been to try to juggle a few different companies with a few different promises for features. Then you try to get the best features you can with your engineering and product budget over your quarters or your year, and keep the deals in place.
So that model has not changed for most companies out there, even with the dawn of AI writing code. What AI does is it lets you write this code very quickly. And that means the difference between SaaS companies comes down faster. But what it doesn't solve is the complexity of your product. Just because it's fast, it doesn't mean it's sensible to build for every single enterprise customer. So customer A requests a feature, and putting that feature in front of customer B, customer B will say, I don't want this, I'm not paying for this, this is making my product more complicated.
And now we have this other problem, which is that the number of feature releases becomes overwhelming. Users are saying, I don't like these constant updates I don't want, because there's a modal every time I open my software, because you released some other feature to some other customer that's not me.
So that's the current model being used at most companies today. What we offer as an alternative is using a malleable software platform like Rough, and letting enterprise users either build some of these feature requests themselves, or use your CS and sales teams to build feature requests pre-sales, so that the deal can go smoothly and a customer joins with all of the features that they need in place from day one.
What's the cost to writing the features into code?
There's two major problems with just writing code for every feature request. The first is that it does introduce complexity in your product from a technical perspective. Having lots of intermingling systems does introduce problems, even with AI. AI does not let you take away the maintenance burden of having a huge piece of software that you have to figure out. And so what we're doing right now is we're getting to that end state quicker. We're getting to the state where we have a massive piece of software that's very difficult to maintain, faster.
The other side of this is that having lots and lots of features in your product drives away new users, because the majority of those features they're looking at, they have no need for. So when you build specific features for specific people, you don't have a need for every user to use all those features. And what it does is it causes difficulty in the sales process, as users feel like they should move towards products that are better suited for them. Or it produces problems in your retention, as users, when they go to renew, are looking at the product they signed up for a year ago, and it's a completely different product. And now it feels like it doesn't fit them as well as it once did.
Why not use a no-code builder?
There's a few different ways that it's different. The first is that no-code and low-code builders still require a certain level of competency. And we can see this by just who uses low or no-code builders. They're not normally used by end users, or even salespeople, because they have to learn some esoteric low or no-code framework in order to understand what's going on. And so they basically have to go through pretty intense training anyway, and it's almost like creating pseudo programmers to solve needs.
There's a lot of no-code platforms that create this odd level of abstraction where you need to dive really deep into them in order to create enough power for users to actually solve their problems, which does put a burden on engineering teams. So a product like Rough, what's very interesting about it is that because we use natural language to plug these gaps, it doesn't require any additional work from engineering teams. They can just give us their existing SDK, and we can infer what's required for an LLM to create code on top of that SDK.
The second thing is that human beings love natural language. That's how we talk to each other. And so by removing what feels like maybe a small abstraction, like a low or a no-code layer, we give a lot more people within our organisation, and even our end users, the power to create much more complex things and solve their needs.
Is this safe?
So UI sandboxing is really important when it comes to something like this. And what that means is that we take a little boundary inside our application, and we say, within this boundary, we understand the inputs and we understand the outputs of this boundary. But within that boundary, we don't need to see what's inside it, because we know all of the different capabilities that it has. And so that lets vendors offload the black box over to someone like Rough. And so that gives vendors the ability to say, we are giving our customers, our CS and sales people, the ability to do powerful things within our product, but we aren't shouldering a huge maintenance burden to do so.
What changes if we adopt a malleable software platform?
Malleable software is not going to give you your entire backlog built tomorrow. In fact, that's the whole thing that we're arguing against. What malleable software gives you is just another tool in your arsenal. So if you use a platform like Rough, you're going to have the ability to close some of those feature gaps in a way that solves the problem for probably your most important customers. It's just giving your sales teams, your sales engineers, and your product people as well, the ability to do more with what they have today.
And over time, as malleable software platforms get better and better, you're going to be able to close more and more of those gaps through a platform like Rough. You're still going to have backlog management of some degree. It's just the load is going to be lighter in many different ways.