The Sloooooooow Pace Of Feature And Design Changes

We've been working with a well established and reputable product (won't say which, doesn't really matter) for almost 8 years now. This product has an auto backup feature, but you can't custom schedule it- it's hard coded. And no, it's not a basic model where more advanced models offer this option.

8 years! We can't be the only ones who have been asking this to be an option, and we don't think it too much to ask. My point is, anyone else wonder why some simple basic feature or option can't ever get implemented. One where the manufacturer (or people who work there), say "Yeah, everyone asks for that. Hopefully they'll change it soon."

Anyone who works for a manufacaturer want to chime in? Is it just too much to get the R&D department to free the money for the 8 or 16 hours needed to change the code?


Often there is a single person who sets the product roadmap and that person might be a visionary or hard-headed (take your pick). Even if lots of people ask for it, that won't budge this person unless s/he wants it.

As for your specific example, there is another problem - no hard revenue attached to it. How many sales are explicitly being lost for not having custom scheduling of auto backup? How many large prospects tell this company they will go to a competitor unless they implement this feature?

I also doubt 'everyone' asks for that as it is a fairly niche thing, not a 'basic feature'. I see the value but it is not as if 'everyone' would use it (probably only a fraction of users).

Finally, while it is not a huge feature, I doubt it is one or two day's work. If you are dealing with scheduling, you need to determine how much flexibility to offer for scheduling (daily, weekly, multiple times per week), how the UI is laid out, how it deals with daylight savings, how it deals with recovering from any errors (does it email someone if there is a problem, etc.). Then there is localizing it into different languages, adding it to user manuals, training tech support to support it, etc.

Not the answer you want :) I think it's a useful feature to have, I just can see a reasonable manufacturer not giving this high priority.

John, those are good explanations and I've thought of those, too. I wish I could remember some other offhand ones as that was just one example. (And you're probably right, would most likely take more than a couple days work on that one, but I'd be happy with just that one simple option and not to many complex choices.)

As to how many sales are lost, that's a hard one to quantify, yes. But manufacturers should not be quick to dismiss small anonyances. yes, it may not immediately disqualify a "large sale", but if it causes enough anonyances in a lot of smaller sales, when it comes time to decide to upgrade the equipment, it may cause enough people to look for alternatives.

In this case, when you are trying to host a backup service for this equipment, and dozens and dozens of them are all tyring to cram in to your online storage at the same time every night and some of them they fail because of time out, that's an issue.

"tyring to cram in to your online storage at the same time every night and some of them they fail because of time out, that's an issue."

And that's where you say, "Hey we love you guys but we are seriously considering going to Genetec/Milestone/OtherVMSBigCo for new projects if you cannot deliver this feature." This is presuming they care about sales, which most do....

To add a couple more elements to those John alredy listed....

Code has to be regression tested which means everything that used to run with the old code must be put through its paces with the new code in place. This ties up a lot of resource. The bigger the code base the longer it takes. In my previous life at a large 'Big Blue' company...a regression could take a couple of weeks.

If it is something they are considering...they will collect several of the requests.... decide which ones are most requested and do them as a group to utilize the resourcemore effectively.

Having worked in software development for my entire career, most of it in product management where it's my job to guide the roadmap, I've experienced this many times over the years. I'll add my opinions. Note that these experience span many companies, many features and many products.

1. The enhancement touches a sensitive (fragile) part of the software. As such stakeholders assign a much higher degree of risk to the change. This increases the threshold for moving forward.

2. The enhancement is relatively easy to implement, but adds a significant amount of new testing. Sometimes a simple change has larger downstream impacts to QA efforts. Scheduling functions are actually a good example. The test cases can get quite large to ensure the schedule behaves as expected in all scenarios.

3. The enhancement falls under the umbrella of a larger, more ambitious enhancement. The organization is hesitant to invest effort in making a small change that they know will be wasted if they move forward with the larger effort that will replace it. The problem is that the larger effort always takes a lot longer to move forward, if it ever does.

