If there is a never-ending theme in software organisations, it’s the mutual misunderstanding and frustration between business and tech. On the business side, tech is never fast enough. If new features were done faster and with fewer bugs, we could conquer so much more market share, they say. And on the tech side, sales and support just continuously throw new ideas and making promises to customers and board members without even asking them if it’s possible.
Having been on both sides of the table, I have a lot of empathy for all the parties involved in this dance, and it’s usually one of the main topics we cover during the TLT21 workshops.
I’ve found that the main reason for why this situation happens is that the generation of new feature ideas is easy and cheap. It’s usually a couple of lines on a ticket, or worst, a verbal promise made during a sales pitch. On the other hand, executing these ideas, making them, building them, is hard and expensive. You need to design them, code them, integrate them, test them… So, on one hand, you have an infinite inventory of potential new features (that “we have to build to reach our sales targets”) and, on the other hand, a finite throughput of programming power to make them.
You can, of course, add more developers and increase your efficiency (rarely works together though), but since the idea inventory is infinite, the problem will keep happening. So how do you solve this problem?
Adapting the flow to your constraint
According to the theory of constraints (TOC), a management philosophy introduced by Eliyahu M. Goldratt in 1984, “a chain is no stronger than its weakest link". In other words, since it’s hard and expensive to increase programming throughput, the system should adapt its speed to this throughput. This means that the generation of new ideas should be made harder so that their inventory doesn’t grow infinitely, putting pressure on the system’s constraint. Since the generation of ideas is naturally easy and cheap, you have to build “artificial” speed bumps to slow them down.
Here are some techniques I’ve tested and find interesting:
No backlogs: at software company Basecamp, there are no backlogs because “backlogs are a big weight we don’t need to carry”. So what do they do instead? Before each development cycle, they hold a meeting where stakeholders decide what to do in the next cycle. If they decide to build a feature, it goes into the next cycle to build. If they don’t, they let it go. Of course, everyone can still track bugs, requests, or things they want to do independently without a central inventory that keeps piling up and frustrates everyone
Limit promises: that’s also something that’s done at Basecamp. They never commit on a date to implement a certain feature. To be honest, even I find this a bit too much and that would definitely never work in an enterprise model where you have to implement certain features to sign big customers. On the other hand, I’ve seen way too many salespeople hide behind a customers’ request list to justify the inability to sell. As a former maker and seller of software products, I’ve come to realize that this is almost never true. There is a huge difference between doing solving your customer’s problem and doing whatever he’s asking (unless you’re a service company, in this case, that’s your business model). Salespeople should be trained to go around Santa’s list of features and solve their customer’s problems with the features that are already there (without promising).
Sales and support become Product Owners: that’s something I experimented at my former startup. Since we were a small team, we couldn’t afford to have 1 person at each position so I decided to train sales and support staff to become product owners. Since our product was used both by support (back office) and by customers (handled by sales), it made a lot of sense for them to formulate the majority of our roadmap items. At first, I was acting as PM but since I quickly became a blocking point, I realised I shouldn’t be doing this. And by responsibilising sales and support in the formalisation of features, it became a “harder” task for them, forcing them to unconsciously dismiss not so interesting features or push back more when customers were asking for new features.
Do you have this problem within your organisation? How do you deal with it?