What's actually going wrong when a company ends up promising features up front?
It's normally a strategy problem. Normally, if you've got a big enterprise customer and they want really specific features, and those specific features are within your product strategy, then there's not normally a huge problem with promising the features upfront, because it's within the type of thing you want to put in your product anyway.
The main issue comes when you've got ten of these different enterprise deals, and they all want something subtly different, and then you have a lot of feature flags and a lot of complexity in your product. The worst thing is if you actually put those features in front of all of your customers, and now everybody is saying, hey, I never asked for this. Why is this in front of me? And then also the engineering and product team is saying, well, we've spent the last three quarters building stuff that has very little applicability to both future customers and our current customers.
So that's where the problem comes from, but it doesn't come from any sort of malicious intent from any one department. A lot of the time, sales teams are working closely with leadership or with their CRO, and they're only promising things that they really think will get them over the line. They're not normally doing it with any malicious intent.
Is there an early warning sign leaders should be watching for?
I think it is just the problem that comes with going upmarket. Once you hit the enterprise level, you are going to be dealing with these specific feature requests, and you are going to need to find a way to circumvent them.
I don't think the right answer is just saying we would never do it, because that's just opening your product up for disruption to somebody who says that they can do it. And it also leads into this build versus buy problem, where people, if they hear no too many times, are going to start thinking, well, could we build whatever we need out of the software ourselves? And that's not something that vendors want to be introducing into the conversation.
So I would say the warning signs for this problem are that you are going upmarket, or you are already upmarket in an upmarket category. And you need to recognise that this tension will come up, and you need to have ways to mitigate it rather than trying to avoid it entirely.
What does the middle path actually look like in practice?
Our approach to this is some sort of mix between customised software and malleable software. Malleable software is really powerful, but it can't cover one hundred percent of every single case that exists.
Malleability is really important for enterprise deals, because with malleability we get to close that feature gap a little bit more, to get our enterprise customers and keep them happier. But we're never going to get to one hundred percent. So there's usually always going to exist this ten percent on the roadmap. Where that tension usually manifests will be something like extremely specific security requirements, which oftentimes you are not going to be able to cover through some sort of malleable surface. Or very specific integration requests, which again, the technology is not currently there to cover with malleability, although it is something we are thinking about.
So there are two answers to how to approach this. Firstly, you need somewhere with some sort of malleability. Without malleability, every single request is going to come across like a bespoke request, and most of them can be covered by some sort of low level surface. And the second part of that is having a good product strategy, having some way that you can approach these specific customisations in a way that's a bit more cohesive to your product.
But I think saying no to everything is not the right answer, and saying yes to everything is not the right answer, but you should be able to say yes to all of the things that you can cover with some level of malleability.
So how does that actually change the shape of the roadmap?
There are two answers to that question. The first thing is that all of the things that can be covered by a malleable surface, they're basically just removed from the roadmap. We don't see them anymore. But it doesn't mean that there's no impact on the roadmap from malleable instances.
So an example of this is that what you're doing is giving sales teams, CS teams, end users the ability to change the software that they're using. But the cost of that is you want to be observing what they're doing with this, finding the gaps, and seeing if you can plug those gaps. So an example would be if somebody really wants to visualise the data for their users or their products inside an app, and you have not given them that capability, then that may require engineering to go in and provide that capability within that surface, so that the user is now able to build that feature themselves. So there is still some roadmap impact, in the sense that you need to be maintaining or at least understanding these malleable surfaces so that your users are getting the most out of them.
And then the second thing is everything else that isn't covered by a malleable surface does need to go on a traditional roadmap. It gives your engineers time. That's what's great about malleability: the time that they would otherwise be spending on building things that could just be malleable, they can now use to actually improve the product in these deeper domains, like security and things like that.
How does the job itself change?
It's not like product people can just relax and not worry about the roadmap anymore, because it just changes the way they're thinking about features. Because features now just exist in production from the outset, product managers need to be spending more of their time observing those features and being proactive about whether or not they're working for the customers.
These are still your customers. They still have problems and requirements. You might need to get a bit closer to them to understand what's going on in their lives, but you can't just wash your hands of it just because the customer built the feature, or the salesperson built the feature, instead of you. So that's the first thing. For product people, it just changes what they're doing day to day, and it becomes a bit more fulfilling, because you're working with a solution that a user or a salesperson came up with themselves. And these people are normally very close to the problem, so it's a much clearer data point than even a discovery interview sometimes is.
The other side of this is it does make the roadmap decisions you're working on a lot more difficult to reason about, because you're actually working with really hard problems. And when you extend the malleable surface and give people more power to do bigger things, oftentimes that is going to come with a bunch of questions like, well, if somebody can now do x or do y, then what does that mean for us? What kind of features will that enable? And do we want to be thinking about that from a product team perspective?
So it just changes the way product people operate. It doesn't necessarily reduce their workload. It just shifts it to something potentially a bit more fulfilling.
Real examples
We have a lot of examples of people building things. The most common thing that people build is import and export, and that's because it covers the gaps that integrations may not cover themselves. So with the malleable surface, you can create a very rich import screen to import extremely specific data, or export data in a very specific format, and then have that as an ingress and an egress to the system that you're using. So that's a very specific example, and it is very common to see.