4. The organization overvalues building and marketing new features and undervalues minor user experience improvements for existing users. It's hard to market that you "fixed something that was annoying", so those those types of improvements get undervalued. I have read that replacing a lost customer is more expensive than acquiring a new one, so companies would be wise to NOT undervalue satisfying existing customers, but some companies struggle with the balance.

5. As John mentions, sometimes even though it feels like surely EVERYONE would want a small improvement, you might actually be one of the few people requesting it. Every time I get a request for some enhancement that is relatively unusual, that is my signal to start asking "why?" questions to really understand the pain they are experiencing. There might be other solutions to the problem.

Great stuff, Ryan, thanks!

1, can you share what the application is/does in general, without revealing the manufacturer, just so we can get a sense of how glaring the omission is for that type of product?

Interesting that you ask if R&D can “free the money for 8 or 16 hours to change the code.” Your implication being that money buys features within R&D. That’s not quite how engineering works. Most of the cost of engineering goes to paying engineers. These are typically full-time salaried people. It doesn’t make sense to hire a new person to do an 8 or 16 hour job. So basically engineering resources (and thus throughput) is relatively fixed. It is not as elastic as to spend (say) $1000 more this month and get an extra feature. Hiring new engineers is difficult to justify because they’re a liability that must be supported by sales not just this month but for the foreseeable future.

So, given that engineering throughput tends to be fixed, what are all those engineers doing? That depends a lot on the nature of the products and where they are in their maturity lifecycle. Products tend to get managed with plans for the next model/version and everything that your (fixed) engineering throughput can’t support in a reasonable time gets pushed to a backlog. Low priority items on the backlog tend to stay on the backlog for a very long time. What goes into the “next” version/model of your product is deemed higher priority based on a number of factors—again, depending on the product and its maturity.

Software products are notorious for being understaffed in terms of engineers to maintain, develop new features, and test/deploy/support. Unfortunately the more mature the product becomes the more difficult it tends to be to maintain and significant new features become more and more problematic to integrate. New features also tend to have a ripple effect whereby maintenance of the old and new code takes an increasingly large percentage of your (fixed) engineering throughput. Over time software products "crystalize"--changing slowly and generally cannot change significatly unless they're shattered by a major rewrite (a costly endevour).

With few clues about what’s happening with your particular manufacturer I’d guess that 1) the slow pace of feature and design changes tends to be due to the maturity of the product and 2) this particular scheduled backup feature is stuck on the backlog and the longer it remains there the greater the chance it could remain there indefinitely.

Great and informative comment Steve, thanks. For my part, what I meant about freeing money, but didn't really make clear what I was thinking, was more taking at jab at what I believe is mostly outsourced software development and coding, which I think most all companies do (right? wrong?), so my impresison is that any feature to be added or change to be made probably each has a dollar cost, so sometimes maybe it's a matter of not just what changes to make, but how much is the 3rd party software engineering firm going to charge for each one. Maybe an overly cynical view, or maybe an incorrect one, but that's part of why I posted this question, to be set right what may be the wrong idea.

Not all software is outsourced. It depends a lot on the nature of the product and the company’s strategy related to how they will compete in the marketplace. If I was going to make an embedded DVR with VCR type controls as a standalone product then yes outsourcing the software might make sense. If I were building a software VMS with lots of integrations, targeted at multiple platforms, and it was central to my company’s ongoing operations then I’d want to hire for in-house development.

Outsourcing tends to make sense when you can clearly define the product’s requirements (both functional and non-functional, plus quality criteria). This defines a clear deliverable that the outsource company can cost with greater accuracy, ensuring they’re able to make money and you’re able to get what you need at a fair price. Whereas when you’re trying to ‘invent’ new things, or cannot articulate all requirement detail ahead of time you’re better off to have in-house engineers that can evolve the system as you learn, and respond to changing market conditions as the company grows.

Most of the large manufacturers (that are not themselves ODM/OEMing their products) have in-house teams that develop and maintain their flagship VMS and camera product-line software. They most likely only using outsource engineering for discrete ancillary products (for example, a mobile client) or possibly for lower end devices in their product lines.

