The mantra of both Product Managers and Nancy Reagan with her 1980s anti-drug campaign is “Just say no.”

Indeed, Nancy Reagan had a point – just saying no to drugs at the outset prevents subsequent calamities. But what about Product Managers? Why should they say no when their mission is to delight customers with whiz-bang products?

Product Managers attempt to take the parochial suggestions from a single customer and generalize them to benefit all customers. Sometimes this isn’t possible with features that address unusual business needs not commonly shared by other enterprises. When a feature cannot be crafted to be useful to many customers, this leaves a Product Manager with a few imperfect choices:

1. Agree to provide a feature that only benefits a single customer. The problem with a Product Manager who always says yes is that eventually, the product will become rich with features almost no one wants or needs. The “just say no” product management mantra is borne from the prospect of complicated, feature-stuffed products that don’t server customers’ needs.
2. Refuse to provide a feature that benefits only one customer. The problem with this decision is the one customer may take their business elsewhere – to a provider more willing to kowtow to the customer’s unique demands. Unless a software company’s intention is to “fire customers” with problems that don’t align with their strategy, losing customers is terrible. Still, the alternative, option 1, is potentially worse.
3. Offer to make a “special build” of the product with the feature that’s provided just to this one customer. A smart customer realizes that receiving a bespoke software product is dangerous. The provider must remember to keep this separate version up-to-date when they implement new features and fix bugs. Furthermore, one-off products seldom receive the same testing scrutiny as core products.
4. Craft the feature with a binary on/off toggle with a default of “off.” The feature becomes part of the official product but isn’t used or noticed by most customers. While this may sound like the perfect compromise, adding feature toggles complicates test plans. The existence of toggle-able features presents factorially increasing testing paths that can quickly become unwieldy.

How KoolSpan approaches product features

Many companies bend to implement specialized features for important customers. Other companies justify making one-off products by cobbling together a special team and classifying the revenue as Professional Services.

Although KoolSpan is flexible, it doesn’t bend to inflict unnecessary features on unsuspecting customers. Furthermore, KoolSpan is intentionally small and nimble and doesn’t offer professional services — KoolSpan is a software company through and through.

KoolSpan’s approach for features that aren’t universally useful is to either say no or to put them behind a feature toggle. This way, customers who don’t need a feature never have to see it or be affected by it. Building a rich set of automated tests enables us to thoroughly test all the possible combination of toggled features.

If you have three features that can each be in either an “on” or “off” state, the number of possible combinations can be calculated using the formula for combinations of binary states:

Number of combinations = 2ⁿ

where n is the number of features.

For three features:

Number of combinations = 2³ = 8

Possible Combinations:

• Feature 1: Off, Feature 2: Off, Feature 3: Off
• Feature 1: Off, Feature 2: Off, Feature 3: On
• Feature 1: Off, Feature 2: On, Feature 3: Off
• Feature 1: Off, Feature 2: On, Feature 3: On
• Feature 1: On, Feature 2: Off, Feature 3: Off
• Feature 1: On, Feature 2: Off, Feature 3: On
• Feature 1: On, Feature 2: On, Feature 3: Off
• Feature 1: On, Feature 2: On, Feature 3: On

So, there are 8 possible combinations. Without a library of automated tests, testing more than three toggled features quickly becomes unmanageable.

Externalizing to avoid bespoke software

Externalizing strings, icons, and typography settings allows for TrustCall product customization without requiring a bespoke build. Internationalization, White Labeling, and UI reskinning are accomplished by swapping externalized resource files which are read at runtime. 

Any company, especially a small one, benefits from avoiding special builds requiring maintenance, support, and institutional memory. Customers benefit as well, with products that conform to their specifications but also receive focused maintenance and testing.

 Quality over quantity at KoolSpan

TrustCall, KoolSpan’s flagship secure communications product, is intentionally modestly-featured, not feature-rich. Sure, we have the table stakes features everyone expects and needs in a communications product. But instead of implementing bells and whistles, the Product team decided to focus on building high-quality generally applicable features. Taking a customer-centric approach, the Product team listens to the challenges our customers face and crafts features to solve them.

Quality has been paramount since the TrustCall product’s inception. Our customers must establish secure audio and video calls from far-flung locations where coverage is sometimes spotty. Ensuring the best possible connections in imperfect conditions is an ever-present KoolSpan company-wide mandate.