Packet Pushers

Where Too Much Technology Would Be Barely Enough

  • HOME
  • Podcasts
    • Heavy Networking
    • Priority Queue
    • Network Break
    • Briefings In Brief
    • Datanauts
    • Full Stack
    • IPv6 Buzz
    • Community
  • News
  • Hosts
  • Subscribe
  • Sponsor
  • Contact

IGNITION MEMBERSMEMBER LOGIN

You are here: Home / Blogs / Where Is My Feature Request?

Where Is My Feature Request?

Justin Ryburn April 4, 2018

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.

About Justin Ryburn

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • Email
  • Facebook
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

RSS YouTube

  • A Data Center Down Story February 19, 2019

RSS The Weekly Show

  • Heavy Networking 430: The Future Of Networking With Guido Appenzeller February 15, 2019

RSS Priority Queue

  • PQ 161: Inside Juniper’s Programmable Silicon (Sponsored) December 13, 2018

RSS Network Break

  • Network Break 222: SnapRoute Launches Network OS; Carbonite Buys Webroot February 18, 2019

RSS Briefings In Brief

  • Tech Bytes: Thousand Eyes Shares Lessons Learned From A CenturyLink Outage (Sponsored) February 18, 2019

RSS Datanauts

  • Datanauts 158: Creating, Operating, And Collaborating On Open Source February 13, 2019

RSS Full Stack Journey

  • Full Stack Journey 028: Turning The Mic On Scott Lowe December 18, 2018

RSS IPv6 Buzz

  • IPv6 Buzz 019: IPv6 And Broadband Internet Cable Providers February 7, 2019

RSS The Community Show

  • Day Two Cloud 003: Building And Automating A Private Cloud Underlay February 20, 2019

Recent Comments

  • Martin on Fortinet Stitches New Firewalls Into Its Security Fabric
  • Ethan Banks on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • Glenn Sullivan on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • Ethan Banks on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • Ethan Banks on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • michael marrione on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators

PacketPushers Podcast

  • Heavy Networking
  • Network Break
  • Priority Queue
  • Briefings In Brief
  • Datanauts
  • Full Stack Journey
  • IPv6 Buzz
  • Community Podcast

PacketPushers Articles

  • All the News & Blogs
  • Only the Latest News
  • Only the Community Blogs
  • Virtual Toolbox

Search

Website Information

  • Frequently Asked Questions
  • Subscribe
  • Sponsorship
  • How To Pitch Us
  • Meet the Hosts
  • Terms & Conditions
  • Privacy Policy

Connect

  • Contact PacketPushers
  • Ask Me Anything
  • Subscribe to Podcasts
  • Sponsorship
  • Facebook
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

© Copyright 2019 Packet Pushers Interactive, LLC · All Rights Reserved