This is a fantastic question and a great thread. I am really impressed at how much goes into QA in the software side of the business that I was only faintly aware of previously. My experience with one of the early VMS circa 2004 was that these feature requests were filled quickly and with relatively little cost. However, unlike many in this thread there was little to no regression testing and for every feature that was quickly bolted on, core components of the package that were previously functional would be rendered inoperable. Each time that broken component was fixed it broke further items. That VMS is no longer around. With this development approach in mind I see the point that features, no matter how minor will require more time than it appears on to an outsider.

Nice comments about the importance of QA. One thing to add / emphasize is that the VMS software / appliances are 'shipped', so if you have a bug, that bug could linger for months or lingers unless and until someone on site upgrades the software / appliance.

Web development is a lot easier in this respect, since there is only one 'spot' to deploy to and new updates / fixes can be pushed out any time. This Quora thread has an interesting discussion about pushing new code to production multiple times a day.

Great info and I appreciate the behind the scenes perspectives. I know we see things as being a lot easier from the outside than what they are.

I'd like to give more clues as to the particular product in question, but we need to protect that relationship. And I don't want to get mired in a specific product- I meant it more as a general discussion.... or maybe a vent. :)

Here's another example- web enabled smart switches. Why don't more manufacturers have a text entry available to name ports? You let me name all kinds of VLAN's and other criteria. But it'd be nice to know at a glance which port is powering the "Back Alley Cam" without having to look it up so I can reset just that camera.

Sometimes the reason can be that the person you think is the software manufacturer is really not.

Case in point, I called ONSSI several years ago and had asked them if they planned on supporting x in their recorder... I got a long winded explanation of why it wasn't necessary.

In the very next release, it was included though. Back then I naively thought that I had instigated them. Now I realize it was just because Milestone had gotten around to it.

I have noticed first-hand two types of development groups in this industry: A) small groups consisting of engineers who also have tons of industry knowledge, and B) groups of engineers who are good coders, but lack industry experience and rely on "subject matter experts", processes such as Scrum, Agile, and the like.

To the best of my knowledge, there are few, if any, successful products that began out of a B group. There are excellent products that started as the brainchild of an A group that became a B group over time (as it must as people retire, change jobs, or die off), but the number of individuals capable of fast-tracking a request that is not tied to an immediate revenue or emergency, decreases over time. To do this you need both engineering skill and industry passion in the same individual. If your product was already well-established 8 years ago, then by now those individuals are probably gone. Your best bet now is to constantly hound the sales rep and explain how much more you could sell if you had this-or-that feature.

That's a good comparison.

Exacq is an excellent example of that. Never had any real marketing hype, did not raise a lot of money but had a team that deeply knew the industry, executed very well on real features mainstream users wanted and had a great exit.

And then, on the other hand, 3VR. They had many really brilliant people, both in terms of academic background and pure intellectual abilities. But the initial design of the company/product and the lack of understanding of the industry particulars hurt greatly.

Of course, there's Dropcam, which had no industry experience but had a great exit, so I think industry experience substantially reduces chance of failure but big money and aggressive marketing can sometimes create a huge exit.

Folks,

We are an oem and even we get frustrated with the slow pace of change but please keep a couple of things in mind...and FYI, this is not an excuse, just an explanation.

First, any company with even a rudimentary presence in the market has hundreds or thousands of dealers and everyone clamors for different features. It's not that we consciously ignore a dealer but the input from thousands is deafening. Most often, everyone requests a different feature. I'd, agree that something like backup is pretty key but please don't under estimate the amount of time it takes to propery code and support a robust feature. Even if you can code a feature in 8 to 16 hours and that's incredibly rare - as the poster referenced), there are lots of other steps to make sure the installer community has the tools to effectively use it. For instance, let's say a feaure only takes a ...say a week to code. It takes 5 to 8 times that long to fully test, document, release and train the company staff on just that feature. Then there is the training of the installer community as well. That's why features are seldom released on their own but are bundled with other features which of course, then pushes the release date out even further. I guess the point is that to fully support one week of coding, you are looking at 5 to 8 additional weeks for all of the other disciplines.

