Where Is My Feature Request?

I wish I had a dollar for every time I heard that in a customer meeting when I was a vendor SE. A cynic might argue that vendors don’t care about their customers — and for some vendors that might be partially true. There is a lot more at play than I think the average engineer realizes so let’s take a look.

(DISCLAIMER: I still work for a vendor but am no longer in the sales organization.)

Its Not Personal Its Business

As with a lot of things in life, it is helpful to put yourself in the other person’s shoes. If you are dealing with a vendor that is publicly traded then they have shareholders, a board, and wall street they have to answer to. They are required to show profits. That means investing their R&D dollars in the features they think will give them the biggest return. If the feature you are asking for solves a problem that is unique to your organization or your network design, it is tough for your account team to argue successfully for that feature. It is also important to consider how much you are spending with that vendor. If you are dealing with a vendor with $50B a year in revenue and you spend $200k, they are less likely to implement your features than a customer that spends $1M or more a year with them.

What Size Is The Vendor?

Ever noticed that when Juniper was startup they released features a lot faster than Cisco? These days companies like Arista and Cumulus are the ones quick to market while Juniper looks slower. Smaller (newer) vendors tend to kick out features faster. There are a lot of reasons for this:

1. They are laser focused on releasing features. It is the only way they can compete in the market and survive.
2. They can focus on new technologies and not have to worry about legacy ones. Juniper didn’t support AppleTalk, IPX, etc. like Cisco so they focused solely on IP.
3. Introducing new features likely introduces new bugs. A larger vendor will have years of code with those legacy features. If the introduce a feature, they have to carefully test and debug to make sure it does not break features existing customer rely on.
4. Starting from scratch they likely get a more modern approach. They get to take advantage of the latest development in OSs, programming languages, data models, development techniques and more. For example, Cumulus and Arista EOS are built on a modern Linux kernel whereas Juniper’s JUNOS was built on an older FreeBSD kernel.
5. They have less customers so a single customer’s revenue is a larger percentage of the total. Each customer has a bigger voice early on. As the company scales the voice of the average customer gets watered down.

So Now What?

Given that you likely have very little control over the above, what do you do now? You could gripe to your account team but they are likely doing everything they can to get your features. They get paid to sell you the product so they are already advocating for you. You could switch to a newer vendor but there are costs to learning the new product and risks the company could go out of business or get bought and the product EOL’ed.

What I found success with my customers was to design around it. This falls into a couple categories in my experience:

1. Does the product have a different feature I could use instead? Maybe I am doing things this way because it is the way I have always done them. Is there a better/different approach that would not require the vendor to implement a new feature?
2. Is there an industry trend towards a different design? If a lot of the vendor’s customers are asking for a new feature because it is the new way of doing things — and not just solving a unique problem in your network — you are much more likely to get the features you need.

Some other tips that might help:

• Do some research on how others have solved similar problems.
• Talk to your SE to see if he or she has run across this problem in the past and has a suggestion on design changes.
• See if the vendor has some Architects or other SMEs internally that may be working on solutions for similar problems.
• Gather support from other operators with similar challenges. Again, the more industry backing a feature request has, the more likely it is to get implemented.

If all else fails, submit that feature request. Just be prepared for that to be a much longer and more painful process than you initially anticipated.