You’ve most probably been there: To win that one ueber-important client, your friendly sales rep sells the farm and his grandmother (well actually he sells features, which he invents right in front of the client to make sure to get the deal, but the effect is nearly the same). And not only does he sell „the grand new feature in the sky“, but he even guarantees a delivery date – and all without speaking a word to the tech guys. Sweet, huh? He is a hero. He made that huge deal and everyone is patting his shoulder. Well, besides you probably. And everyone else who now has to deliver a completely bloated feature in a totally unrealistic time frame. And, of course, there’s absolutely no room for negotiations. In fact, you’re not even allowed to talk to the client to ask a question about his requirements because the sales guy doesn’t want to make a „bad impression“.
Non-negotiable Features Create Technical Debt
You know what happens next. The developers scramble to their feet and churn out something, which, at first glance, can be considered as the feature the client ordered. You don’t have time for adapting the architecture to the new needs. And, of course, automated tests, proper feedback, and a useable UI go right out the window. You might be able to pull off that crazy delivery date, but at what cost? You’re left now with a bloated beast of software put together in such a rush that no one dares touch once it’s released because the chances of breaking something are significant. You dug your technical grave, but the rest of the company is celebrating a huge win! No one outside the tech department noticed how huge the technical debt you’ve just taken in order to deliver.
No-one Profits From Non-negotiable Features
If features are pre-sold without any option to negotiate what’s important and what may be left out, you inevitably end up with too much complexity. Sales representatives often feel pressure to promise too much to a client. They want to close a deal, but they’re not able to see the technical implications. They raise very high expectations and often fix them in the contract which removes any way to iterate and develop your product until it’s actually useful for your client. Instead, the contract is based on a rough, but very challenging scenario, which is impossible to deliver and has very little chance to fit the client’s needs once it is released. Such pre-sold features not only tie your hands, but the client is also not able to change what he needs over time. Both parties agreed to the contract and a rigid change management process is installed to make change as painful (and therefore infrequent) as possible.
Agile Web Operations 
Thank you. Will forward this to our sales reps.
LikeLike
So true.
Non negotiable features are valid when upside outweighs the risk and effort. The problem is often when every other deal has non negotiable features and it becomes a sales culture. When I was a product manager I always used to buffer product roadmaps because I knew a surprise from sales would land on my desk every month. The problem as you say is that sales have no understanding or interest in how things get delivered, they just want it asap. It’s fine for PM and R&D to make magic happen every now and then but doing it every week just burns people out.
What used to frustrate me is people in the sales who had a little bit of technical knowledge but had never built or designed applications in their life. They seemed to have all the answers but knew jack about the application development lifecycle.
LikeLike
Wow, it is almost as if you had been listening in on my thoughts over the last few days. Great job of turning it into such a crystal clear message. 😉
LikeLike
Building Planbox, an Agile tool, we hit that problem almost on a daily basis. Ironically, we get lots of requests for waterfall features inside an Agile tool. They come from customers who want to or are transitioning to SCRUM and want a gradual shift. That situation is always very tough because if we give in and develop a waterfall feature to help the customer transition, we are shooting our-self in the foot, and hindering the customer’s chance of a successful transition.
Its paramount that the sales team understands this to avoid being blind sided by short-term sale goals.
LikeLike
This causes a lot of pain in a lot of places. The last two companies I worked with had this decease bad. I would say it’s one of the the biggest problems and challenges in the software industry today. To all sales people of the world: it’s time to have a look on how the last 10-20 years of improving the process of making what you sell affect the way you need to sell it.
LikeLike
But then again, I get asked back “-so how do you sell something without specifying exactly what it is and when it’s gonna get delivered?”. I’m not in the position to edit our template legal contracts, and I’m not sure I can give an elevator pitch version of an answer to that either.
Sales can educate the customer – but did anyone manage to educate sales?
LikeLike
sending this to my sales vp…wait a sec…i am the sales vp
LikeLike
Why is everyone saying that sales should read this/be educated? This is a clear case of “the folly of rewarding A while hoping for B”.
If you reward people for selling something regardless of whether it can be delivered, you are practically asking them to sell the impossible (or possible only with huge technical debt as described). It’s the same as rewarding people for selling on credit regardless of the customer’s ability to pay (the company suffers, the sales rep wins).
Until the reward system changes, there is no reason for the sales organization to change. The problem lies above in the hierarchy, with the decision-makers that are incapable of systems thinking and thus encourage this type of local optimization at the expense of the organization as a whole.
LikeLike
Thanks Adriana for your clear words. You nailed it. The same is true for venture funded startups. Too much funding too early shoots the expectations through the roof. Then those expectations can only be fulfilled by creating huge technical debt (or not at all).
LikeLike
This has been the pattern in almost all the projects that we do. Any concrete solutions or best practices to avoid this by any chance? Couldn’t have been conveyed better.
LikeLike
As Adriana already mentioned, the only way to remove the root cause is to change the rewarding system.
From within a development team there’s not too much you can do other than trying to educate your sales reps on the dramatic costs and risks for their client business they create with their approach.
LikeLike
The comments were much more interesting than the article (sorry Matthias). The whole reward system discussion really struck home with me. If you’ve ever had to sit through a sales discussion where someone is pointing out that sales rep a.) had inside (development) info that allowed them to make a sale using promises sales rep b.) wasn’t even aware of yet…. You know it’s out of whack. And you can’t really get them to buy into the fact that it’s out of whack because there shouldn’t have been promises in the first place that weren’t backed up by negotiated features. Too late by the time b.) makes a sale.
LikeLike
No issues. I’m glad that you found helpful stuff on our site – no matter who the author is 🙂
LikeLike