Doing more does not mean you are moving forward.
A domestic hamster
White-glove configuration is a fast track to drying up a ton of resources. For any short-term euphoria earned in winning a huge sales contract with your next big enterprise customer by offering flexible near-infinite configurability of your product, a wise builder should feel an ice cold splash of dread of the maintenance of shipping such a failingly open “feature”.
Demand to Scale
At some point in a SaaS startup’s lifetime, the investor / market induced phase of “scaling” your product for many users arrives, which will require consolidating the number of custom configurations any one user could conceivably have into a standard enumerable set. As fearful as removing the white glove touch may be for those loyal enterprise customers, not doing so soon enough in the product lifetime can lead to an even more painful point of no return requiring an inevitable halt in product development while a monumental system rewrite is undergone.
Always manage customer expectations by always underselling. The strain put onto a product team when they are subject to an overselling can be thrillingly destructive. Burnout, employee attrition, spike in tech and product debt, are a few of the consequences of trying to sell “ahead of the curve”.
Feature Factory Truth
The assumed philosophy for some product teams is implicitly the problematic adage “the customer is always right” therefore what should be built are feature requests. A product team may fall into the trap of developing seemingly flexible solutions that serve a growing number of disparate use cases under the guise of gaining access to an ever widening market… which yields a cyclic pride in product-ivity culture where outputting features at whim from customer requests is praised as the driver of the product dev lifecycle. The troublesome truth for these teams is that “the customer is rarely right because they’re not product designers”.
The cost of “feature factory”ing early-on is system architecture that materializes into highly brittle error-prone NLP fuzzy matching pipelines introduced amidst scaling to artificially reduce the number of free config variables down to a manageable few. Symptoms of unscalable systems include frequent needs to rearchitect things, growing outsourcing of user-facing systems, and an uptick in customer support tickets. Minimizing the number of configuration paths should be top of mind as a product and its supporting systems grow beyond scalability.
Value of Less
Less options in a product IS the value provided by SaaS. Less configuration translates to increased predictability of a system which thus improves performance stability with a flattened tech debt curve instead of an exponentially growing tech debt. Personalization of software is not a free-for-all customization, it is a structured UX design problem of crafting a user flow that feels customized across an actually small set of ethically informed configurable choices. Scalable product design alleviates the burden of choice from the user while accelerating their critical path workflows. Such a design has a tech-coveted characteristic of surfacing clear and defined points of optimization in the underlying system, freeing dev team to focus on further increasing the scalability of the system. This is most likely to succeed when done around a strict handful of supported use cases of the software. Scale your solutions, not your feature flags.
As an addition to product bloat, if you have an app named Admin, ask yourself, why does everyone have to be on your office VPN to access it? Names are important, they’re the first impression of a thing. Lyft Driver. Clearly indicates the user served. But Admin? Admin of the galaxy? Or admin of your ecommerce back-office stock inventory? For the sake of your team’s sanity, pick one. Internal products influence the culture of a SaaS company as much as external ones, so make it a practice to ship internal products with the same level of rigor as with your publicly revenue-generating ones.
Priorities
The epitome of customization is consultancy, where a dev shop may pride itself on shipping custom json input validators. On the other hand, as a SaaS product considers scale, customization needs to be reigned in as the unique user value is clearly defined, enabling the reduction of the number of moving parts in the bloated system in order to focus teams on scaling the remaining value-adding components. Practice the daily exercise of asking yourself whether time is being spent where the distinguishable value actually lives, instead of lulling yourself into a sense of productivity with investing resources into feature creeping next to the value.
Take the time to determine the unique value your SaaS should deliver, and you will save yourself from inadvertently building non-scalable interdependent systems. Slow, deliberate software development produces fast, scalable software.
