The Sloooooooow Pace Of Feature And Design Changes

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.

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.

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.

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.

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...

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.