Second and in the mode of full disclosure, this is a personal gripe. Do you know how many requests we get on our web site for features that are actually in the software already that an integrator hasn't learned...or....on which, we as the oem apparently have not have not effectively educated the channel? It's a constant source of debate inside the company as to the cause of this confusion. Is it poor software design on our part, poor documentation (again on our part) or is it a dealer community that just wants to get in and then get out without learning the product. The only answer that we can consistently come up with is that it's all of the above, particularly when dealing with a very diverse dealer community. That of course brings us full circle about adding features. Shoehorning them in quickly (the 8 to 16 hour number that the poster referenced) rarely completely serves the needed function in the long run because that just doesn't leave enough time for the supporting effort to make the feature a success.

Ps

Please excuse the typos assuming there are some. It was late at night when I typed this and I didn't have my reading glasses available...

that just wants to get in and then get out without learning the product.

I'm defintely guilty of willful disregard for documentation. It's a disease, like a reverse OCD.

Unfairly perhaps, but anytime a tech (who is experienced with other similar units) needs to RTFM to do basic configuration on a device, that will often be viewed negatively.

The flip side of your frustration at dealer apathy is the number of hours wasted with less capable manuals than your own, often outdated, incomplete, incoherent and even flat-out incorrect.

Everyone dreads putting a half-hour trying to make sense out of some google translated manual from hell, only to end up mano a mano with the stubborn beast in the end anyway!

And I for one, feel better about a device when I configure it for the first time without reading the whole documentation. Because it gives me a confidence that when I need to to do something later on the unit, I won't have to go searching for where and in whatever form (built-in, online, CD, DVD, paper) the documentation exists before even starting.

Those are some of the reasons that I don't RTFM for devices all the time. That's probably not want you want to hear, but I doubt I'm alone either.

That said, as many times as I have saved 10 minutes, I'm sure there are just as many times that would have been solved quicker by reading something that was just a few feet away.

Finally, even if you have a great manual, I think its worth doing a focus group with integrators that have never used your product before. Ask them to try to install it WITHOUT the manual. You may find that their intuition is better than you might expect, and that with just some minor proccess changes, your products can be made less manual dependent.

Which is good for everyone, I would think...

5, insightful feedback!

"features that are actually in the software already that an integrator hasn't learned...or...on which, we as the oem apparently have not have not effectively educated the channel?"

We have actually experienced the same thing recently. The Camera Calculator has been a huge success for us, with it alone being used 7,000+ times a month. However, every time we have a webinar, nearly half the attendees have never used it before (and many are thrilled to learn about it). On the one hand, that means there is a lot of upside left. On the other, it underscores that we need to spend more time promoting / educating our members about it.

This is great feedback on the process and I thank all the respondents.

Something really interesting that I think came out of this was the suggestion....

"Finally, even if you have a great manual, I think its worth doing a focus group with integrators that have never used your product before. Ask them to try to install it WITHOUT the manual. You may find that their intuition is better than you might expect, and that with just some minor proccess changes, your products can be made less manual dependent."

That sounds like a good idea.... to me. But from a manufacturer side maybe some have tried that and found it didn't work as expected.

And I'm perfectly willing to be disproved on estimated development time. I concede I am not a developer.

This seems to have accomplished half my goal- get some feedback on what the challenges are sometimes and why what seems like some seemingly simple things take so long to get done, if every. But I was also hoping to get some other examples of things from other people to maybe back me up. Maybe I am just a whiner.

Surprisingly many of the vendors in physical security, regardless of size of company, have significant product management, engineering, and support weaknesses.

Feel free to visualize the loud 20 minute version of that comment coming out of my mouth when I'm sitting next to the CIO of your biggest customer the morning after all the door locks fail, and I'm that irritating geek lecturing you while they burn your purchase order in front of you.

Some vendors are good. Some have figured out they need to improve. Some really seem to think they can stand still. That third group is gonna get run over by one of the other two groups eventually. The lucky ones probably listened when the customer asked for new features.

Rodney, are you really saying there are manufacturers that feel they don't need to change or listen to what customers want?

Well, maybe they feel pandering to users and integrators requests is chasing geese and would take away resources from mainting their standing in the industry.

Wow that video is a blast from the past. The dark ages practically.