Author: newshirt

Our company develops a line of products.  We sell the same off-the-shelf design to many customers.  They all essentially get the same thing: a downloadable product with a certain set of features.  But there is always somebody that needs something a little different.  That’s when they become “special.”

Developing special features for a single customer can pose special challenges to an off-the-shelf product.  This post discusses three of those challenges.

My biggest concern is punishing 99% of the customers with a feature that only 1% will use.  Suppose you add a new feature to the product that 1% of your “special” customers will use.  The other 99% may not understand it.  That’s a bad thing.  They’ll think they need to understand it, and will spend time studying it, only to learn that it does not apply.  My advice: make sure that doesn’t happen.  Bury it where only the most adventurous will find it.

The next concern is maintenance.  If you create a new feature for one customer, guess what…  You’ll have to make sure it stays working forever.  It will cost you money as long as you maintain it.  Make sure you get that money up-front, or in maintenance payments along the way.

Have you given any thought to the effect your “special” features have on the rest of the product?  In other words, will these one-off features break something else.  The more complex a product is, the more likely collateral damage will occur.

The upshot is that special features cost more money than you might think.  But you have to do them to gain new customers and satify existing ones.  It’s all part of the game.  Just make sure you are profitable doing it.

–newshirt

This is not as bad as it sounds.  A lot of companies are in this boat.  They don’t have the revenue to hire full time QA engineers and testers.  So, they do what they can and rely on customers to report bugs, oversights, and possible enhancements.

Let’s briefly discuss how a ‘real’ QA department operates, and then contrast that to the poor-man’s solution.  Normally, a QA manager and team of testers ensure that products delivered straight from the engineer’s drawing boards ship with minimal bugs.  Each tester is assigned one or more areas of the product.  They follow a QA plan and checklist.  Every feature is scrutinized, often put through the paces as real customers would use it.  Bugs are sent up the chain, through the QA manager, and back to the original engineers for fixing.  Once resolved, QA engineers verify the fixes.

A QA department is nice to have.  They find hundreds of issues, and save the company a lot of money and embarrassment.  Product defects are resolved before they hit the shelves.  In the end, the QA department is usually worth their pay.  After all, that’s why the department exists in the first place – to save the company money.

But if you can’t afford the salaries, and you have a small number of customers, the development and manufacturing engineers will need to perform the dreaded duty.  (It is monotonous work.)  Problem is, engineers bristle at repetitive tasks like product testing.  They won’t do a thorough job, and you still end up getting bug reports from customers.  Plus, you’ll have to pay the engineers for their extra testing work – and they aren’t cheap.  Bugs that reach the outside still cost you money in customer dissatisfaction and lost sales, but perhaps not as much as the salaries for a full testing crew.  That’s the real gamble.  And, there are so many intangibles that a true cost analysis of each method is difficult.  But, you’ll know when you need a QA team – when customer complaints begin to kill your product momentum.  When that happens, put together a team quick!

–newshirt