In these trying times, a well-made product can be indispensable. Depending on what market you are in and what your product is, you can see the market change very quickly. Careful attention to modularity and architecture in the early stages of product definition and design is critical to flexibility and adaptability of the final product when market forces demand it.

Examples abound right now. COVID-19 has shut down the world. As we struggle to get by in work and life (for those who can work remotely), we have to find new ways to do it. Working remotely brings demands on how to deliver. That is straining collaboration tools, in some cases, to their breaking point, and revealing their flaws. Those that are well-designed with a solid architecture will fare better than hastily-coded, inefficient products that will buckle first under the vastly increased load.

Remote learning is stretching the limits, too, and many students do not have adequate access. Flexible products may at least allow for some stop gap deployments to improve it to additional screens and platforms. In the future, new products (cheaper) and other innovations will be needed to dovetail with needed social programs to roll these out to every last child.t

Fitness is another area. Gyms around the world are suddenly shut down, and their members- the regulars at least, are looking for at-home workouts. Clubs are scrambling for content, both live and coached. For solution providers with well-designed products, repackaging and white labeling is relatively quick. Some have shoved content out on YouTube, but that is hardly a great way to keep your member’s engaged. With YouTube, you provide the video, Google gets the data, and displays content options at the end that can hijack your members to competing brands.

In this actual example, the entire list of thumbnails on the site take the user away from the brand. When the video is done, it also takes the user to related content that belongs to somebody else. In all cases, related content that is not yours means lost eyeballs and potential lost customers.

Learning by Experience

I learned firsthand why good, modularized design is the best approach. My background is in hardware and software development. With software in particular, I learned to focus on the architecture of a system, which properly done, affords modularity and reuse. It’s not easy at the beginning to modularize a design, and that is the main reason why it so seldom happens properly.

Many years ago I worked with a group of stellar engineers at TI and and subsequently brought them into Nokia. I learned a lot from them that forever shaped my approach. The ease at which their software could be reused and redeployed was amazing. Design did take a bit longer, but that was more than made up for with shorter testing cycles (due to fewer bugs) and subsequent reuse. This is one of my basic tenets, which were described in the Ways of Thinking article.

A well-architected subsystem is easily reused on future products, over and over. A well-architected product can easily support customized configurations and be white-labeled. By layering out and isolating the branding elements into one place, you can quickly apply branding and push out new applications for new customers at a fast cadence.

Another benefit is when new requirements come in. When a crisis hits, or a market inflection point. weaknesses and gaps in existing products (yours or others) become painfully evident. With a well-designed system, you can address and add support for previously unknown requirements. Modularity implies an ability to reconfigure products depending on a changing market.

Modularity and customization doesn’t end with the modules that make up the final product. The individual features themselves, in many cases, can also be modularized- configurable for different uses. That is represented in the graphic above with a variant feature designation. “Feature B” represents the out-of-the-box feature, while “Feature B-1” represents a modest customization of that feature.

For example, your Flagship Product may be a generalized workout capture application, with the ability to record Running, Cycling, Swimming, Cardio and Weightlifting. A variant of the app with a focus on Running, would want to capture the types of runs, not just “Running”. There are many types of runs that serious runners use besides just “Running”. There are Intervals, Tempo Runs, Fartleks, Recovery Runs, etc… To the general user, they may not need that detail. But to a runner, it’s a welcomed variant.

Modularity can recursively be applied to lower level elements of your product. I have seen it applied at very low levels in the code for sub-features that are prone to revision or additions.

Don’t Set A Bad Example

Every once in a while you see something- good or bad, that makes such an impression on you that the lesson sticks with you. The team I mentioned above, that worked on the low layers of cellular data code was a great example of good design, witnessed firsthand. Their code was relevant and reused in product after product with little modification and very few bugs. When some low-level requirements changed, modularity at a low level enabled a quick update to add the requested commands.

A few years back I saw a not-so-good example. I saw a personal health-related product that generated a daily how-you-did health score from 1-100 on how well you did the previous day. It was based on a handful of variables. That score basis was hard coded and inflexible. The score took into account basic measurements like steps and sleep, and a few other parameters. When presented with new measurements, such as flights of stairs ascended and other health-related sensor measurements, they were unable to utilize these. Substantial amounts of work were needed to incorporate new types of data to generate a score still normalized on a 1-100 scale.

In technology, one thing is obvious. What is not yet invented, will be. What is now experimental, will eventually become mainstream. What is expensive now, will become cheaper. Wearable tech will forever be improving in their ability to measure more accurately and measure new things. More sensors are a given.

Instead of building a flexible scoring system that incorporated that incorporated these new biometrics and activity measurements, a product that was static in time was built. The scoring was designed around the original sensors and data that the early Fitbit and Jawbone devices could deliver. More is already available and even more will be coming. But the product score was based on 2013-2014 technology, locked in time without substantial investment to change the product.

By building in flexibility at the beginning, expecting that new capabilities are coming, and allowing- within reason, for the surprise that comes down the line (the Unknown Unknown), you’ll have a flexible product ready to adapt and be redeployed quickly when market conditions change unexpectedly. And you’ll be able to capitalize early on new technology when it becomes available. If you don’t, you risk becoming obsolete, particularly in software solutions.