A DJ is working hard to keep the dancefloor going. But in front of the booth, a girl is trying to get his attention. It's her friend's birthday, and she was wondering whether she could request a song. DJs loathe requests because they make it hard to do a good job. They're building a chain of songs that keeps the audience dancing and now, all of a sudden, they have to throw the Macarena in there somewhere. Ugh!
There's a similar dynamic when building software products.
We build great products by allocating our attention to a chain of valuable problems. We can always come up with some solution. Even if we only have a single day, we can alleviate the pain somewhat. The solution will depend on the time we have to address the problem. A well-defined problem has multiple solutions, which gives us flexibility. This flexibility is what allows us to decide to release something that's good enough for now and move on to the next problem.
So rather than listing work items and stressing about closing all of them, we do the best we can with the allocated time. It's a powerful and sustainable approach. It's how we delight our customers and keep the dancefloor going.
However, there is a scenario I often see in SaaS startups that hinders this kind of flexibility. Salespeople will try to sign up new customers who are interested in the product. But during the sales conversation, the potential customer drops a hint. They like the product, but they would really buy it if it also did X. And X is usually some bespoke feature that's not on the roadmap.
Let's say you're building an access control system. Your potential customer wants to implement such a system in their new offices so their workers can badge in and out. It's a big deal. But they have a request for a feature that would REALLY convince them to sign up. Since people badge in and out, can't you link it to their timesheet application? How hard can it be to build such an integration, right?
Now, from a sales perspective, trying to indulge such a customer makes total sense. It's lubricant for the sales machine. But it poses a big, long-lasting risk.
Building a custom feature for a single client is an expensive way to acquire new customers. The feature needs to be built and maintained forever, which is not for free. Since the feature has no value to other customers, this is a pure acquisition cost.
But there is another, more hidden cost: it kills our flexibility.
It's already difficult enough to get our developers and product people out of the scope mindset. Thinking problem-first is hard to teach specialists, let alone customers. So when that client mentions that feature, they have a scope in mind—a list of all the work that needs to be done before the project is done.
If they ask you for such a feature and you comply, they are now in the driver's seat. You lost flexibility because the feature is only done when they say it's done! You can no longer do the best with the time you allocate. You can no longer decide that something is good enough for now. You've agreed to play the Macarena.
There's a vocal group of developers (and DJs) who will advise you never to agree to build such a feature. They'll scream blue murder because Sales tried to close a deal. The reality is that such a scenario can be both risky and lucrative in the early days.
So here's how to handle such a feature request without losing too much flexibility.
Small projects
A bespoke feature is a project— it has a clear Iron Triangle. Large projects are risky, so it makes sense to keep the scope as small as possible. Instead of coming up with advanced integration flows, try sending a simple REST call when someone uses their badge. When the scope is small, it's easier to define and follow up. There is less wiggle room to decide when it’s done. It also allows you to sweat out this period of inflexibility more quickly. Bespoke features should be minimal-effort solutions—just enough to convince the customer to buy.
Don't let them pick up the check
Sometimes, customers know that they are pushing it, and they offer to pay to develop the bespoke feature. To salespeople, this sounds like a great deal. It is, however, without exception, a deal with the Devil. As soon as a customer pays for a feature, they feel entitled to it. And rightfully so. You'll get an endless list of feedback and requests. Your team will be forced to spend a considerable amount of their attention on a feature that doesn't grow your product. The client has become another demanding stakeholder to please.
A bespoke feature is a pure acquisition cost and must be treated as such.
Make it somewhat reusable
Often, the bespoke solution can be interpreted a bit broader, and while it probably won't be useful for most customers, it might be to some. You could build a system of configurable webhooks that trigger when people use their badges. If you can convince the potential customer to integrate with that, you have a reusable feature, and you push most of the custom development to the client.
Now, you no longer have a bespoke feature. You have a feature used by only one customer. That's yet another thing your salespeople can actively sell.
Customers listen to what you have to say but care more about what you do. So, if you show them that you're willing to take requests, they'll line up in front of the DJ booth. Taking requests impacts your ability to decide what's good enough. All of a sudden, there's another stakeholder on board who doesn't care about the product as a whole but only cares about their own use cases. That's a situation that's often hard to recover from.
Coming up with a reusable feature, even if no one else is currently interested, is by far the best way to handle such a bespoke request. It builds some value and ensures you remain in the driver's seat. Rather than building what the customer asks, you show them how they can solve their problem with your product.
If that doesn't work and you really have to close the deal, work hard to keep the scope of the project small and sweat it out as soon as possible.
Good analogy and nice article! Sometimes you just need the money from the sale and it’s okay but even then you should keep that bespoke feature separate from your code.